On Wed, Jul 09, 2014 at 05:46:55PM -0600, Chris Murphy wrote: > > 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. That doesn't help - the idea is to have every installed OS provide bootloader fragments in the same location. You still need a separate partition for the shared configuration space. > 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. Not going to disagree. > 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.) Well, you can't install it on the ESP on BIOS systems - there's no guarantee that there's enough room to embed it. > The spec isn't clear on which of these three is the case. But the absence suggests b. You're free to implement whichever you want. As long as you can find the config fragments in a single shared location, the way you configure your bootloader is entirely up to you. > 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. Well yeah, don't delete partitions if you don't know what they're doing. MBR doesn't allow for any meaningful labelling of partitions, so how it's presented is kind of ambiguous. > 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] Why? Now you're requiring an extra partition on UEFI systems. And you can't guarantee that there'll be enough embedding space on BIOS systems. > >> * 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. That's why I said BIOS. > > 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. …and if the disk fails it's still dead. We can do a better job than we're currently doing as far as ensuring filesystem consistency goes, but the most likely failure point is still going to be the drive. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
