On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski <luto(a)mit.edu> 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?
RFE: always create required bootloader partitions in custom partitioning
https://bugzilla.redhat.com/show_bug.cgi?id=1022316
I'm not opposed to both ESP and BIOSboot created for every selected disk at install
time. But I am opposed to the current behavior of not creating that which is mandatory for
operation, while the installer then proceeds to chew me out for not having created it. It
knows enough to squawk at me, but it doesn't know enough to just do the thing that
needs to be done? Grrr that's not OK.
And in fact it's worse in that presently I can't create an ESP per disk because
the installer is mountpoint centric not partition centric. So I can only create one ESP on
one disk because I can have only one /boot/efi.
https://bugzilla.redhat.com/show_bug.cgi?id=1060576
/boot is useful regardless of how you boot. The ESP doesn't need
to
be very large and doesn't cause any harm if booted via BIOS. The BIOS
Boot partition only needs to be ~64kB IIRC, and UEFI boot will happily
ignore it. You don't even need to have any contents in there.
GRUB devs want 1MB for BIOS Boot. And then it also maintains 1MB alignment. Nevertheless
one Kleenex is more valuable than 1MB of drive space, even on an SSD.
IMO in an ideal world, there would be one (or zero!) copy of the
bootloader config, and the default configuration of the bootloader
would populate the ESP (with the signed shim!), the BIOS Boot
partition, and the (fake) MBR in the first sector. That way the disk
would *always* be BIOS-bootable and, as long as there's a (working)
copy of efibootmgr around, you can make the system UEFI-bootable with
a single command that doesn't write to disk.
I'm not opposed to the layout, but I'm personally totally disinterested in the
ensuing clusterf|ck experiences I've already had with UEFI+BIOS dual boot OS's. If
I could only experience food poisoning instead, my disposition would be no worse for the
wear.
My opinion: anything that requires BIOS to boot is old, or it's broken. And if
it's old, it should be put into a VM. And if it's broken it should be fixed if it
isn't a bad idea from the outset.
Everyone wins. Especially people who install via UEFI, upgrade
their
BIOS, and go "oh sh*t" when the BIOS upgrade conveniently erases their
boot entry.
Let's agree to not equate UEFI and BIOS. There is nothing basic about UEFI.
In any case, this is what BOOT/BOOT<arch>.EFI is for.
Sorry to say but Apple had this exact scenario figured out some 30 years ago, having had
so much experience with CMOS/NVRAM corruptions that there is a keyboard shortcut for every
Mac since the dawn of time, that clears it. And yet it has a fallback mechanism to still
boot the OS via a, probably unnecessarily clever, hint in the file system volume header.
Chris Murphy