On Thu, Jul 10, 2014 at 02:20:53PM -0600, Chris Murphy wrote: > > On Jul 9, 2014, at 10:19 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > > > > 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. > > I was under the mistaken impression GRUB would embed on FAT. But it > complains same as on ext, and requires --force. Since this > apprehension to embed is unique to GRUB, I don't think BIOS Boot needs > to be a spec required thing, although it could be a recommendation. Right. It's specific to your bootloader, and so it's outside the scope of the spec. But suggesting that people embed grub in the same partition as is used to store the BLS fragments is a bad idea. > > 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. > > It seems risky to me to define and implement a spec, with the idea if > reuse blows up down the road we'll change the spec and reimplement. > Why not just side step the potential for problems entirely from the > get go? Because it results in a more complicated spec? This is something that we can actually test now, if you're worried about it. > > And it's impossible to migrate any installed UEFI systems to the new > > approach, which doesn't seem like a benefit. > > Converting the existing ext4 /boot means changing partitiontype GUID, > and moving kernels to their new location under /org/freedesktop/bls. > Impossible ≠ don't like the idea. ? You'd have to reformat /boot to FAT to conform on most hardware. Fragments live on a shared partition. > > 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. > > #2 and #3 can't be combined why? For a long time we've had a > filesystem other than FAT and the bootloaders read this just fine. > GRUB, extlinux, LILO, u-boot all read ext. GRUB and extlinux at least > support software raid. Seems like no change at all for BLS to be > ext3/4. Bootloaders have supported this for over a decade. Because the spec isn't intended to be Linux-specific, and we can't guarantee that arbitrary bootloaders can read ext4 or any Linux md implementation. > And for #3 if the OS and its installer conforms to the BLS, and the > volume has enough space, sure it can be shared. If it's full, their > install falls back to /boot directory on root or they create a > dedicated /boot as before. Cool. And now the first OS has less space than it needs. Sharing kernel storage is a bad idea. > > 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. > > It is a conservative position, it is not a bad one. I'd like this to > work rather than having to think of how other software might interpret > unsanctioned use of the community garden. > > We have a plot of space in /EFI/fedora. It's neither sanctioned nor > proscribed to start using unused space outside of our plot. But how > does this work when everyone does it? What happens when the ESP is > full and software can't write to /EFI/mylitterbox? I think it's fair > game for software to pitch files outside /EFI/ rather than its > operation to fail. We're talking about installing a small number of files of well under 1KB each. I think it's difficult to describe that as antisocial. > > 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*. > > Two NVRAM entries, one for each ESP's shim.efi. If NVRAM croaks, > firmware falls back to the first bootx64.efi it finds on either disk, > which happens to be shim.efi. So the system boots in any case. Please point to the section of the spec that guarantees that a failure to read a disk will generate an error that will cause the firmware to fall back to the next boot option. > > > 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. > > So you hope for a BLS defined $boot/org/freedesktop/bls/ read/writable > from BSD, Windows, OS X, not only Linux? This hasn't been the case > since maybe ancient history. Why bring this back now? Because it'd be useful? Being able to fix your Linux boot configuration from any other bootable OS on the same disk sounds like a win. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
