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.
Created attachment 644244 [details] anaconda.log (BEFORE INSTALL)
Created attachment 644245 [details] anaconda.log (AFTER INSTALL)
Created attachment 644246 [details] program.log (BEFORE INSTALL)
Created attachment 644247 [details] program.log (AFTER INSTALL)
Created attachment 644248 [details] storage.log (BEFORE INSTALL)
Created attachment 644249 [details] storage.log (AFTER INSTALL)
Created attachment 644252 [details] storage.log (AFTER INSTALL)
This is still valid with F18b RC1.
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.
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.
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.0.10:~/findgrub . # chmod +x ./findgrub # scp root.0.10:/usr/bin/tput /usr/bin/ # scp root.0.10:/usr/bin/getopt /usr/bin/ # scp root.0.10:/usr/bin/hexdump /usr/bin/ I will put each TEST in its own comment.
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
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
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
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
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!!
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.
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.
This is a dup of 885912, even though it comes a month earlier.
(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 ***