Bug 534066
| 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> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | low | |||
| Version: | 12 | CC: | awilliam, beland, ddumas, eddie, hdegoede, irishmangoes, meyering, orion, vanmeeuwen+fedora, vedran | |
| Target Milestone: | --- | Keywords: | CommonBugs, Reopened | |
| Target Release: | --- | Flags: | ddumas:
fedora_requires_release_note?
|
|
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | https://fedoraproject.org/wiki/Common_F12_bugs#recovery-partition-boot | |||
| Fixed In Version: | parted-2.1-8.fc13 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 588664 (view as bug list) | Environment: | ||
| Last Closed: | 2010-05-06 06:55:41 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 583628 | |||
| Bug Blocks: | 507681 | |||
|
Description
Antonio A. Olivares
2009-11-10 13:43:01 UTC
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. We should note somewhere that this problem exists, and document the procedure to fix it. 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 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 (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 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 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 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 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 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. 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. (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 ? Chris, any comments on my suggestion done in comment #12 ? 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. (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. 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" > 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.
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 (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. As there seem to be no takers, I'll take this one. Patch coming up. This should be fixed in anaconda-13.40-1, moving to modified. 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 :>) anaconda-13.40-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.40-1.fc13 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 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. 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. Marking /dev/sda2 as boot didn't have any effect. Also, anaconda simply labels it as "Other" (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. 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. 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. 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. parted-2.1-8.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/parted-2.1-8.fc13 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. |