Description of problem: QA:Testcase dualboot with windows - F18-TC1 Auto Partition Does not create Working Dual Boot System while Manual Partition does create a working system. Version-Release number of selected component (if applicable): F18-Final-TC1 How reproducible: QA:Testcase dualboot with windows Steps to Reproduce: 1. Install Windows XP to Fresh VM 2. Launch F18 Installer 3. Choose Shrink NTFS Partition and Automatic Partitioning Actual results: A system with only Fedora in Grub menu is offered Expected results: Dual Boot Grub options Additional info:
I would vote this if F18-NTH but not a Final Blocker as a technical following of the QA Test Case produces a working result. It may be confusing for the neophyte end user however when auto partitioning appears to be working not to encounter this problem.
Thanks for your report. This sounds like an clear F18 blocker under this release criterion[1]: 9. The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working You can propose this bug as an F18 blocker by adding the F18Blocker bug alias[2] to the Blocks field for this bug. BTW, the developers are going to want to see the log files. They should be in /var/log/anaconda/. [1] Fedora 18 Final Release Criteria https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria [2] http://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
I am working to recreate as I type this. When I tested with manual partitioning and x86_64 I got results similiar to i386 with auto partitioning. Chasing a theory that libvirtd caused the issue and not f18. I'll post more as I get data. Biggest problem is lack of drive space and each test vm takes 30GB.
Thanks for your update. This sounds like a related bug: Bug 875944 - shrinking Windows partition creates an unusable dual-boot setup
I am finishing testing a dual boot with automatic partitioning and now have a working theory that if the shrink function steps on the minimum space needed by XP that it does not respond to os-probe and thus fails. If I use a 30GB disk and reduce windows to 18GB and have 12GB for Fedora then dual isntall fails. If I use a 40GB disk and reduce windows to 28GB and have 12GB for Fedora then Dual Install Works. I'll be posting anaconda log files later this morning or afternoon. That other bug could be related. -- I'll leave that to the real experts aka developers.
Created attachment 661462 [details] Compressed File with contents of /var/log/anaconda from non-working attempt From the non workign Dual Boot Instance
Created attachment 661477 [details] Compressed File of logs from Working attempt - /var/log/anaconda System is identical between working and non-working except one is i386 other is x8664 and one was auto-part other was manual part.
Update - I am keeping the i386 non-working model and x86_64 working model idle and untouched in case folks need more information from them. I did have a working i386 but had to delete it for space to test x8664. Bottom line Auto partition creates a system without a Windows Grub entry and Manual Partiton works as expected for Dual Boot Shrink install on XP.
+1 Final blocker. (I remember getting libvirtd errors on my i386 installs but I never tried to reproduce it or track it down.)
Discussed at 2012-12-12 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-12/f18final-blocker-review-4.2012-12-12-17.01.log.txt . We agreed we cannot determine the status of this bug until we're sure what the trigger is - is it the size of the Windows partition, automatic vs. manual partitioning, or something else. Bob, it would help if you could post the resulting partition tables of the broken and working cases (with parted or fdisk). I will try and find time to try and reproduce this and see if I can figure what's going on.
parted from non working system -- (parted) print all Model: ATA QEMU HARDDISK (scsi) Disk /dev/sda: 42.9GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 3555MB 3555MB primary ntfs boot 2 3555MB 4079MB 524MB primary ext4 3 4079MB 42.9GB 38.9GB primary lvm Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/fedora-swap: 2114MB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 2114MB 2114MB linux-swap(v1) Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/fedora-root: 36.8GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 36.8GB 36.8GB ext4 (parted)
fdisk -l output from defective system -- [root@localhost ~]# fdisk -l Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 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: 0x25c325c3 Device Boot Start End Blocks Id System /dev/sda1 * 63 6942719 3471328+ 7 HPFS/NTFS/exFAT /dev/sda2 6942720 7966719 512000 83 Linux /dev/sda3 7966720 83886079 37959680 8e Linux LVM Disk /dev/mapper/fedora-swap: 2113 MB, 2113929216 bytes, 4128768 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 /dev/mapper/fedora-root: 36.8 GB, 36754685952 bytes, 71786496 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 [root@localhost ~]#
parted output from working system --- [root@localhost ~]# parted -l Model: ATA QEMU HARDDISK (scsi) Disk /dev/sda: 42.9GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 29.4GB 29.4GB primary ntfs boot 2 29.4GB 29.9GB 524MB primary ext4 3 29.9GB 42.9GB 13.1GB primary lvm Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/fedora-swap: 2114MB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 2114MB 2114MB linux-swap(v1) Model: Linux device-mapper (linear) (dm) Disk /dev/mapper/fedora-root: 10.9GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 10.9GB 10.9GB ext4 [root@localhost ~]#
fdisk from working system -- [root@localhost ~]# fdisk -l Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 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: 0x14691469 Device Boot Start End Blocks Id System /dev/sda1 * 63 57343999 28671968+ 7 HPFS/NTFS/exFAT /dev/sda2 57344000 58367999 512000 83 Linux /dev/sda3 58368000 83886079 12759040 8e Linux LVM Disk /dev/mapper/fedora-swap: 2113 MB, 2113929216 bytes, 4128768 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 /dev/mapper/fedora-root: 10.9 GB, 10947133440 bytes, 21381120 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 [root@localhost ~]#
(In reply to comment #11) ... > Number Start End Size Type File system Flags > 1 32.3kB 3555MB 3555MB primary ntfs boot > 2 3555MB 4079MB 524MB primary ext4 > 3 4079MB 42.9GB 38.9GB primary lvm ... For the record, Windows XP requires: "At least 1.5 gigabytes (GB) of available space on the hard disk" System requirements for Windows XP operating systems http://support.microsoft.com/kb/314865
My Computer from the working system shows 27.3 GB of space and 24.7 GB of free space. A dir from C:\ shows 26,596,126,720 bytes free . This would see to suggest that auto-partition did not take into account the 1.5 GB Free requirement Steve Tyler mentions above.
Published Windows space requirements are basically useless. the 1.5GB is a theoretical minimum amount of disk space needed for a fresh install (which, more to the point, Microsoft more or less pulled out of their asses). In general, though, the fact that an existing, dirty Windows partition got squished down to 3.5GB in size rings all kinds of alarm bells for me. That's pretty small. Can you hack up a correct bootloader entry and try booting that copy of Windows and see if it actually works? Can you run the grub os-detect script on the broken system manually and see if you can get any useful output from it to indicate why it fails?
According to Comment 0, Robert is doing fresh Windows XP installs. Windows XP has some recovery tools, so it might be possible to get it booted that way. The overzealous NTFS squishing appears to be reported here: Bug 875944 - shrinking Windows partition creates an unusable dual-boot setup
Created attachment 662763 [details] Grub2 Windows Section from Working System I "borrowed" this grub.cfg section 30 from the working system and ported it blindly to the broken one since the windows isntalls were identical as far as I can tell on the surface. It squawked about and item 1C90E7... not existing but went on and tried to boot ending in a BSOD message about an unmountable_boot_volume. It suggested a restart in safe mode which resulted in the same BSOD after loading mup.sys. I am about to RTFM on os-prober and play around on the fedora side of the broken dual boot. Adam if you have a specific set of os-prober commands you can recommend it will probably save us all some time. I am thinking I might need to change that 1C90E7.... device string to whatever os-prober sees as the the broken windows device number. Any recommended reading on Grub2 windows boot syntax would also be appreciated guaidance here for me.
it kinda does sound like somehow the windows install has been squished too far - if Windows actually tries to boot, you got the grub config right, you can't fix a Windows BSOD by fiddling with grub config. for os-prober just look at the script grub2 uses - /etc/grub.d/30_os-prober
Adam the line OSPROBED="`os-prober | tr ' ' '^' | paste -s -d ' '`" leads me to believe the command I want is something like os-prober | tr ' ' '^' | paste -s -d ' ' but this returns nothing but a blank line, which kind of lines up with the 30 section being empty on the broken system. Am I missing something here?
mounted a CD holding the Windows XP Install Cd and entered rescue mode. chkdsk returns the nice message "the volume appears to contain one or more unrecoverable errors". I was considering a bootcfg, fixboot or fixmbr command might yield something, but I'll wait to see what others think as the fixboot and fixmbr are probably irreversable except to reisntall and repeat the whole test case.
For reference, here is the Windows XP partitioning for an install to a 40 GiB VM disk image[1]. Note that there is a 13.7 MB free space at the end. Based on past experience, the Windows XP installer reserves some free space at the end. That free space has been consumed by sda3 according to the fdisk reports in Comment 12 and Comment 14. [root@localhost xfr]# parted /dev/sda print free Model: ATA QEMU HARDDISK (scsi) Disk /dev/sda: 42.9GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 42.9GB 42.9GB primary ntfs boot 42.9GB 42.9GB 13.7MB Free Space [root@localhost xfr]# fdisk -l /dev/sda Disk /dev/sda: 42.9 GB, 42949672960 bytes, 83886080 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: 0x3ceb3ceb Device Boot Start End Blocks Id System /dev/sda1 * 63 83859299 41929618+ 7 HPFS/NTFS/exFAT [root@localhost xfr]# [1] Created with: $ qemu-img create winxp-test-1.img 40G $ qemu-kvm -m 2048 -hda winxp-test-1.img -cdrom ~/xfr/fedora/winxp/winxp-1.iso -usb -vga qxl -boot menu=on -usbdevice mouse -rtc base=localtime
What does the Windows XP recovery console report for the working system?
Can you mount either NTFS file system from the Live CD?
Linux has a variety of NTFS tools, and they are available on the Live CD: # rpm -ql ntfsprogs # ntfsinfo -m /dev/sda1
boblfoot: it all kinda lines up with the theory that the resize was too aggressive, really, but you might be able to get more details from os-prober by running it through sh -x.
output of sh -x os-prober Blah Blah http://fpaste.org/a743/ [root@localhost ~]# sh -x os-prober | tr ' ' '^' | paste -s -d ' ' + set -e + . /usr/share/os-prober/common.sh ++ cleanup_tmpdir=false ++ cleanup_ro_partitions= ++ progname= ++ type mapdevfs + newns + '[' '' ']' + exec /usr/libexec/newns os-prober [root@localhost ~]#
Steve Tyler - ntfsinfo -m /dev/sda1 returns [root@localhost ~]# ntfsinfo -m /dev/sda1 Failed to read last sector (6943344): 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/sda1': Invalid argument The device '/dev/sda1' doesn't have a valid NTFS. Maybe you selected the wrong device? Or the whole disk instead of a partition (e.g. /dev/hda, not /dev/hda1)? Or the other way around? Failed to open '/dev/sda1'. [root@localhost ~]#
(In reply to comment #29) > Steve Tyler - ntfsinfo -m /dev/sda1 returns > [root@localhost ~]# ntfsinfo -m /dev/sda1 > Failed to read last sector (6943344): Invalid argument ... > or the partition table is corrupt (partition is smaller than NTFS), ... Awesome! After resizing, the partition gets shrunk ... that could have gone wrong instead of the ntfsresize.
also the output from ntfsfix -n shows promise in the end. [root@localhost ~]# ntfsfix -n /dev/sda1 Mounting volume... Failed to read last sector (6943344): 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 Attempting to correct errors... Failed to read last sector (6943344): 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 Failed to startup volume: Invalid argument Failed to read last sector (6943344): 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). Trying the alternate boot sector The alternate bootsector is usable Set sector count to 6942656 instead of 6943344 The startup data can be fixed, but no change was requested Volume is corrupt. You should run chkdsk. No change made [root@localhost ~]#
steve: well yeah the partition has to be resized, otherwise the shrink doesn't actually free up any space.
Running ntfsfix for real and then sh -x os-prober yields some other better data. Trying the alternate boot sector The alternate bootsector is usable Set sector count to 6942656 instead of 6943344 Rewriting the bootsector The boot sector has been rewritten Processing $MFT and $MFTMirr... Reading $MFT... OK Reading $MFTMirr... OK Comparing $MFTMirr to $MFT... OK Processing of $MFT and $MFTMirr completed successfully. Setting required flags on partition... OK Going to empty the journal ($LogFile)... OK NTFS volume version is 3.1. NTFS partition /dev/sda1 was processed successfully. [root@localhost ~]# sh -x os-prober | tr ' ' '^' | paste -s -d ' ' + set -e + . /usr/share/os-prober/common.sh ++ cleanup_tmpdir=false ++ cleanup_ro_partitions= ++ progname= ++ type mapdevfs + newns + '[' '' ']' + exec /usr/libexec/newns os-prober /dev/sda1:Microsoft^Windows^XP^Home^Edition:Windows:chain [root@localhost ~]# grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub.cfg ... Found theme: /boot/grub2/themes/system/theme.txt Found linux image: /boot/vmlinuz-3.6.9-4.fc18.i686.PAE Found initrd image: /boot/initramfs-3.6.9-4.fc18.i686.PAE.img Found Microsoft Windows XP Home Edition on /dev/sda1 done
And that windows boots and My Computer shows C: Drive as 3.3GB big with 768 mb of free space. This won't run well for long now will it. Definitely agressive shrink.
That's excellent. The NTFS file system is being corrupted at the end, but it may not be the fault of the ntfsresize command: After minimizing the NTFS file system using the ntfsresize command on the F18 TC1 Live CD, Windows XP reboots, runs chkdsk, and reboots to the Windows desktop. The ntfsresize command alone does not explain the problem with the installer resize operation. Procedure from the F18 TC1 Live CD: # ntfsresize -m /dev/sda1 # get minimum size XXXX in MB # ntfsresize -s XXXXM /dev/sda1 NB: This was done entirely from the Live CD. The installer was not run at all.
(In reply to comment #34) > And that windows boots and My Computer shows C: Drive as 3.3GB big with 768 > mb of free space. This won't run well for long now will it. Definitely > agressive shrink. Windows XP is reporting Low Disk Space after the ntfsresize to the minimum. The warning says that: "System Restore has suspended tracking changes ..." Resizing to the minimum is definitely not something that should be done automatically without the user being notified first.
no kind of resize gets done 'automatically', you have to specifically request it through custom part or the reclaim space dialog.
(In reply to comment #33) > Running ntfsfix ... ... > Set sector count to 6942656 instead of 6943344 ... Let's do the math ... :-) 1. anaconda.program.log for non-working case (Comment 6): ... 03:25:41,942 INFO program: Running... ntfsresize -ff -s 3555M /dev/sda1 ... 03:25:42,063 INFO program: New volume size : 3554992640 bytes (3555 MB) ... The new file system has 3554992640/512 = 6943345 sectors. 2. Partitioning for non-working case (Comment 12): Device Boot Start End Blocks Id System /dev/sda1 * 63 6942719 3471328+ 7 HPFS/NTFS/exFAT /dev/sda2 6942720 7966719 512000 83 Linux /dev/sda3 7966720 83886079 37959680 8e Linux LVM The sda1 partition sector count is 6942719-63+1 = 6942657 sectors. 3. Conclusion: The partition is smaller than the file system. NB: I'm not sure why ntfsfix is reporting one sector less in each case. Thanks, Bob and Adam, for helping get this figured out.
Not a problem steve. As I told Adam in #fedora-qa. I came to use Fedora and then Centos after starting with a double boot xp/fedora system. That is why this test case is always on my radar. I know of setting up double had not been easy back in Fedora8 I'd still be a doze only user.
Looks like anaconda is having parted set the partition size in the MBR contrary to the ntfsresize command. storage.log 15:39:23,303 DEBUG storage: fixing size of existing 12866MB partition sda2 (3) with existing ntfs filesystem at 12866.00 program.log 15:38:31,998 INFO program: ntfsresize v2012.1.15 (libntfs-3g) 15:38:31,999 INFO program: Minsize (in MB): 12967 … 15:39:32,957 INFO program: Running… ntfsresize -ff -s 13491M /dev/sda2
Created attachment 663208 [details] anaconda program.log Windows 7 default installation (2 partition) to 750GB virtual disk, followed by default installation of Fedora 18 with anaconda 18.37.2-1 using autopart.
Created attachment 663209 [details] anaconda storage.log Windows 7 default installation (2 partition) to 750GB virtual disk, followed by default installation of Fedora 18 with anaconda 18.37.2-1 using autopart.
*** Bug 875484 has been marked as a duplicate of this bug. ***
Adam, in Comment 10 you said "We agreed we cannot determine the status of this bug until we're sure what the trigger is ..." and I am curious as to whether the additional posts have met your requirement, answered your question? Thanks.
(In reply to comment #43) > *** Bug 875484 has been marked as a duplicate of this bug. *** Reartes did a superb job of analyzing this bug. In Bug 875484, Comment 17 he concludes that: ... * TEST#3: FOUND, After TEST#5, it is clear that the problem is in the partiton table generated by anaconda. ... BUG: The END_SECTOR for the resized NTFS partiton is WRONG.
Does anyone have a setup available for testing? If so, please let me know what version of anaconda you're using so I can supply an updates.img with some more targeted logging.
I have the w7 guest for testing, since i made a backup of the disk. I have F18-TC2, smoke5, smoke6 or F18-TC1.
Fedora-18-TC2-x86_64-Live-Desktop.iso has anaconda 18.37.2-1. That's what I'd be using.
If you can use updates=http://clumens.fedorapeople.org/885912.img against the TC2 image containing anaconda-18.37.2-1 and attach /tmp/storage.log to this bug report, it would be very helpful. Thanks. You'll need to at least schedule the resizing, though you may not need to actually move to the second hub.
Created attachment 663804 [details] storage.log w/ targeted logging updates=http://clumens.fedorapeople.org/885912.img applied
Created attachment 663805 [details] storage.log with updates applied (i do not performed the installation)
(In reply to comment #46) > Does anyone have a setup available for testing? If so, please let me know > what version of anaconda you're using so I can supply an updates.img with > some more targeted logging. I have a pair of windows xpsp2 vm and the full DVD of TC2 in both i386 and x86_64 and will be available for testing over the weekend sometime after 2300 Friday. Please provide desired test protocols if you can.
(In reply to comment #50) FWIW logs in comment 41, 42 are from the same VM snapshot state as the log in comment 50. 15:41:14,744 INFO program: New volume size : 13490995712 bytes (13491 MB) Which is 26349601 sectors. Plus sda2 start LBA 206848 should be an end LBA 26556449. However: 15:41:23,873 INFO storage: !!! _computeResize: aligned end sector to 26556415 Which is what fdisk reports and is 34 sectors too short.
Paul: we haven't had another blocker review meeting since then. If we had, there would be a note of the decision on the bug. All blocker status discussions are documented in the bug.
F18 - TC2 - i386 - DVD .iso with clumens updates img notes 1. adding just updates=http://clumens.fedorapeople.org/885912.img results in a cannot download error and a drop into DRACUT. Have to add ksdevice=eth0 as well to get updated to download. 2. Fresh Install of xpsp2 to 40gb vm. Used automatic partitioning and shrink of ntfs partition resulting in system with no windows boot entry. Suspect this system is identical to the TC1 system. 3. Logs to follow :
Created attachment 663921 [details] F18-TC2-I386-ClumensUpdateImg-Anaconda-ifcfg.log F18-TC2-I386-ClumensUpdateImg-Anaconda-ifcfg.log
Created attachment 663922 [details] F18-TC2-I386-ClumensUpdateImg-Anaconda.log F18-TC2-I386-ClumensUpdateImg-Anaconda.log
Created attachment 663923 [details] F18-TC2-I386-ClumensUpdateImg-Anaconda.packaging.log F18-TC2-I386-ClumensUpdateImg-Anaconda.packaging.log
Created attachment 663924 [details] F18-TC2-I386-ClumensUpdateImg-Anaconda.storage.log F18-TC2-I386-ClumensUpdateImg-Anaconda.storage.log
Created attachment 663925 [details] F18-TC2-I386-ClumensUpdateImg-Syslog F18-TC2-I386-ClumensUpdateImg-Syslog
Log Files ks-script-1PE9nO.log ks-script-ehMK75.log ks-script-HANaik.log were 0 bytes in size and not uploaded for F18-TC2-i386
Created attachment 663926 [details] F18-TC2-x8664-ClumensUpdateImg-Anaconda-ifcfg.log
Created attachment 663927 [details] F18-TC2-x8664-ClumensUpdateImg-Anaconda.log
Created attachment 663928 [details] F18-TC2-x8664-ClumensUpdateImg-Anaconda.packaging.log
Created attachment 663929 [details] F18-TC2-x8664-ClumensUpdateImg-Anaconda.storage.log
Created attachment 663930 [details] F18-TC2-x8664-ClumensUpdateImg-Anaconda.xlog
Created attachment 663931 [details] F18-TC2-x8664-ClumensUpdateImg-Syslog
Created attachment 663932 [details] F18-TC2-i386-ClumensUpdateImg-Anaconda.xlog
files ks-script-V2Bz_G.log ks-script-varPAJ.log ks-script-_YCcAo.log were 0 bytes and not upliaded F18-TC2-ClumensUpdate.img
All I needed was storage.log, which I've not got several of. I think we're good on data for this bug report now.
Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Accepted as a blocker per criterion "All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs" - this bug can badly damage an existing Windows partition.
Could anyone who's got this still set up try testing again with updates=http://clumens.fedorapeople.org/885912.img and see if it works? We've got a fairly cheesy fix that I'm hoping will work without introducing any new problems.
Created attachment 665739 [details] storage.log Reply to comment 72. Inadvertently applied update to anaconda-18.37.3-1, instead of 18.37.2-1. But it does work, the Windows install isn't nerfed; the auto chkdsk on reboot to Windows completes with no errors, subsequently reboots to Windows successfully.
Created attachment 665747 [details] storage.log Reply to comment 72. This one applied against anaconda 18.37.2-1. Same results.
Created attachment 665772 [details] storage.log (AFTER INSTALL) F18 TC2 with updates image I tried with the same w7 guest. W7 did boot, did the chkdsk stuff,then reboot, and then it booted normally. (In addition, the boot-loader was installed properly)
anaconda-18.37.4-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.37.4-1.fc18
anaconda-18.37.4-1.fc18 appears to fix this bug.
Package anaconda-18.37.4-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.37.4-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20677/anaconda-18.37.4-1.fc18 then log in and leave karma (feedback).
anaconda-18.37.4-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
We need to verify this is really fixed. Reartes, could you please try again with the smoke9 images? http://dl.fedoraproject.org/pub/alt/qa/20121219_f18-smoke9/ Thanks!
Kamil: see comment #77.
Created attachment 667033 [details] storage.log (AFTER INSTALL) F18 smoke9 I tried twice, and both times w7 guest was able to perform both the chkdsk and then boot normally. The second time i tested without installing a boot loader and it also worked. (attached storage.log).
(In reply to comment #81) > Kamil: see comment #77. I missed that one. (In reply to comment #82) > Created attachment 667033 [details] > storage.log (AFTER INSTALL) F18 smoke9 > > I tried twice, and both times w7 guest was able to perform both the chkdsk > and then boot normally. > > The second time i tested without installing a boot loader and it also > worked. (attached storage.log). Thank you very much for verification.
This problem maybe solved - I cannot prove it with my XPSP3-NTFS VM however and smoke12 encountered another dual boot problem 889896.