On Jul 8, 2014, at 4:17 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > >> * What happens to BIOS Boot on BIOS systems where GPT is either >> preferred, or necessary to support > 2.2TB drives? Looks like such >> systems get BIOS Boot still for core.img, a FAT formatted ESP for >> /org/freedesktop/bls/entries, and a Linux boot partition for >> kernel+initramfs, grub, etc. And I'm not sure really what's gained by >> changing the legacy layout with one more partition, formatted as FAT, >> for just bootloader snippets. > > The bios boot partition has no filesystem, so can't be used to store > configuration. /boot is not required to be shared between multiple > operating systems. a.) core.img on BIOS Boot can contain an embedded grub.cfg. This closely approximates the co-located grubx64.efi and grub.cfg on UEFI. Maybe it doesn't apply to other bootloaders. b.) grub.cfg on ext4 at /boot/grub2, where it also loads blscfg.mod which then finds /org/freedesktop/bls/entries on the FAT formatted ESP. I think this is somewhere between goofy and convoluted. c.) it goes on the ESP, along with /org/freedesktop/bls/, maybe also with /grub2/ stuff (and would apply to other bootloaders moving their binaries to the ESP rather than /boot.) The spec isn't clear on which of these three is the case. But the absence suggests b. While an EFI System Partition on non-UEFI systems is technically benign, it's a nomenclature failure. It will cause confusion for users, sysadmins, anyone who hasn't read documentation in advance because the behavior isn't obvious or self-describing. It'd be entirely reasonable to delete an EFI System Partition on a non-EFI system as an inappropriate, unnecessary, accidentally created partition by a confused installer. Oh nice now I can't boot - oops, guess I shouldn't have deleted it. I think the change to ESP needs to be reverted to the originally proposed partition type: bc13c2ff-59e6-4262-a352-b275fd6f7172 on GPT; 0xEA on MBR. Bootloader binaries (core.img, and .mod, themes), bootloader native configuration, and /org/freedesktop/bls/ all go there. The recommended volume format is ext4 for single device installs, is md raid1 v1.2 metadata + ext4 for multiple device installs. [1] >> * A consequence of BLS is multiple device resilient boot isn't >> possible because the configuration files go on a single ESP disk, >> which can't be on md raid (or btrfs). So it becomes a single point of >> failure. > > For BIOS systems there's no problem with RAIDing the ESP. Who will guarantee that UEFI firmware will never write to ESPs? And the same for bootloaders? What happens when Windows or OS X sees this disk, the ESP partition type code, but has metadata on it that isn't understood? I bet both of them will complain, repair or offer to format the partition. man 8 mdadm "When creating a partition based array, using mdadm with version-1.x metadata, the partition type should be set to 0xDA (non fs-data)." The GPT equivalent partition type is A19D880F-05FC-4D3B-A006-743F0F84911E. > For UEFI > systems it's already a single point of failure. Works for me. Generic grub.cfg on ESP searches for mduuid and volume uuid, uses configfile to read /boot/grub2/grub.cfg on md raid1 ext4. Only /boot/grub2/grub.cfg is ever updated. Simple. It's worked on Windows and OS X for a while. So this is not a UEFI limitation. It is a problem on Fedora due to a.) dynamically changing boot information going on the ESP, which creates the need to sync ESPs in the first place; b.) persistently mounting /boot/efi rw for no good reason encourages unnecessary changes to the ESP and file system corruption. [1] I'm on the fence if any filesystem really needs to be explicitly proscribed for the BLS $BOOT. And maybe different partition type codes for single vs raided partitions. Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
