Discussion: Automatic ESP discovery/management of boot assets

[ikeydoherty]

Following up on Richard's request to bring the G+ discussion to the tracker.

I would like to start a discussion around the packaging of assets in /boot, as well as dynamic discovery of where /boot really is.

Specifically, in Solus packaging, it is illegal for any package to ship files in /boot. For UEFI systems we automatically mount the ESP to /boot using the freedesktop bootloader specification (as we use systemd-boot), perform any updates, sync, and unmount again. With that said we'll automatically discover if /boot is actually mounted (i.e. getmntent) and leave it mounted if this is how the users system is configured.

In an ideal world, fwupdate would automatically discover the ESP, and as appropriate push the blobs (safely + sanely) into the ESP, respecting the various plagues of issues known to FAT on Linux (case ignorance, atomic writes, dangers of overwriting, requirement to sync) to facilitate integration with standard update procedures.

For an example of interacting with the freedesktop bootloader specification, please see the clr-boot-manager work. Note even in clr-boot-manager we still looked to see if the ESP was mounted at /boot (simple example) to locate a valid boot mount before falling back to var probing (because as we all know, firmware can and will suck.)

So in short, if approved, I'd like to implement:

• Automatic failsafe ESP discovery to alleviate per-distro configuration differences
• Sane and safe ESP blitting of the PE32 blobs
• By default the removal of the PE32 blobs from the default packaging.

Before I go gung-ho on writing code, I'd like to see a conversation around this so its either rejected/approved, but either way, everyone would at least be on the same page. Cheers!

[coling]

I've been pushing to adopt the freedesktop bootloader spec too. It's just... well, sensible! So I'd want ESP on /boot to be supported as a first class citizen too. It's certainly how I use and configure my system (although yet to push it as a distro default)

[ArchangeGabriel]

/boot as ESP is widely used on ArchLinux too (because systemd-boot notably), and this has been (and is still) causing issue with fwupdate. The 10 release changed things a bit here by allowing an ESP path to be specified at runtime (though not for the cleanup script), but ideally a correct detection of the ESP would be better. Note that they also are systems without ESP since without (U)EFI.

[ArchangeGabriel]

And indeed, /boot and the ESP might not be mounted at all, so we do not allow packages to ship files under /boot or in the ESP, so that currently people are required to manually move the fwupdate efi binary to its correct location.

[superm1]

Thanks for the proposal and the offer to produce a patch series.

I'd be open to a patch like proposed by @ikeydoherty. This discussion has come up in the past and it's just looking for an implementer. Like @ArchangeGabriel mentioned there are distros that choose not to mount the ESP, so runtime is a better time to install the bootloader than packaging.

A few thoughts I would like to make sure are incorporated into this patch:

• Do all the preparation directly from the call to fwup_set_up_update_with_buf, eg around the same time the NVRAM variables are set up.
• Please try to determine the current "active" ESP. It's technically possible to have an ESP on two different drives and as far as i'm aware it's undefined behavior which the firmware chooses to use. A possible way to do this would be to look at BootCurrent to figure out current boot variable and then looking at the BootXXXXpointed to by that to figure out which drive is in use.
• Use this detection of the ESP to validate the location in re-used fwupdate-*variables from other installations. They can be fixed up on the fly if cleanup hadn't been run for some reason already.
• Please test if secure boot is enabled before installing the EFI binary to the ESP. You can refer to https://github.com/hughsie/fwupd/blob/master/plugins/uefi/fu-plugin-uefi.c#L618 for a sample of how to test if secure boot is enabled. If it's enabled there are a few things you should do differently. 1) Make sure that shim is available or on the ESP in the right location already. If not, set an error. 2) If shim is already there, try to copy a fwup$arch.efi.signedfrom the libdir storingfwup$arch.efi (eg normally /usr/lib/fwupdate in common scenarios) to the ESP fwup$arch.efi. If there isn't a binary here, set an error.

[superm1]

@ikeydoherty any progress on this? If you don't think it's going to be for a while you'll get to it, I'd like to reassign this to fwupdate-12 milestone.

[superm1]

fwupd master has merged fwupdate into itself and now will manage installation of fwupx64.efi on it's own. I'm going to close this issue for the fwupdate project. Please test the implementation on fwupd master and provide comments there if any problems.

[joakim-tjernlund]

As fwupd master has problems to upgrade Lenovo ThinkPad it would nice if fwupdate could support ESP mounted under /boot

[ArchangeGabriel]

@joakim-tjernlund It does. Any arbitrary path actually. Just read the doc.

[joakim-tjernlund]

hmm, then maybe sys-apps/fwupd-1.0.8 that bugs? I get some strange fault(cannot rember now) when trying to use 1.0.8

[hughsie]

@ikeydoherty fwupd > 1.1.0 copies things into the ESP at runtime rather than relying on the package manager to do it. I think that makes fwupd suitable for use in Solus now.