New UEFI guide on the wiki

[Adam Williamson]

On Tue, 2014-02-04 at 11:49 -0800, Andrew Lutomirski wrote:
> On Tue, Feb 4, 2014 at 11:28 AM, Adam Williamson <awilliam at redhat.com> wrote:
> > On Tue, 2014-02-04 at 10:03 -0800, Andrew Lutomirski wrote:
> >
> >> This reminds me: I *always* install with a GPT partition table, an ESP
> >> partition, a BIOS Boot partition, and a smallish (1 or 2 GB) ext4
> >> /boot near the beginning of the disk.  All Linuxes seem perfectly
> >> happy to install this way (assuming you can figure out how to
> >> partition the disk like that in the first place) and booting that way
> >> in BIOS or EFI mode.  Given that this wastes at most a few MB, should
> >> anaconda just partition like that by default?
> >
> > Definitely not. We tried doing BIOS installs to GPT disks by default in
> > Fedora 16, and it was basically a complete disaster.
> 
> What failed?  

The major thing was we found quite a lot of systems that just don't boot
this way. Large numbers of Thinkpads appear to have firmwares that can't
boot BIOS-native installs from GPT disks, for instance.

We didn't auto-create a BIOS boot partition in custom partitioning, and
people were often stumped by the requirement. People hit the same
problem with UEFI installs and the ESP, of course, but we're stuck with
that: we *have* to support UEFI. We don't have to cause ourselves the
pain with BIOS-native installs. Also, people are more likely to accept
that things will be different with a completely new firmware standard
than they are with the idea that we just arbitrarily changed our default
disk format and required them to learn about this 'BIOS boot partition'
thing.

Your proposal like cmurf's involves us auto-creating the BIOS boot
partition, so it doesn't have *that* problem, but it has another
problem, the one I pointed out to cmurf - it's not actually all that
easy to have custom part just magically do stuff for you, and it
certainly makes the code paths more fragile, and we really don't need
any more fragility in partitioning.

> I'm guessing that userspace improvements since then have
> mostly fixed this.  I've never seen any problem on F18 (IIRC) and up
> with GPT partition tables being BIOS-booted.  It seems to Just Work
> (tm).

You might want to go look back at the F16 release validation process and
the anaconda bug list from that period. It was anything but Just
Working. :)

> Also, isn't this already sort of necessary on large disks?

Yeah. MBR disks top out at 2.2TB or something like that - you can format
a bigger disk with an MBR partition table, but the space beyond whatever
the limit is won't be available.

These are already special-cased in the installer, if we're reformatting
a disk that's above that size, we format it to GPT not MBR (and the BIOS
boot partition requirement kicks in).

> (I maintain at least ten machines like this, running Fedora and
> various Ubuntus, some installed graphically and some installed by
> untarring a system image.  I haven't had any problem at all.)

Ten machines is nice and all, but we have, you know, 10,000 times that
many or whatever it is to worry about for a Fedora release :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net