On Tue, Jul 08, 2014 at 03:46:28PM -0600, Chris Murphy wrote: > > On Jul 7, 2014, at 2:43 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > > > Ok, here are my first attempts at modifying the spec to be more > > generally useful. Note that this means that gummiboot can no longer > > implement the full spec, but since gummiboot is also unable to do > > several other things that we need to do I don't see that as a problem in > > Fedora. > > > > https://secure.freedesktop.org/cgit/www/log/MatthewGarrett/BootLoaderSpec.mdwn > > > * What's the distinction between $boot and $root in > grub-core/commands/blscfg.c? GRUB_BOOT_DEVICE is $boot when > GRUB_MACHINE_EFI. While GRUB_BOOT_DEVICE is $root on non-UEFI. Yet the > revised spec says /org/freedesktop/bls goes on the ESP as $boot > whether UEFI or non-EFI. I need to actually set up a BIOS system again to verify how this is going to work properly - it's been too long since I used one. However, there's still no requirement that grub be installed on the ESP on BIOS systems, so drawing a distinction between "The disk with grub on it" and "The disk with the config on it" is still important. > * Changes, 3rd bullet, "There's no reason to enforce VFAT as long as > the filesystem is able to read it." I'm thinking "filesystem" was > meant to be "firmware". Correct. > * 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. > * Spec doesn't address how a spec compliant installer should behave > when installing along side an existing installation: Should > bootability of the previous OS must be preserved? That seems a > critical point of contention with most distros erring on the side of > "oh, whatever" <hand waive> "user obviously doesn't care about the > other OS that much, they're installing ours." I think as a default > behavior it's pernicious. Sure, that's outside the spec. If there's a boot fragment for the other OS then it'll remain installable. If the OS wants to support booting non-compliant OSes then it should ensure that fragments are generated. What *is* missing is guidance on naming of chainload/efi fragments - using the machine ID there is obviously inappropriate. I'll add something on that. > * 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. For UEFI systems it's already a single point of failure. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
