Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Anaconda does not assign correct root partition to boot windows|
|Product:||[Fedora] Fedora||Reporter:||Antonio A. Olivares <olivares14031>|
|Component:||anaconda||Assignee:||Hans de Goede <hdegoede>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||12||CC:||awilliam, beland, ddumas, eddie, hdegoede, irishmangoes, meyering, orion, vanmeeuwen+fedora, vedran|
|Target Milestone:||---||Keywords:||CommonBugs, Reopened|
|Fixed In Version:||parted-2.1-8.fc13||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||588664 (view as bug list)||Environment:|
|Last Closed:||2010-05-06 02:55:41 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||583628|
Description Antonio A. Olivares 2009-11-10 08:43:01 EST
Description of problem: When installing on a system with a restore partition, anaconda? assigns it the windows name leaving windows unbootable :( [root@acer-aspire-1 ~]# fdisk -l Disk /dev/sda: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xd2107a38 Device Boot Start End Blocks Id System /dev/sda1 1 784 6297448+ 12 Compaq diagnostics /dev/sda2 * 785 11350 84867072 7 HPFS/NTFS /dev/sda3 11350 11375 204800 83 Linux /dev/sda4 11376 19457 64918665 5 Extended /dev/sda5 11376 19457 64918528 8e Linux LVM Disk /dev/dm-0: 64.4 GB, 64395149312 bytes 255 heads, 63 sectors/track, 7828 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Disk /dev/dm-0 doesn't contain a valid partition table Disk /dev/dm-1: 2080 MB, 2080374784 bytes 255 heads, 63 sectors/track, 252 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Disk /dev/dm-1 doesn't contain a valid partition table [root@acer-aspire-1 ~]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,2) # kernel /vmlinuz-version ro root=/dev/mapper/vg_aceraspire1-lv_root # initrd /initrd-version.img #boot=/dev/sda default=0 timeout=5 splashimage=(hd0,2)/grub/splash.xpm.gz hiddenmenu title Fedora (188.8.131.52-122.fc12.i686) root (hd0,2) kernel /vmlinuz-184.108.40.206-122.fc12.i686 ro root=/dev/mapper/vg_aceraspire1-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge initrd /initramfs-220.127.116.11-122.fc12.i686.img title Fedora (18.104.22.168-117.fc12.i686) root (hd0,2) kernel /vmlinuz-22.214.171.124-117.fc12.i686 ro root=/dev/mapper/vg_aceraspire1-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge initrd /initramfs-126.96.36.199-117.fc12.i686.img title Fedora (188.8.131.52-115.fc12.i686) root (hd0,2) kernel /vmlinuz-184.108.40.206-115.fc12.i686 ro root=/dev/mapper/vg_aceraspire1-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge initrd /initramfs-220.127.116.11-115.fc12.i686.img title Fedora (18.104.22.168-96.fc12.i686) root (hd0,2) kernel /vmlinuz-22.214.171.124-96.fc12.i686 ro root=/dev/mapper/vg_aceraspire1-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge initrd /initramfs-126.96.36.199-96.fc12.i686.img title Fedora (188.8.131.52-56.fc12.i686) root (hd0,2) kernel /vmlinuz-184.108.40.206-56.fc12.i686 ro root=/dev/mapper/vg_aceraspire1-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge initrd /initramfs-220.127.116.11-56.fc12.i686.img title Fedora (18.104.22.168-48.fc12.i686) root (hd0,2) kernel /vmlinuz-22.214.171.124-48.fc12.i686 ro root=/dev/mapper/vg_aceraspire1-lv_root SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us rd_plytheme=charge initrd /initramfs-126.96.36.199-48.fc12.i686.img title windows xp rootnoverify (hd0,1) chainloader +1 title Acer Restore rootnoverify (hd0,0) chainloader +1 The fix is to change the (hd0,0) to (hd0,1) or (hd0,X) where windows partition(C:\ ) resides. Version-Release number of selected component (if applicable): anaconda-12.46-1.fc12.i686 ??? How reproducible: Install Fedora unto a machine with windows and a restore partition like Emachines 1161-05, or acer aspire one netbook. Steps to Reproduce: 1. make free space in windows partition, scandisk/defragment 2. let fedora resize ntfs partition, it worked beautifully :) 3. install it and let it configure bootloader. It assigns Other (hd0,0) or windows to restore partition. Actual results: mapped windows partition incorrectly Expected results: I expected anaconda to get this right, but it was fixable Additional info: upon request.
Comment 1 Chris Lumens 2009-11-10 09:26:27 EST
We can't fix this, because we do not have the information to make this kind of decision. The "System" column from your fdisk output above is not exported to anaconda by parted/pyparted because it really only means something on the msdos disk type, and that's what we'd require to make this decision. In all other ways, your first partition look exactly like a Windows partition so anaconda believes it is one.
Comment 2 Denise Dumas 2009-11-11 15:59:36 EST
We should note somewhere that this problem exists, and document the procedure to fix it.
Comment 3 Adam Williamson 2009-11-12 12:24:00 EST
This sucks, and I'd much rather we do something about it :) Options: a) ask parted developers to export the necessary property, for msdos disk types. This would seem best. b) if a system has two Windows-type partitions and we haven't a clue what's on which, notify the user and ask. I realize this is a sucky question for many users, but for those kinds of users, having Fedora provide a bootloader option which goes into a strange interface they've never seen before, from which they could easily wind up wiping all their Windows data, is even more sucky. This is a better-of-two-evils situation. c) do some kind of detection; fr'instance, you can spot an actual Windows partition, almost all the time, by looking for a few common first-level directory names (\WINDOWS and \WINNT , fr'instance, I'm sure there's a list out there somewhere to steal). This would allow us to pick at least _a_ Windows partition correctly in the vast majority of cases. Abusing my power to re-open the bug, just this one time. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 4 Adam Williamson 2009-11-12 12:30:39 EST
oh, you could also try a size-based heuristic: rescue partitions are usually small. on a reasonably modern system, the primary Windows partition is extremely unlikely to be 5GB or less in size, but recovery partitions almost always are. I'd bet that heuristic would cover the vast majority of situations, a lot better than we do now anyway. It could be refined a little for odd cases, like really old systems. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 5 Adam Williamson 2009-11-12 12:32:30 EST
(although I note in the case above the recovery partition is 6GB. sigh. what the hell are Compaq putting in there?!) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 6 Adam Williamson 2009-11-12 12:34:18 EST
oh, and of course there's the rather cogent point in 537155: the real Windows partition is almost certainly the one marked 'bootable' at the start of the process. Just keep that assignment, if you have no pressing reason to override it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 7 Adam Williamson 2009-11-12 13:29:22 EST
hansg, the summary is that we would like parted to provide the extended partition information available for msdos-type partitions, that is used by fdisk to identify the recovery partition (see the initial description's fdisk output). Currently parted doesn't provide this info to anaconda. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 8 Adam Williamson 2009-11-12 13:31:48 EST
just so it's not lost, in case it's at all useful, Mandriva guys pointed out to me that HAL has (had, I guess, now...) a heuristic for spotting recovery partitions. Just look for labels: 'RECOVERY', 'PQSERVICE', 'HP_RECOVERY', 'Recovery Partition', 'DellUtility', 'DellRestore', 'IBM_SERVICE', 'SERVICEV001', 'SERVICEV002' (from /usr/share/hal/fdi/policy/10osvendor/20-storage-methods.fdi ). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 9 Adam Williamson 2009-11-12 13:35:12 EST
mdv's code is in http://svn.mandriva.com/svn/soft/drakx/trunk/perl-install/fs/type.pm , look for "sub isRecovery". -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 10 Hans de Goede 2009-11-13 04:53:16 EST
Chris, I don't see why this was changed to be a parted bug, as explained by yourself in comment #1, exporting the raw fs type byte from parted is not something which fits well in parted's model of abstracting partition tables. Also as already said in other comments, a good solution would be to simply select which partition has the active flag set, which is already exported by parted. Changing component back to anaconda. Not sure who to assign this to, so I'll just leave it assigned to the team for now.
Comment 11 Chris Lumens 2009-11-16 09:30:52 EST
Hans - I'd much rather use the fs type bytes from parted even if they're a little weird there than to use some heuristic that just seems like asking for future problems.
Comment 12 Hans de Goede 2009-11-17 03:30:47 EST
(In reply to comment #11) > Hans - I'd much rather use the fs type bytes from parted even if they're a > little weird there than to use some heuristic that just seems like asking for > future problems. Hmm, but that will only work for msdos disk labels. How about putting the knowledge which msdos System ID is a rescue type inside parted and adding a "rescue" flag which can be queried on partitions ?
Comment 13 Hans de Goede 2009-11-23 07:38:36 EST
Chris, any comments on my suggestion done in comment #12 ?
Comment 14 Eddie Lania 2009-11-26 12:37:33 EST
Hello to you all, My bug 539886 "preupgrade of F11 to F12 has overwritten my boot sector" seems to be a duplicate of this? Anyway, why is it not possible for a user (like me) to influence the boot options at install or preupgrade time? Because: I was pretty surprised after running preupgrade that my other OS's were not bootable anymore (see my bug). I did not at least aspect that, while before the upgrade I already had a working boot to my linux OS, it still was being changed without any warning afterwards. Regards, Eddie.
Comment 15 Hans de Goede 2009-11-27 05:08:47 EST
(In reply to comment #14) > Hello to you all, > > My bug 539886 "preupgrade of F11 to F12 has overwritten my boot sector" seems > to be a duplicate of this? > No, this is a different issue, for further discussion of your issue see bug 539886.
Comment 16 Christopher Beland 2010-02-12 16:20:33 EST
Nominating as F13 blocker due to criterion 6:"The installer must be able to install alongside 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"
Comment 17 Chris Lumens 2010-04-16 11:30:01 EDT
> Hmm, but that will only work for msdos disk labels. How about putting the > knowledge which msdos System ID is a rescue type inside parted and adding a > "rescue" flag which can be queried on partitions ? That seems like a decent idea to me. Let me know what interface you decide upon and I can make the changes to pyparted as well.
Comment 18 Adam Williamson 2010-04-23 12:18:09 EDT
Discussed at 04/16 and 04/23 blocker meetings. Agreed to be a blocker. Current status is that we expect anaconda team to move ahead with hansg's suggestion, in time for final release. Thanks! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 19 Hans de Goede 2010-04-25 10:09:00 EDT
(In reply to comment #18) > Discussed at 04/16 and 04/23 blocker meetings. Agreed to be a blocker. Current > status is that we expect anaconda team to move ahead with hansg's suggestion, > in time for final release. Thanks! > Hi the necessary parted and pyparted changes are in place, so now we just need anaconda team member who is familiar with the code in question to make use of the new PED_PARTITION_DIAG flag.
Comment 20 Hans de Goede 2010-05-03 11:42:45 EDT
As there seem to be no takers, I'll take this one. Patch coming up.
Comment 21 Hans de Goede 2010-05-04 04:54:03 EDT
This should be fixed in anaconda-13.40-1, moving to modified.
Comment 22 Adam Williamson 2010-05-04 18:30:24 EDT
This updates.img should include the fix for the bug: http://people.fedoraproject.org/~jwrdegoede/f13-updates.img Can someone please test with that? (I can't; ironically, this F13 install was done over the top of the rescue partition on this system, it's the only spare space :>)
Comment 23 Fedora Update System 2010-05-05 01:16:12 EDT
anaconda-13.40-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13
Comment 24 Fedora Update System 2010-05-05 03:22:43 EDT
anaconda-13.40-1.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update anaconda'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13
Comment 25 Adam Williamson 2010-05-05 12:58:29 EDT
We should now be able to confirm that this bug is fixed using the images here: http://alt.fedoraproject.org/pub/alt/stage/13.0505/Fedora/i386/os/images/ if we have not yet confirmed the fix, can anyone able to reproduce this bug please test with one of those images and check that the bug is fixed? Thanks.
Comment 26 Orion Poplawski 2010-05-05 16:40:52 EDT
I used the updates.img from comment 22, but still have Windows pointing to (hd0,0) instead of (hd0,1). Device Boot Start End Blocks Id System /dev/sda1 * 1 196 1572864 27 Unknown Partition 1 does not end on cylinder boundary. /dev/sda2 196 2628 19535522 7 HPFS/NTFS /dev/sda3 14462 14594 1060864 7 HPFS/NTFS This might be a special case though since the active partition is sda1, no idea if that is how it was originally. Fujitsu Lifebook S6510. I'm going to mark sda2 as boot and re-install.
Comment 27 Orion Poplawski 2010-05-05 18:19:14 EDT
Marking /dev/sda2 as boot didn't have any effect. Also, anaconda simply labels it as "Other"
Comment 28 Hans de Goede 2010-05-06 02:37:49 EDT
(In reply to comment #26) > I used the updates.img from comment 22, but still have Windows pointing to > (hd0,0) instead of (hd0,1). > > Device Boot Start End Blocks Id System > /dev/sda1 * 1 196 1572864 27 Unknown > Partition 1 does not end on cylinder boundary. > /dev/sda2 196 2628 19535522 7 HPFS/NTFS > /dev/sda3 14462 14594 1060864 7 HPFS/NTFS > The issue is that sda1 has an id of 27, which as fdisk indicate is not any known partition type id. Try changing it to "12" (compaq diagnostics), or to "de" (dell diagnostics). My MSI laptop's recovery partition has a type of 12.
Comment 29 Hans de Goede 2010-05-06 02:43:21 EDT
Hmm, doing some googling found me: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Which says that 0x27 also is used quite often for recovery partitions. One parted patch coming up.
Comment 30 Fedora Update System 2010-05-06 02:54:49 EDT
anaconda-13.40-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
Comment 31 Hans de Goede 2010-05-06 03:11:52 EDT
Uhg, partition id 27 is the microsoft recommend id for a recovery partition, see: http://technet.microsoft.com/en-us/library/dd744364%28WS.10%29.aspx I definitely need to teach parted about this.
Comment 32 Fedora Update System 2010-05-06 05:19:56 EDT
parted-2.1-8.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/parted-2.1-8.fc13
Comment 33 Fedora Update System 2010-05-07 01:48:39 EDT
parted-2.1-8.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.