Bug 875484

Summary: anaconda damages W7 guests when reclaiming space with 'shrink' using AUTOMATIC PARTITIONING
Product: [Fedora] Fedora Reporter: Reartes Guillermo <rtguille>
Component: anacondaAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 18CC: anaconda-maint-list, bugzilla, g.kaviyarasu, jonathan, kraxel, pf.rhlists, robatino, sbueno, vanmeeuwen+fedora, vpodzime
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-14 06:25:10 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 752661    
Attachments:
Description Flags
anaconda.log (BEFORE INSTALL)
none
anaconda.log (AFTER INSTALL)
none
program.log (BEFORE INSTALL)
none
program.log (AFTER INSTALL)
none
storage.log (BEFORE INSTALL)
none
storage.log (AFTER INSTALL)
none
storage.log (AFTER INSTALL) none

Description Reartes Guillermo 2012-11-11 10:27:31 EST
Description of problem:

W7 instances might be damaged when one reclaims space (use the 'shrink' action).

Version-Release number of selected component (if applicable):
F18b TC8

How reproducible:
always

Steps to Reproduce:

0. Get a W7 guest
1. Launch anaconda and enter STORAGE: INSTALLATION DESTINATION
2. Do AUTOMATIC PARTITIONING, go to 'reclaim space'
3. Choose 'shrink' for the big ntfs partition
4. Press 'Reclaim Space' and return to the MAIN HUB
5. Install
6. Reboot, Fedora is OK, but 7 it is not (it BSODs and cannot be repaired)

Actual results:
unknown, 7 will not boot

Expected results:
do not damage the other os

Additional info:
i sincerely do not know much about 7.
Comment 1 Reartes Guillermo 2012-11-13 12:09:04 EST
Created attachment 644244 [details]
anaconda.log (BEFORE INSTALL)
Comment 2 Reartes Guillermo 2012-11-13 12:10:04 EST
Created attachment 644245 [details]
anaconda.log (AFTER INSTALL)
Comment 3 Reartes Guillermo 2012-11-13 12:11:12 EST
Created attachment 644246 [details]
program.log (BEFORE INSTALL)
Comment 4 Reartes Guillermo 2012-11-13 12:12:38 EST
Created attachment 644247 [details]
program.log (AFTER INSTALL)
Comment 5 Reartes Guillermo 2012-11-13 12:13:56 EST
Created attachment 644248 [details]
storage.log (BEFORE INSTALL)
Comment 6 Reartes Guillermo 2012-11-13 12:14:54 EST
Created attachment 644249 [details]
storage.log (AFTER INSTALL)
Comment 7 Reartes Guillermo 2012-11-13 12:18:33 EST
Created attachment 644252 [details]
storage.log (AFTER INSTALL)
Comment 8 Reartes Guillermo 2012-12-01 19:04:58 EST
This is still valid with F18b RC1.
Comment 9 Reartes Guillermo 2012-12-05 15:47:29 EST
I tried today with smoke3 netinstall.

Steps:

0. Restore the working w7 qemu image and test that it boots: it does.
1. Boot F18b (anaconda smoke3) netinstall and use closest mirror.
2. Selected 'minimal' package set.
3. Select the disk containing W7 (in this case, there is only one disk).
4. Set anaconda's option to NOT to install any bootloader.
5. Selected automatic partitioning, default type (lvm).
6. Reclaim space: set to 'shrink' the big ntfs partition.
7. Installed F18b smoke3 ok.

I performed these steps twice, and:

#1: The first time, W7 was bootable after F18b install.

#2: The second time, W7 performs a BSOD as previous comments have shown.

Note: On #1, a chkdsk was automatically performed. No chkdsk was ever performed
on the other tries.
Comment 10 Reartes Guillermo 2012-12-07 14:40:04 EST
I performed one more test with smoke4, instead of letting anaconda do the shrink, i did it manually on another vt.

0. Restore the original working qemu w7 image in which w7 uses the whole disk.

1. Boot Fedora. (smoke4 netinstall).

2. At the 'welcome screen' switch to VT2.

3. In VT2, resize the ntfs filesystem.

# ntfsresize -c /dev/sda2

