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. > 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. I don't have a problem with creating the ESP on a BIOS system, as long as it's not being used to store critical data to boot a BIOS system. > 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? > >>> 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. 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. >>> 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. #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. 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. > >>>> 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. 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. Is it wrong Windows invites reformatting of partitions that use its partitiontype GUID? No. Is it wrong that BIOS firmware puke on GPT disks? No. Do we like or approve of any of these behaviors? Unlikely, I certainly don't, but the behaviors aren't wrong. The mistake happened before these behaviors cropped up. >> 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. Ok well I don't see an advantage of lurking in people's backyards to find out whether I'm going to get shot at or not. There's no shortage of partitiontype GUIDs or partitions on GPT and it avoids having to spend brain cycles thinking about let alone testing whether it'll be a problem down the road, and how to mitigate it. > >>> …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? There are two ESPs, one on each disk, they have the same contents placed there at install time. The ESP contents aren't subsequently modified when kernels are installed. > 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. > 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? Chris Murphy [1] RHBZ 1046577 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
