Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 572488
| Summary: | Allow using pre-existing gpt labels for /boot on non EFI x86 | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jim Meyering <meyering> | |
| 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: | 13 | CC: | awilliam, bkoz, hdegoede, jlaska, jonathan, pjones, redhat, r.szalai, vanmeeuwen+fedora | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | anaconda-13.38-1 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 580404 581626 (view as bug list) | Environment: | ||
| Last Closed: | 2010-05-03 15:13:57 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: | ||||
| Bug Blocks: | 507681, 581626 | |||
|
Description
Jim Meyering
2010-03-11 11:00:58 UTC
The policy to not allow installation with a GPT partitioned boot drive when using IBM PC BIOS machines is deliberate, as there are no guarantees this will work with all BIOS's. However there have also been other complaints about anaconda's bootdevice checks getting in the way of things advanced users want to do (like putting /boot on an LV for some reason). See for example bug 567515. Therefore I propose that we add a "nobootsanitycheck" cmdline option, which disables the calling of checkBootRequest() when present. That sounds like a fine compromise. However, do note that BIOS do not (IMHO, must not) care what type of partition table you use for a disk (they do not manipulate partitions). Operating systems do care. If you know of authoritative documentation demonstrating how some BIOS cares about partition table type, please share. We really don't want to bypass checkBootRequest. First, doing so opens us up to getting bug reports for all sorts of strange configurations that we do not support. Second, it creates yet another rarely-tested code path. Third, look at all the things checkBootRequest does that we definitely don't want to skip: checking boot-on-encryption, checks that /boot/efi exists on those machines, that there's a PReP partition on those machines, etc. Hi Chris, Regardless of how it's implemented, we really must at least *permit* installation onto GPT-partitioned disks. Otherwise, anaconda will seriously impede adoption by those who value (or require) GPT's ability to handle partitions larger than 2TiB, not to mention those who think GPT's backup partition table is useful, just in case the primary one somehow becomes corrupted. GPT is also good for its support of 128 primary partitions and even offers a way to name partitions. GPT is the way of the future. Fedora should be encouraging its use, rather than taking the "let's keep bug reports to a minimum" approach. Oh I'm not suggesting we prevent installation onto GPT disks - just that I don't want to add command line arguments to circumvent checks. I do believe we somewhere have a bug about being able to change to GPT disk labels, but I can't find the number offhand. (In reply to comment #5) > Oh I'm not suggesting we prevent installation onto GPT disks - just that I > don't want to add command line arguments to circumvent checks. I do believe we > somewhere have a bug about being able to change to GPT disk labels, but I can't > find the number offhand. Hi, Do you have any suggestion on how to "not prevent installation onto GPT disks", while not changing checkBootRequest in the default case? We could add a "laxbootsanitycheck" cmdline option which does not completely disables checkBootRequest, but makes it a bit more lax, allowing for example having /boot on a GPT disk on an IBM BIOS pc ? Regards, Hans Look, if we're blocking things that are intended to be supported (or that should be supported) in checkBootRequest, we need to fix it, not add methods to circumvent it. It's there for a reason. (In reply to comment #7) > Look, if we're blocking things that are intended to be supported (or that > should be supported) in checkBootRequest, we need to fix it, not add methods to > circumvent it. It's there for a reason. Sounds good to me. AFAIK you were part of the discussion to make sure /boot is on an msdos labelled disk, because some IBM BIOS' won't boot from a disk when they don't see a valid msdos disklabel. Are you suggesting we relaz the check to also allow /boot being on a GPT labelled disk for plain IBM BIOS machines ? *** Bug 574290 has been marked as a duplicate of this bug. *** Hello, I'm ready to install F13-pre nightly onto another system with a GPT partition table. Is that possible, now? (In reply to comment #10) > Hello, > > I'm ready to install F13-pre nightly onto another system with a GPT partition > table. Is that possible, now? If it is a non EFI system, I'm afraid the answer still is no. *** Bug 576681 has been marked as a duplicate of this bug. *** Marking this as F13Blocker, as bug 576681, which was a dup of this was marked as such. (In reply to comment #11) > (In reply to comment #10) > > Hello, > > > > I'm ready to install F13-pre nightly onto another system with a GPT partition > > table. Is that possible, now? > > If it is a non EFI system, I'm afraid the answer still is no. Hans, I'm not well versed in the history of this problem. I just know I'm not able to install F-13 to my MacbookPro,5,5 system. I believe this system is an EFI system (from bug#576681), how can I confirm? (~)> sudo parted /dev/sda -s p [sudo] password for jlaska: Model: ATA FUJITSU MJA2320B (scsi) Disk /dev/sda: 320GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 20.5kB 210MB 210MB fat32 EFI system partition boot (In reply to comment #14) > Hans, I'm not well versed in the history of this problem. I just know I'm not > able to install F-13 to my MacbookPro,5,5 system. I believe this system is an > EFI system (from bug#576681), how can I confirm? > Hmm, If that is a x86 based MAC, *and* you are installing directly on it (so not using bootcamp), then yes it is an EFI system. If you're using bootcamp it does not count as an EFI system (but it does nicely proof that our current stance of not supporting gpt installs in the non EFI case is no good, as one certainly wants to do a GPT install on a MAC). Regards, Hans I'm trying to install F13 on a MacBookPro5,5, which is an EFI system indeed. Usually I'm booting the CD via rEFIt (refit.sf.net) - I don't know if this is simlilar to "Bootcamp" (never used it) but when I bypass refit (i.e. holding C during boot), I'm getting the same error ("sda must have a msdos disk label").
$ parted -l
Model: ATA TOSHIBA MK2555GS (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 20.5kB 210MB 210MB fat32 EFI System Partition boot
2 210MB 50.2GB 50.0GB hfsx osx
3 50.3GB 54.4GB 4099MB swap
4 54.4GB 84.4GB 30.0GB ext4 linux boot
5 84.4GB 250GB 166GB data
I'm a bit worried that F13 will be released (in May!) w/o support for GPT. I understand that "disabling checkBootRequest" is not the proper way to go, but can't we relax this check somewhat so that GPT users can at least *install* F13 and go on to test all the other things to come? We could revisit checkBootRequest (whatever is done there) later on or even postpone it for F14, but I think so many potential testers are left out when we don't find a (quick!) workaround here.
Thanks,
Christian.
I was trying to install F12 and then F13-Beta-RC, but faced this bug. Both Ubuntu and Debian allows such an install, so I am using Ubuntu for now. I wouldn't worry about support problems. The only reason people would complain is that their BIOS is buggy. Other than that there the bootloader in the protective MBR works just the sameas on an MSDOS partitioned disk. I also think as a leading distribution Fedora should encourage the use of modern technologies, just like it does in the case of DisplayPort and other new hardware features. Is there any workaround or instructions how to patch anaconda and build a custom installer media? Hi All, After some discussion we've decided to make the /boot check on x86 more relax and allow /boot to live on disks with either a msdos or a gpt disklable, resolving this issue. Please give this updates.img a try: http://people.fedoraproject.org/~jwrdegoede/updates-572488 You can make anaconda use it, by doing a regular (not a livecd) install and then passing: updates=http://people.fedoraproject.org/~jwrdegoede/updates-572488 On the syslinux boot cmdline (press a key to get the bootmenu, tab to add options, and then add the above option to the end of the pre-filled cmdline). Regards, Hans This will be fixed in anaconda-13.38-1, which will hit F-13 after the beta freeze is lifted, in the mean time you can use the provided updates.img. Thanks Hans, F-13-Beta-RC5 + http://people.fedoraproject.org/~jwrdegoede/updates-572488 allowed me to install Fedora 13 on my MacbookPro 5,5. I no longer am prevented from installing due to the '/boot' warning. F13-Alpha + updates-572488 allowed me to install to an already partitioned GPT disk. (I've tested this in a VirtualBox VM and got bitten by #564330 or #571241 or something, but that's a different story.) Thanks! as anaconda 13.38 is in the main repos now (in fact, has been superseded) I believe we can close this. please re-open if I'm wrong. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers |