On Jul 9, 2014, at 7:10 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > On Wed, Jul 09, 2014 at 05:46:55PM -0600, Chris Murphy wrote: > >> 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. For me "it" is grub.cfg. So I'm not following what needs embedding. > >> 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. The problem started with a lie. Don't lie about partition types by using the wrong type code. A non-UEFI system shouldn't be using an EFI System partition for critical boot data. It's as if we haven't learned from the Microsoft basic data partition mess and want to one up that one. [1] This partition will be used for a different purpose, on a system is wasn't meant for, don't use the same type code. >> 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. Yes and now there's symmetry. UEFI is to ESP as BIOS is to BIOS Boot. BLS $boot (call it Linux Boot) contains /org/freedesktop/bls, optionally supports shared /boot which is made viable by making it not FAT, and permitting md raid1 for redundancy of important boot data. It's up to distros if they use the shared BLS Linux Boot, or use /boot directory on root - both options keep partition count the same as now. Only if distros really want dedicated separate /boot do they end up with an extra one, for no good reason I'll argue but hey whatever, spec doesn't disallow it nor does it require that 3rd boot partition. > And you > can't guarantee that there'll be enough embedding space on BIOS systems. I don't know what this is referring to. > >>>> * 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 You can't predict the myriad ways the hardware will be moved around, what OS's will discover and try to manipulate these partitions that claim to be ESPs but really aren't. BLS is defining at minimum a Linux Bootloader Configuration partition. It could be a sharable Linux Boot partition as well. In either case, it's not an ESP. Can we stop stealing other projects' partition type GUIDS? > >>> 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. I don't understand this. The disk fails, it's dead yes, the system isn't, because one drive still works. This system is still bootable with the configuration I've described. Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