# ntfsresize -m /dev/sda2
11768

# ntfsresize -ff -s 11768M /dev/sda2

# ntfsresize -c /dev/sda2

4. In VT2, now that the filesystem was resized ok, resize the 
partition.

# fdisk /dev/sda

Delete sda2, and create them again and use +11768M for size.

5. Reboot, let w7 perform the chkdsk and reboot again. It does
boot.


Note: i noticed that on some old anaconda logs that 12321 was used instead of 11768 which is what i do obtain manually.

After doing the above, i launched F18b smoke4 again, and installed
Fedora. I used closest mirror, minimal install, automatic partition (now
it detected free space). It installed ok, and w7 was bootable too.
Comment 11 Reartes Guillermo 2012-12-12 13:49:34 EST
Ok, it seems that anaconda might be doing something bad, let's find it.

I decided to try 'findgrub' script, after reading this thread:
http://forums.opensuse.org/english/other-forums/development/programming-scripting/447138-looking-grub-windows-bootloader-all-partitions-24.html

Sadly, for findgrub to work, one needs to copy 
some binaries that are not presetn in the F18 system. 
Also, the ssh server from the F18 system does not work
for some reason. I also noticed that there is no 
'passwd' command on the F18 system, that is truly ugly.
(Some commands that are really usefull in case of an 
issue are missing: passwd, lsusb, maybe there is a 
reason but i don't know it).

This led me to perform something very anoying: copy with
scp from the F18 system the binaries from my F17 host there.

Ok, the mini-rant is over, back again on topic:

Procedure to make 'findgrub' functional in the following tests:

# loadkeys es
# cd /tmp
# scp user@192.168.0.10:~/findgrub .
# chmod +x ./findgrub
# scp root@192.168.0.10:/usr/bin/tput /usr/bin/
# scp root@192.168.0.10:/usr/bin/getopt /usr/bin/
# scp root@192.168.0.10:/usr/bin/hexdump /usr/bin/

I will put each TEST in its own comment.
Comment 12 Reartes Guillermo 2012-12-12 13:50:00 EST
TEST#1: (smoke5: anaconda 18.37)

0. Restore a working W7 qemu image
1. Boot F18,  make 'findgrub' funcional
2. Execute and capture "findgrub -n" output
3. Capture a "fdisk -l" from before resize.
RESULT (Does W7 boot?): Y


Output of 'findgrub -n':
NO OPERATION WAS PERFORMED YET

Find Grub Version 4.4.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ... --> Windows Generic MBR (Sig: 0xec1b5526)
 - searching partition /dev/sda1   *  (NTFS)          ... --> Windows7/Vista Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - searching partition /dev/sda2      (NTFS)          ...

********************************************************************************
WARNING: /boot/grub/device.map not found.
         Displayed BIOS device mapping may be incorrect!
********************************************************************************

Press <enter> to Exit findgrub...


Output of 'fdisk -l':
NO OPERATION WAS PERFORMED YET

Disk /dev/sda: 27.8 GB, 27787264000 bytes, 54272000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5526ec1b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848    54269951    27031552    7  HPFS/NTFS/exFAT
Comment 13 Reartes Guillermo 2012-12-12 13:50:15 EST
TEST#2: (smoke5: anaconda 18.37)

0. Boot F18, make 'findgrub' funcional

1. Perform the NTFS resize MANUALLY: 

  1A. Boot Fedora, At the 'welcome screen' switch to VT2.

  1B. In VT2, resize the ntfs filesystem:

    # ntfsresize -c /dev/sda2

    # ntfsresize -m /dev/sda2
    11798

    # ntfsresize -ff -s 11798M /dev/sda2

    # ntfsresize -c /dev/sda2

  1C. In VT2, now that the filesystem was resized ok, resize the 
  partition:

    # fdisk /dev/sda

    Delete sda2, and create it again and use +11798M for size.
    The partition was PRIMARY, so create it PRIMARY too.
    The partition number and starting sector should be the same,
    just accept the defaults.
    The partition type must be set again to 07.

2. Execute another capture of "findgrub -n" output

3. Capture a "fdisk -l" from before resize.
RESULT (Does W7 boot?): Y


Output of 'findgrub -n':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED MANUALLY


Find Grub Version 4.4.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ... --> Windows Generic MBR (Sig: 0xec1b5526)
 - searching partition /dev/sda1   *  (NTFS)          ... --> Windows7/Vista Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - searching partition /dev/sda2      (NTFS)          ...

********************************************************************************
WARNING: /boot/grub/device.map not found.
         Displayed BIOS device mapping may be incorrect!
********************************************************************************

Press <enter> to Exit findgrub...

Output of 'fdisk -l':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED MANUALLY

Disk /dev/sda: 27.8 GB, 27787264000 bytes, 54272000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5526ec1b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848    24369151    12081152    7  HPFS/NTFS/exFAT
Comment 14 Reartes Guillermo 2012-12-12 13:50:30 EST
TEST#3: (smoke5: anaconda 18.37)

0. Restore a working W7 qemu image

1. Boot F18, make 'findgrub' funcional

2. Do the ntfs resize with F18 smoke5 (Install F18 smoke5 netinstall)
  2A. Set keyborard to: Spanish 
  2B. Set Timezone to America/Buenos_Aires and disabled NTP
  2C. Selected CLOSEST MIRROR (using NETINSTALL) and choose MINIMAL
  2D. Performed AUTOMATIC PARTITIONING, default SCHEME (LVM) and set the
  big ntfs partition to 'shrink'.

3. Execute another capture of "findgrub -n" output

4. Capture a "fdisk -l" from AFTER resize.
5. Capture all anaconda logfiles AFTER resize.
RESULT (Does W7 boot?): N

NOTE: No bootloader was installed. This was NOT intended.



Output of 'findgrub -n':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED AUTOMATICALLY BY ANACONDA

Find Grub Version 4.4.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ... --> Windows Generic MBR (Sig: 0xec1b5526)
 - searching partition /dev/sda1   *  (NTFS)          ... --> Windows7/Vista Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - searching partition /dev/sda2      (NTFS)          ...Failed to read last sector (24066392): Invalid argument
HINTS: Either the volume is a RAID/LDM but it wasn't setup yet,
   or it was not setup correctly (e.g. by not using mdadm --build ...),
   or a wrong device is tried to be mounted,
   or the partition table is corrupt (partition is smaller than NTFS),
   or the NTFS boot sector is corrupt (NTFS size is not valid).
Failed to mount '/dev/sda2': Invalid argument
The device '/dev/sda2' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
umount: /mnt: not mounted

 - reading bootsector  /dev/sda3      (LINUX)         ...
 - reading bootsector  /dev/sda4      (Extended)      ...
 - searching partition /dev/sda5      (LINUX LVM)     ...

********************************************************************************
WARNING: /boot/grub/device.map not found.
         Displayed BIOS device mapping may be incorrect!
********************************************************************************

Press <enter> to Exit findgrub...


Output of 'fdisk -l':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED AUTOMATICALLY BY ANACONDA

Disk /dev/sda: 27.8 GB, 27787264000 bytes, 54272000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5526ec1b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848    24272895    12033024    7  HPFS/NTFS/exFAT
/dev/sda3        24272896    25296895      512000   83  Linux
/dev/sda4        25296896    54271999    14487552    5  Extended
/dev/sda5        25298944    54271999    14486528   8e  Linux LVM
Comment 15 Reartes Guillermo 2012-12-12 13:50:52 EST
TEST#4: (smoke5: anaconda 18.37)

On this test, i will use the value that ancaconda choose
on test #3. (wich is: 12322M)

0. Boot F18, make 'findgrub' funcional

1. Perform the NTFS resize MANUALLY: 

  1A. Boot Fedora, At the 'welcome screen' switch to VT2.

  1B. In VT2, resize the ntfs filesystem:

    # ntfsresize -c /dev/sda2

    # ntfsresize -m /dev/sda2
    11798

    # ntfsresize -ff -s 12322M /dev/sda2

    # ntfsresize -c /dev/sda2

  1C. In VT2, now that the filesystem was resized ok, resize the 
  partition:

    # fdisk /dev/sda

    Delete sda2, and create it again and use +12322M for size.
    The partition was PRIMARY, so create it PRIMARY too.
    The partition number and starting sector should be the same,
    just accept the defaults.
    The partition type must be set again to 07.

2. Execute another capture of "findgrub -n" output

3. Capture a "fdisk -l" from before resize.
RESULT (Does W7 boot?): Y

Output of 'findgrub -n':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED MANUALLY WITH THE
SIZE THAT ANACONDA DOES SELECT

Find Grub Version 4.4.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ... --> Windows Generic MBR (Sig: 0xec1b5526)
 - searching partition /dev/sda1   *  (NTFS)          ... --> Windows7/Vista Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - searching partition /dev/sda2      (NTFS)          ...

********************************************************************************
WARNING: /boot/grub/device.map not found.
         Displayed BIOS device mapping may be incorrect!
********************************************************************************

Press <enter> to Exit findgrub...


Output of 'fdisk -l':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED MANUALLY WITH THE
SIZE THAT ANACONDA DOES SELECT

Disk /dev/sda: 27.8 GB, 27787264000 bytes, 54272000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5526ec1b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848    25442303    12617728    7  HPFS/NTFS/exFAT
Comment 16 Reartes Guillermo 2012-12-12 13:51:21 EST
TEST#5: (smoke5: anaconda 18.37)

0. Restore a working W7 qemu image

1. Boot F18, make 'findgrub' funcional

2. Do the ntfs resize with F18 smoke5 (Install F18 smoke5 netinstall)
  2A. Set keyborard to: Spanish 
  2B. Set Timezone to America/Buenos_Aires and disabled NTP
  2C. Selected CLOSEST MIRROR (using NETINSTALL) and choose MINIMAL
  2D. Performed AUTOMATIC PARTITIONING, default SCHEME (LVM) and set the
  big ntfs partition to 'shrink'.

  NOTE: I will hit a bug in which the bootloader will not be installed, even
  if i do not select such opton. This bug will actually helpfull. :-)
  Step 7. requieres to not to install a bootloader anyway.

