Bug 432589

Hello,

I hit the same error updating my T495's firmware. both via Discover and "fwupdmgr update". A workaround for it is to restart and temporary disable secure boot in the BIOS, but this is not ideal on a work laptop.

The source for this backport is at https://invent.kde.org/neon/backports-focal/fwupd ; but I am confused about the upstream origin of this packaging:
  - the gitlab project description links to https://launchpad.net/ubuntu/+source/fwupd, suggesting it's derived from the ubuntu packaging
  - the commit history suggests an import from https://salsa.debian.org/efi-team/fwupd.git instead

I would love to help on this one provided there is no technical hurdle (can the Neon build infrastructure sign UEFI binaries?) and if someone can provide guidance and reviews.

Unfortunately we can't sign uefi binaries.  One option is to look into doing this.

There is a snap package of fwupd and I'm unclear if that is signed, can you test?

snap install fwupd --classic

snapd is not welcome on my systems, but I checked the official flatpak and it only ships an unsigned EFI

$ find /var/lib/flatpak/app/org.freedesktop.fwupd/ -iname *.efi*
/var/lib/flatpak/app/org.freedesktop.fwupd/x86_64/stable/d0fd85cb1b12f7668ab365a4cb066c0928312eb62b33aab00ba840e279042cf0/files/libexec/fwupd/efi/fwupdx64.efi
$ sbverify --list /var/lib/flatpak/app/org.freedesktop.fwupd/x86_64/stable/d0fd85cb1b12f7668ab365a4cb066c0928312eb62b33aab00ba840e279042cf0/files/libexec/fwupd/efi/fwupdx64.efi
[...]
No signature table present

Comparing to the grub EFI signed by Canonical:

$ sbverify --list /boot/efi/EFI/neon/grubx64.efi 
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2017)
   issuer:  /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority

For users impacted by this, would downgrading to the 1.3.9-4 provided by the focal repositories (and installing the matching fwupd-signed package) be a viable option, or would it break something?

Yes it would be possible to downgrade.  The reason we use the newer version is it is required by Discover the app manager, so you will probably need to remove this too.

(In reply to Jonathan Riddell from comment #4)
> Yes it would be possible to downgrade.  The reason we use the newer version
> is it is required by Discover the app manager, so you will probably need to
> remove this too.

sorry but this doesn't make sense to me. requiring a newer, non-working version of a tool to have another tool partially working?
In the end, I would prefer to have a working solution. if the solution is to use the cmd that's still a solution. now we have a nice gui which in the end can not get the job done because the underlying tool doesn't work in the required version...

Ok it seems I found a solution working for me:
1. rebuild the hirsute version of fwupd (1.5.8-0ubuntu1) for focal (https://packages.ubuntu.com/source/hirsute/fwupd) which works fine (I thinks also because of the work done by the neon packages which updated some deps, thx). to do this I used pbuilder-dist
2. install the hirsute version of fwupd-singed (1.38+1.5.8-0ubuntu1)

(In reply to me from comment #6)
> Ok it seems I found a solution working for me:
> 1. rebuild the hirsute version of fwupd (1.5.8-0ubuntu1) for focal
> (https://packages.ubuntu.com/source/hirsute/fwupd) which works fine (I
> thinks also because of the work done by the neon packages which updated some
> deps, thx). to do this I used pbuilder-dist
> 2. install the hirsute version of fwupd-singed (1.38+1.5.8-0ubuntu1)

This works fine for me too, using discover. Maybe you can integrate this new version of fwupd along with the fwupd-signed into de neon repository and that will fix this problem before upgrading neon to future 22.04LTS?

Something odd happened to me today: Discover was complainig about signed efi packages missing. A quick apt search revealed fwupd-signed was not installed. I did the install and rebooted. Then discover stopped complaining and appeard to download and install the firmware update. Turned out the update was still there after the reboot. 

I then tried to install manually (sudo fwupd update) and again it *seemed* to work, but when I rebooted the system I got a notification from Discover that the firmware update is still there.

I checked the signatures for fwupd-signed (version 1.38+p20.04+trelease+git20220321.1349+1.7.5-3~20.04.1) and they appear to be there:
sbverify --list /boot/efi/EFI/neon/grubx64.efi 
signature 1
image signature issuers:
 - /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority
image signature certificates:
 - subject: /C=GB/ST=Isle of Man/O=Canonical Ltd./OU=Secure Boot/CN=Canonical Ltd. Secure Boot Signing (2017)
   issuer:  /C=GB/ST=Isle of Man/L=Douglas/O=Canonical Ltd./CN=Canonical Ltd. Master Certificate Authority

What gives?

System info:
Operating System: KDE neon 5.24
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.13.0-41-generic (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520

Thank you for your bug report! 
However this bug report was created/provided previous to 01/01/2023 and also has not received any updates since  before 01/01/2025. 
Unfortunately KDE neon no longer provides updates for anything older than noble 24.04 based edition's.
Please upgrade to KDE neon noble and if you can reproduce the issue after upgrading to an active version, feel free to re-open this bug report.
Thanks for understanding!