Track requests for uefi-fw-tools snap

store-requests
1

Hi team,

I did the same request in July, and the store team accepted to create a new track 1.4 for the new upstream branch. Recently, after many rounds of discussion on github[1][2], we’re still not aligning the same page between the upstream and ubuntu core, as our goal is to make sure the confined fwupd snap maintained by upstream can work outside of ubuntu core. For example, the confined fwupd snap can do firmware update on Fedora or other distributions, and then eventually uefi-fw-tools can be deprecated. As a result, now it become difficult and I’m put in very hard position.

Under this situation, I only can keep maintaining uefi-fw-tools for ubuntu core 16/18/20 and follow one of their suggestions that is to pass the parameter efi_os_dir fwupd provided to be built with meson plugin during snapcraft build. In the meanwhile, the ubuntu core used different ESP layout compared to ubuntu classic, for example, the following gives clear ESP path of uc18/20.

  • uc18: /boot/efi/EFI/boot
  • uc20: /run/mnt/ubuntu-seed/EFI/boot/

It means uefi-fw-tools snap only aligns what ubuntu core did, and it has to deal with the specific ESP path for ubuntu core series, and efi_os_dir is used to point the boot as the last dir of ESP path. More importantly, if we do this then uefi-fw-tools snap can only supports ubuntu core, and other distributions can NOT install it due to ESP is different. Furthermore, uc20 won’t use /boot/efi as default ESP, so that fwupd needs to use OverrideESPMountPoint in the configuration to overwrite the setting. Based on these, I’d like to request a new track “18” and “20” for core specific.

The reasons why uefi-fw-tools needs 18 and 20 tracks:

  • The core 18/20 has different ESP path that needs to be set at build time.
  • It’s clear to say this snap only supports ubuntu core 18/20.
  • latest track is still kept for outdated fwupd version for ubuntu core 16.

If above requests can be accepted, is it possible to drop “1.4” track from store? As the status is changed and may not be suitable for our fit.

Thanks,
Woodrow

[1] https://github.com/fwupd/fwupd/pull/2534
[2] https://github.com/fwupd/fwupd/issues/2513

1 Like
2

One other way to address this quirk would be within the fwupd snap interface code. If we detect we’re running on UC20, it would be relatively easy to instead mount the host system’s /run/mnt/ubuntu-seed over /boot/efi, if that’s the right place to copy the firmware capsules.

That way the different file system layout would not be apparent within the snap’s mount namespace.

3

If you found a reason why your snap requires specific builds based on which version of core is running on the host device, that’s reasonable, as we discussed in July - so +1 from me on creating these “18” and “20” tracks.

Let me know if you’d like me to proceed.

I would prefer not to remove the 1.4 track but what you can do is close all channels snapcraft close uefi-fw-tools 1.4/stable and so on for all channels under 1.4.

  • Daniel
4

@jamesh,

It’s good recommendation for fwupd interface TODO list, thanks. I think we still try to preserve the capability for uefi-fw-tools until the upstream supports the confined snap. Will be good moving forward in parallel.

5

@roadmr,

Yes, please go ahead and I will disable 1.4 track once this can be done.

Thanks,
Woodrow

6

I’ve gone ahead and created 18 and 20 (I omitted the uc prefix which tends to be redundant - let me know if you want it, before publishing anything to the tracks, and I can still change it).

Cheers!

  • Daniel
7

They’re good enough for me, thank you @roadmr!