On Tue, Jul 08, 2014 at 03:46:28PM -0600, Chris Murphy wrote:
On Jul 7, 2014, at 2:43 PM, Matthew Garrett mjg59@srcf.ucam.org 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.md...
- 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.
On Tue, Jul 08, 2014 at 11:17:37PM +0100, Matthew Garrett wrote:
On Tue, Jul 08, 2014 at 03:46:28PM -0600, Chris Murphy wrote:
- 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.
Anaconda will now allow you to setup the ESP on RAID1 and will create i UEFI boot variables for each disk.
On Jul 8, 2014, at 4:17 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
- 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.
a.) core.img on BIOS Boot can contain an embedded grub.cfg. This closely approximates the co-located grubx64.efi and grub.cfg on UEFI. Maybe it doesn't apply to other bootloaders.
b.) grub.cfg on ext4 at /boot/grub2, where it also loads blscfg.mod which then finds /org/freedesktop/bls/entries on the FAT formatted ESP. I think this is somewhere between goofy and convoluted.
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.)
The spec isn't clear on which of these three is the case. But the absence suggests b.
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.
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]
- 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.
man 8 mdadm "When creating a partition based array, using mdadm with version-1.x metadata, the partition type should be set to 0xDA (non fs-data)."
The GPT equivalent partition type is A19D880F-05FC-4D3B-A006-743F0F84911E.
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.
It's worked on Windows and OS X for a while.
So this is not a UEFI limitation. It is a problem on Fedora due to a.) dynamically changing boot information going on the ESP, which creates the need to sync ESPs in the first place; b.) persistently mounting /boot/efi rw for no good reason encourages unnecessary changes to the ESP and file system corruption.
[1] I'm on the fence if any filesystem really needs to be explicitly proscribed for the BLS $BOOT. And maybe different partition type codes for single vs raided partitions.
Chris Murphy
On Wed, Jul 09, 2014 at 05:46:55PM -0600, Chris Murphy wrote:
On Jul 8, 2014, at 4:17 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
- 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.
a.) core.img on BIOS Boot can contain an embedded grub.cfg. This closely approximates the co-located grubx64.efi and grub.cfg on UEFI. Maybe it doesn't apply to other bootloaders.
That doesn't help - the idea is to have every installed OS provide bootloader fragments in the same location. You still need a separate partition for the shared configuration space.
b.) grub.cfg on ext4 at /boot/grub2, where it also loads blscfg.mod which then finds /org/freedesktop/bls/entries on the FAT formatted ESP. I think this is somewhere between goofy and convoluted.
Not going to disagree.
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.
The spec isn't clear on which of these three is the case. But the absence suggests b.
You're free to implement whichever you want. As long as you can find the config fragments in a single shared location, the way you configure your bootloader is entirely up to you.
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. MBR doesn't allow for any meaningful labelling of partitions, so how it's presented is kind of ambiguous.
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. And you can't guarantee that there'll be enough embedding space on BIOS systems.
- 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.
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.
On Jul 9, 2014, at 7:10 PM, Matthew Garrett mjg59@srcf.ucam.org 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
On Wed, Jul 09, 2014 at 09:55:14PM -0600, Chris Murphy wrote:
On Jul 9, 2014, at 7:10 PM, Matthew Garrett mjg59@srcf.ucam.org 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.
On Wed, Jul 9, 2014, at 09:19 PM, Matthew Garrett wrote:
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.
Conversely though for the OSTree desired use case of live in-place nondestructive upgrades, this choice is forcing a repartition, no?
On Thu, Jul 10, 2014 at 07:09:28AM -0700, Colin Walters wrote:
On Wed, Jul 9, 2014, at 09:19 PM, Matthew Garrett wrote:
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.
Conversely though for the OSTree desired use case of live in-place nondestructive upgrades, this choice is forcing a repartition, no?
There's no way to migrate a BIOS system that doesn't implement this spec to one that does without a repartition - I can't see any way around that. UEFI will work out of the box.
*Practically* speaking, we could support the use of fragments even if there's no separate partition (ie, drop them in /boot directly). This would be outside the spec (there's no guarantee that an arbitrary bootloader will support whatever filesystem/RAID/whatever setup your /boot is on), but would work fine in the Fedora case.
On Thu, Jul 10, 2014, at 09:00 AM, Matthew Garrett wrote:
*Practically* speaking, we could support the use of fragments even if there's no separate partition (ie, drop them in /boot directly). This would be outside the spec (there's no guarantee that an arbitrary bootloader will support whatever filesystem/RAID/whatever setup your /boot is on), but would work fine in the Fedora case.
Right...while I know it's a big world with diverse use cases, starting from the matrix of "arbitrary bootloader" and "all storage configruation" is just asking for pain =)
Now I do understand the goal of upgrading from BIOS to UEFI, but it also feels like scope creep. It doesn't work seamlessly today (AFAIK), and I'd prefer to focus on bringing more sanity to the config files and bootloader interactions.
On Jul 9, 2014, at 10:19 PM, Matthew Garrett mjg59@srcf.ucam.org 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:
- BIOS boot partition (in order to embed grub)
- BSL partition (to hold configuration fragments)
- /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
On Thu, Jul 10, 2014 at 02:20:53PM -0600, Chris Murphy wrote:
On Jul 9, 2014, at 10:19 PM, Matthew Garrett mjg59@srcf.ucam.org 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:
- BIOS boot partition (in order to embed grub)
- BSL partition (to hold configuration fragments)
- /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.
On 07/08/2014 06:17 PM, Matthew Garrett wrote:
- 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.
I have been at this for a lot of years and one thing I have learned (the hard way as usual) is "*do not destroy a working system*". That is, when you want to do something like upgrade from Fedora 19 to Fedora 20, first have you OS installed in a separate partition (or, in my case, separate BTRFS subvol) and then install the new system into a different partition or btrfs subvol.
These days grub2 does not play well installing to the boot partition ... it has to go into an MBR. That is OK, it installs into the MBR of the boot drive such as sda and I use either 30_os_prober/os-prober generated menuentry items or some 40_custum "hand-crafted" menuentry items which "chainload the configuration files".
While moving forward, we need to be careful and not break the capability to boot old installs after installing the latest and greatest.
This is *not* an argument to keep os-prober. On the contrary, I want to get rid of it as it is currently implemented and used. But, I want to have some way to boot old installs as well as the 2000 pound gorilla OS (Windows). I believe Chris's point able OS X is spot on ... just ignore it, the user can boot it up using the native firmware.
In general I agree with Chris Murphy's point of view and his suggestions ... especially about not using vfat as the common location for configuration info. I will add my comments as they occur to me.
Gene
On Sat, Jul 12, 2014, at 12:03 PM, Gene Czarcinski wrote:
I have been at this for a lot of years and one thing I have learned (the hard way as usual) is "do not destroy a working system".
That philosophy drives the design and implementation of OSTree.
While moving forward, we need to be careful and not break the capability to boot old installs after installing the latest and greatest.
Right. Clearly at least grubby is going to have to work with current systems, including odd corner cases like how the Cloud image has both grub1 and syslinux config files, the former with console=hvc0.
On 12.07.2014 21:03, Gene Czarcinski wrote:
On 07/08/2014 06:17 PM, Matthew Garrett wrote:
- 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.
I have been at this for a lot of years and one thing I have learned (the hard way as usual) is "*do not destroy a working system*". That is, when you want to do something like upgrade from Fedora 19 to Fedora 20, first have you OS installed in a separate partition (or, in my case, separate BTRFS subvol) and then install the new system into a different partition or btrfs subvol.
These days grub2 does not play well installing to the boot partition ... it has to go into an MBR. That is OK, it installs into the MBR of the boot drive such as sda and I use either 30_os_prober/os-prober generated menuentry items or some 40_custum "hand-crafted" menuentry items which "chainload the configuration files".
While moving forward, we need to be careful and not break the capability to boot old installs after installing the latest and greatest.
This is *not* an argument to keep os-prober. On the contrary, I want to get rid of it as it is currently implemented and used. But, I want to have some way to boot old installs as well as the 2000 pound gorilla OS (Windows). I believe Chris's point able OS X is spot on ... just ignore it, the user can boot it up using the native firmware.
In general I agree with Chris Murphy's point of view and his suggestions ... especially about not using vfat as the common location for configuration info. I will add my comments as they occur to me.
Gene
VFAT == Very Fragile All Time :)
extlinux fan club
anaconda-devel@lists.fedoraproject.org
-
Brian C. Lane -
Chris Murphy -
Colin Walters -
Gene Czarcinski -
Matthew Garrett -
poma