Bug 572488 - Allow using pre-existing gpt labels for /boot on non EFI x86
Allow using pre-existing gpt labels for /boot on non EFI x86
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
:
: 574290 576681 (view as bug list)
Depends On:
Blocks: F13Blocker/F13FinalBlocker 581626
  Show dependency treegraph
 
Reported: 2010-03-11 06:00 EST by Jim Meyering
Modified: 2013-03-13 16:41 EDT (History)
9 users (show)

See Also:
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 11:13:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jim Meyering 2010-03-11 06:00:58 EST
Description of problem: currently, anaconda refuses to install to /dev/sda with a GPT partition table.  It fails with an "error" saying that /dev/sda must have a MSDOS partition table.  GPT partition tables are superior to MSDOS tables in many ways, and should at least be permitted.

Please remove this artificial restriction.

Version-Release number of selected component (if applicable):
anaconda-13.32-1.fc13

How reproducible: always

Steps to Reproduce:
1. put a GPT table on /dev/sda (e.g., parted -s /dev/sda mklabel gpt)
2. attempt to install fedora onto /dev/sda
  
Actual results: installation fails, complaining of the "error" (which is really anaconda's policy decision) that /dev/sda does not have an MSDOS partition table.

Expected results: installation succeeds

Additional info: A related report: http://bugzilla.redhat.com/503149
Comment 1 Hans de Goede 2010-03-11 06:05:26 EST
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.
Comment 2 Jim Meyering 2010-03-11 06:17:47 EST
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.
Comment 3 Chris Lumens 2010-03-11 10:22:21 EST
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.
Comment 4 Jim Meyering 2010-03-11 12:06:59 EST
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.
Comment 5 Chris Lumens 2010-03-12 10:00:03 EST
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.
Comment 6 Hans de Goede 2010-03-15 08:56:11 EDT
(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
Comment 7 Peter Jones 2010-03-15 11:05:31 EDT
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.
Comment 8 Hans de Goede 2010-03-15 11:19:36 EDT
(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 ?
Comment 9 Chris Lumens 2010-03-17 09:38:16 EDT
*** Bug 574290 has been marked as a duplicate of this bug. ***
Comment 10 Jim Meyering 2010-03-27 10:40:18 EDT
Hello,

I'm ready to install F13-pre nightly onto another system with a GPT partition table.  Is that possible, now?
Comment 11 Hans de Goede 2010-03-28 10:09:01 EDT
(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.
Comment 12 Hans de Goede 2010-03-29 04:28:10 EDT
*** Bug 576681 has been marked as a duplicate of this bug. ***
Comment 13 Hans de Goede 2010-03-29 04:28:57 EDT
Marking this as F13Blocker, as bug 576681, which was a dup of this was marked as such.
Comment 14 James Laska 2010-03-29 19:21:04 EDT
(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
Comment 15 Hans de Goede 2010-03-30 03:22:12 EDT
(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
Comment 16 Christian Kujau 2010-03-31 03:01:58 EDT
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.
Comment 17 Robert Szalai 2010-04-07 08:24:39 EDT
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?
Comment 18 Hans de Goede 2010-04-08 04:11:27 EDT
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
Comment 19 Hans de Goede 2010-04-08 11:31:16 EDT
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.
Comment 20 James Laska 2010-04-08 11:38:16 EDT
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.
Comment 21 Christian Kujau 2010-04-11 03:51:11 EDT
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!
Comment 22 Adam Williamson 2010-05-03 11:13:57 EDT
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

Note You need to log in before you can comment on or make changes to this bug.