3. Switch to VT2 to launch commands.

4. Capture a "fdisk -l" from AFTER resize.
5. Capture all anaconda logfiles AFTER resize.
6. Execute another capture of "findgrub -n" output

7. I will resize the partition (ntfs) manually again, discarding the partition
table produced by anaconda. (since no booloader was installed, i expect to be 
able to boot win7).

    # fdisk /dev/sda

    Delete al linux partitions.
    
    Delete sda2, and create it again and use +12322M for size.
    The partition was PRIMARY, so create it PRIMARY too.
    The partition number and starting sector should be the same,
    just accept the defaults.
    The partition type must be set again to 07.


RESULT (Does W7 boot?): Y

Output of 'fdisk -l':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED AUTOMATICALLY BY ANACONDA:

Disk /dev/sda: 27.8 GB, 27787264000 bytes, 54272000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5526ec1b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848    24272895    12033024    7  HPFS/NTFS/exFAT
/dev/sda3        24272896    25296895      512000   83  Linux
/dev/sda4        25296896    54271999    14487552    5  Extended
/dev/sda5        25298944    54271999    14486528   8e  Linux LVM


Output of 'fdisk -l':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED MANUALLY (AND ALL LINUX PARTITIONS WERE DELETED):

Disk /dev/sda: 27.8 GB, 27787264000 bytes, 54272000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x5526ec1b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848    25442303    12617728    7  HPFS/NTFS/exFAT

>>>>>>> FOUND IT <<<<<<<<<
>>> 
>>> The END SECTOR for the NTFS partiton is WRONG when 
>>> anaconda performs the resize.
>>>
>>>

Output of 'findgrub -n':
THE NTFS FILESYSTEM/PARTITION WERE RESIZED MANUALLY (AND ALL LINUX PARTITIONS WERE DELETED):

Find Grub Version 4.4.1 - Written for openSUSE Forums

 - reading MBR on disk /dev/sda                       ... --> Windows Generic MBR (Sig: 0xec1b5526)
 - searching partition /dev/sda1   *  (NTFS)          ... --> Windows7/Vista Loader found in /dev/sda1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can add the following entry to /boot/grub/menu.lst :

###Don't change this comment - YaST2 identifier: Original name: WindowsBootLoader###
title Windows on /dev/sda1
    rootnoverify (hd0,0)
    chainloader +1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 - searching partition /dev/sda2      (NTFS)          ...

********************************************************************************
WARNING: /boot/grub/device.map not found.
         Displayed BIOS device mapping may be incorrect!
********************************************************************************

Press <enter> to Exit findgrub...

So, NO MORE ERRORS found!!
Comment 17 Reartes Guillermo 2012-12-12 13:51:42 EST
The NTFS resize process can be divied in two:
* FILESYSTEM resize level, performed by NTFSRESIZE
* PARTITION resize level, performed by ANACONDA (??) or MANUALLY (fdisk)


