On Wed, Jul 09, 2014 at 09:55:14PM -0600, Chris Murphy wrote: > > 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. You need to embed grub in something. If it's a GPT disk on a BIOS system then you need a partition devoted to that - there's nowhere else that's reliable. > > 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'm not absolutely wedded to the idea of re-using the EFI partition type - but it makes things more straightforward from an implementation perspective, and it means people aren't forced to repartition if they migrate between BIOS and UEFI. If existing operating systems default to handling the situation badly then that's a great argument against it, but if the concern is just that users will delete arbitrary partitions, then, well, that's an education issue. We should work to help avoid installers making it easy for users to do that. > > 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 it's impossible to migrate any installed UEFI systems to the new approach, which doesn't seem like a benefit. > > > And you > > can't guarantee that there'll be enough embedding space on BIOS systems. > > I don't know what this is referring to. BIOS systems on GPT would need the following partitions: 1) BIOS boot partition (in order to embed grub) 2) BSL partition (to hold configuration fragments) 3) /boot (to hold kernels) You can't merge any of these - (1) is required because you can't guarantee enough empty space on any other partition to embed grub, (2) is required because you can't guarantee that any given BIOS bootloader is able to read any filesystem other than FAT (and so also can't be RAIDed), and (3) is required because you can't just reuse (2) because you have no idea whether any other user is able to share it. > >> 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. We can't guarantee that about any partitions. If you have specific examples of operating systems that will do the wrong thing here then that's a great argument, but "There may exist software that will do the wrong thing" is a bad one. > 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? We *can*, I just don't see any advantage in doing so yet. > > …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. The disk containing the ESP fails. What happens next? If you're lucky it doesn't enumerate and you fall back to some other variable. Otherwise it's enumerated by the firmware and it attempts to boot. Now what? You have *no idea*. Maybe it'll fail in a way that results in it falling back to the next variable. Maybe it'll fail in a way that results in the firmware crashing. The overwhelming probability here is that if you have a problem it'll be down to hardware failure. We can and should deal with ESPs in a more resiliant way than we currently do. The entirely point of the BLS spec is to define a partition that's effectively equivalent to the ESP - it has to be shareable with operating systems that don't understand Linux RAID metadata. It has to be usable by operating systems that don't have read/write ext4 support. So yes, we can insist on a separate partition, and now the BLS partition has exactly the same set of problems you're objecting to in our current handling of the ESP. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
