On Feb 4, 2014, at 11:03 AM, Andrew Lutomirski <luto@xxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