Results of the TESTS:

* TEST#2: Demostrated that it is not a size issue because:

  2-A: Manual resize of the FILESYSTEM (using NTFSRESIZE) (using minimum size: 11798M)
  2-A: FILESYSTEM resize steps were taken from ANACONDA's 'program.log' so they are the SAME.

  2-B: Manual resize of the PARTITION (using FDISK) (using minimum size: 11798M)
  
  RESULT: The Win7 boots, performs a chkdsk, reboots, and then boots ok.

  
* TEST#4: Demostrated that it is not a size issue because:

  4-A: Manual resize of the FILESYSTEM (using NTFSRESIZE) (using size: 12322M)
  4-A: FILESYSTEM resize steps were taken from ANACONDA's 'program.log' so they are the SAME.
  
  4-B: Manual resize of the PARTITION (using FDISK) (using size: 12322M)
  
  RESULT: The Win7 boots, performs a chkdsk, reboots, and then boots ok.
  So the size selected by anaconda (12322M) is in fact, OK.

* TEST#5:

  5-A: Anaconda performs the resize of the FILESYSTEM (using NTFSRESIZE) (using size: 12322M)
  5-A is known to work in TEST#4.

  5-B: Anaconda performs the resize (?) of the PARTITON (using ??) 
  5-B: More info is needed on what is anaconda doing.
  5-B: 'findgrub' found errors in the ntfs partition that seems to point to the partition table

  5-C: Manual deletion of all linux partitions after F18 installation, prior to reboot. 
  5-C: Manual resize of the PARTITION (using FDISK) (using size: 12322M)
  5-C: 'findgrub' does not encounter any errors...
  
  RESULT: The Win7 boots, performs a chkdsk, reboots, and then boots ok.

* TEST#3: FOUND, After TEST#5, it is clear that the problem is in the partiton table generated by anaconda.
  
  3-A: Anaconda performs the resize of the FILESYSTEM (using NTFSRESIZE) (using size: 12322M)
  3-A is known to work in TEST#4.
  
  3-B: Anaconda performs the resize (?) of the PARTITON (using ??) 
  3-B: More info is needed on what is anaconda doing.
  3-B: 'findgrub' found errors in the ntfs partition that seems to point to the partition table
  
  RESULT: The Win7 boots, it does not perform any chkdsk, then it does a BSOD.
  
  BUG: The END_SECTOR for the resized NTFS partiton is WRONG.
Comment 18 Reartes Guillermo 2012-12-12 13:52:47 EST
I will propose it as a blocker since it involves potential filesystem corruption and broken widozes

The following should be assesset before rejecting the bug as a blocker:

* The W7 guest uses the most common partition. By default it creates a 
small and a big ntfs partitions.

* Since the bug is in the partition table part of the resize process, it is not
clear how many systems / configurations might be affected by it.

* When encountered, affected systems will not be able to boot and there might be
data loss.
Comment 19 Chris Murphy 2012-12-13 22:19:39 EST
This is a dup of 885912, even though it comes a month earlier.
Comment 20 Vratislav Podzimek 2012-12-14 06:25:10 EST
(In reply to comment #19)
> This is a dup of 885912, even though it comes a month earlier.
Agreed, closing this one as duplicate of 885912. Both bugs contain valuable data, but they are about the same issue.

*** This bug has been marked as a duplicate of bug 885912 ***