fwupd
fwupd copied to clipboard
fwupd
Failed to update metadata for lvfs on Kubuntu 21.04
Describe the bug
When I run
fwupdmgr refresh
It fails with the message
Updating lvfs Downloading… [ - Downloading… [ - Downloading… [***************************************] Downloading… [**************************Downloading… [***************************************] Failed to update metadata for lvfs: checksum failure: failed to verify data, expected 98261db7124c8026fb88f77768787efc2f8355c3
Steps to Reproduce Run the above-mentioned command, or open "Discovery" in Kubuntu or the Gnome-software in Ubuntu.
Expected behavior The metadata should be updated
fwupd version information Please provide the version of the daemon and client.
client version: 1.5.11
compile-time dependency versions
gusb: 0.3.5
daemon version: 1.5.11
Please note how you installed it (apt, dnf, pacman, source, etc):
It was bundled with the distro
fwupd device information Please provide the output of the fwupd devices recognized in your system.
fwupdmgr get-devices --show-all-devices
System Product Name
│
├─Intel(R) Core™ i7-9700 CPU @ 3.00GHz:
│ Device ID: 4bde70ba4e39b28f9eab1628f9dd6e6244c03027
│ Current version: 0x000000ea
│ Vendor: Intel
│ GUIDs: b9a2dd81-159e-5537-a7db-e7101d164d3f
│ 30249f37-d140-5d3e-9319-186b1bd5cac3
│ 809a0b93-8a12-5338-a571-ad5583acf896
│ 50a811ae-a8fd-5cd0-90f4-33583974b789
│ Device Flags: • Internal device
│
├─KINGSTON SA400S37480G:
│ Device ID: 5dbeb140337f610d54913c0f43d15fdaa0eafb51
│ Summary: ATA Drive
│ Current version: SBFKK1B3
│ Vendor: Kingston (ATA:0x2646, OUI:0026b7)
│ GUIDs: d8e02563-67f0-5da4-b388-e3b18a5f0dd3
│ 1ab2d344-65ac-5bc5-adbd-9aab1dfc2be3
│ b4b189f9-ed32-5438-a5e4-d3313483647a
│ Device Flags: • Internal device
│ • Updatable
│ • System requires external power source
│ • Needs a reboot after installation
│ • Needs shutdown after installation
│ • Device is usable for the duration of the update
│
├─System Firmware:
│ │ Device ID: 9faa1c99a611d57becf0cb8087eafd191bfb673e
│ │ Current version: 4611
│ │ Minimum Version: 4611
│ │ Vendor: System manufacturer (DMI:American Megatrends Inc.)
│ │ GUIDs: 247b3810-2e33-51bf-9ade-4f119f3d0e53
│ │ 230c8b18-8d9b-53ec-838b-6cfc0383493a
│ │ 505f27c1-acb7-52ab-b71a-08be849c28e1
│ │ Device Flags: • Internal device
│ │ • Updatable
│ │ • System requires external power source
│ │ • Needs a reboot after installation
│ │ • Cryptographic hash verification is available
│ │ • Device is usable for the duration of the update
│ │
│ └─UEFI dbx:
│ Device ID: 362301da643102b9f38477387e2193e57abaa590
│ Summary: UEFI Revocation Database
│ Current version: 77
│ Minimum Version: 77
│ Vendor: UEFI:Linux Foundation
│ Install Duration: 1 second
│ GUIDs: fda6234b-adcb-5105-8515-9af647d29775
│ f8ff0d50-c757-5dc3-951a-39d86e16f419
│ c6682ade-b5ec-57c4-b687-676351208742
│ f8ba2887-9411-5c36-9cee-88995bb39731
│ 7d5759e5-9aa0-5f0c-abd6-7439bb11b9f6
│ 0c7691e1-b6f2-5d71-bc9c-aabee364c916
│ Device Flags: • Internal device
│ • Updatable
│ • Needs a reboot after installation
│
├─TOSHIBA HDWD120:
│ Device ID: e421b2fc248391f6fe3e55ddbb3c9043be068bd0
│ Summary: ATA Drive
│ Current version: MX4OACF0
│ Vendor: Toshiba (ATA:0x1179, OUI:000039)
│ GUIDs: 0ca61bbd-a96f-5876-abfc-58fce3f19ab0
│ f26aeb1a-c0e2-55e9-a43a-31bc5a30bf61
│ 80770ad0-c298-5c20-894b-d805d681048c
│ Device Flags: • Internal device
│ • Updatable
│ • System requires external power source
│ • Needs a reboot after installation
│ • Device is usable for the duration of the update
│
├─TPM:
│ │ Device ID: c6a80ac3a22083423992a3cb15018989f37834d6
│ │ Summary: TPM 2.0 Device
│ │ Current version: 302.12.0.0
│ │ Vendor: Intel (TPM:INTC)
│ │ GUIDs: ff71992e-52f7-5eea-94ef-883e56e034c6
│ │ 34801700-3a50-5b05-820c-fe14580e4c2d
│ │ 8e1cbc5d-5a11-5149-bfea-b6065d5296ba
│ │ 03f304f4-223e-54f4-b2c1-c3cf3b5817c6
│ │ 52d7b679-db28-5bf7-bd87-41d77aeec600
│ │ Device Flags: • Internal device
│ │
│ └─Event Log:
│ Device ID: 58bd405f31c48e6eca290b425f530a94c91e955c
│ GUID: a25657fe-b5dc-5be0-8b78-8b9dfec678ff
│ Device Flags: • Internal device
│
└─UHD Graphics 630 (Desktop 9 Series):
Device ID: 5792b48846ce271fab11c4a545f7a3df0d36e00a
Current version: 02
Vendor: Intel Corporation (PCI:0x8086)
GUIDs: 94211b97-22f2-57b3-97e7-15b5023f61e5
5b029aee-f2fc-54b4-8247-d7424420c27a
e9ceb7d8-e213-5ec4-8805-6330d894b317
8655a49b-b4b2-54ff-a6c6-06009dd64f13
Device Flags: • Internal device
• Cryptographic hash verification is available
Additional questions
- Operating system and version:
- Have you tried rebooting?
- Yes
- Is this a regression?
- Not sure.
system info:
inxi -F -z System: Kernel: 5.11.0-31-generic x86_64 bits: 64 Desktop: KDE Plasma 5.21.4 Distro: Ubuntu 21.04 (Hirsute Hippo) Machine: Type: Desktop Mobo: ASUSTeK model: PRIME B365M-A v: Rev X.0x serial: <filter> UEFI: American Megatrends v: 1203 date: 10/10/2019 CPU: Info: 8-Core model: Intel Core i7-9700 bits: 64 type: MCP L2 cache: 12 MiB Speed: 800 MHz min/max: 800/4700 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800 8: 1834 Graphics: Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] driver: i915 v: kernel Device-2: IMC Networks XHC Camera type: USB driver: uvcvideo Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting unloaded: fbdev,vesa resolution: 1: 1920x1080~60Hz 2: 1920x1080~60Hz OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 21.0.3 Audio: Device-1: Intel 200 Series PCH HD Audio driver: snd_hda_intel Device-2: JMTek LLC. USB PnP Audio Device type: USB driver: hid-generic,snd-usb-audio,usbhid Sound Server: ALSA v: k5.11.0-31-generic Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: <filter> Device-2: Realtek 802.11ac NIC type: USB driver: rtl8821cu IF: wlx200db0415dd5 state: down mac: <filter> Bluetooth: Device-1: Cambridge Silicon Radio Bluetooth Dongle (HCI mode) type: USB driver: btusb Report: ID: hci0 state: up running pscan bt-v: 2.1 address: <filter> Drives: Local Storage: total: 2.26 TiB used: 900.78 GiB (39.0%) ID-1: /dev/sda vendor: Kingston model: SA400S37480G size: 447.13 GiB ID-2: /dev/sdb vendor: Toshiba model: HDWD120 size: 1.82 TiB Partition: ID-1: / size: 139.05 GiB used: 73.6 GiB (52.9%) fs: ext4 dev: /dev/sda5 ID-2: /boot/efi size: 96 MiB used: 37.9 MiB (39.5%) fs: vfat dev: /dev/sda2 Swap: ID-1: swap-1 type: partition size: 17.45 GiB used: 3 MiB (0.0%) dev: /dev/sda7 Sensors: System Temperatures: cpu: 29.8 C mobo: 27.8 C Fan Speeds (RPM): N/A Info: Processes: 321 Uptime: 51m Memory: 15.49 GiB used: 7.62 GiB (49.2%) Shell: fish inxi: 3.3.01
If you download the metadata files with wget, are you getting some kind of captive portal HTML page?
Tell me how to do it and I will give it a try. Give a command to run in terminal, or something. Right now I am on Kubuntu 20.04 LTS and having the same issue. At first I thought it was because of my corporate root certificate but the IT guys say that don't see any block taking place.
wget https://cdn.fwupd.org/downloads/firmware.x ml.gz --2021-08-19 16:28:05-- https://cdn.fwupd.org/ downloads/firmware.xml.gz Resolving cdn.fwupd.org (cdn.fwupd.org)... 151. 101.194.49, 151.101.130.49, 151.101.66.49, ... Connecting to cdn.fwupd.org (cdn.fwupd.org)|151 .101.194.49|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/xml] Saving to: ‘firmware.xml.gz’
firmware.xm 5.94M 8.57MB/s in 0.7s
2021-08-19 16:28:08 (8.57 MB/s) - ‘firmware.xml .gz’ saved [6229586]
On Thu, Aug 19, 2021 at 4:27 PM Richard Hughes @.***> wrote:
e.g. wget https://cdn.fwupd.org/downloads/firmware.xml.gz
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fwupd/fwupd/issues/3652#issuecomment-901915465, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADIBH5DBGNGRGUZHXZU7V2LT5UBD5ANCNFSM5CNNG7JA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
The same issue was reported by three users at Wilders Security Forums, two on Kubuntu 20.04 [1] [2] and one unknown distro and version [3].
In an earlier fwupd thread with a similar issue, #2089 , hughsie diagnosed the issue to the fact that the server was 'OOMing', out of memory, a server reboot fixed that. I wonder if there is any chance that the same problem may be going on?
server was 'OOMing
That was some time ago when the LVFS was just one VM in a datacenter. It's now a hugely scalable AWS multi-az thing that should survive almost anything.
OK, thank you very much. Do you have any thoughts about what may be causing the issue, currently?
I'm facing this error message as well since a few weeks now, on all my Kubuntu 20.04 machines. I only face this error the 1st time I run Discover after the boot of my machine. Exiting and re-running Discover doesn't generate this error again. Until a subsequent day where Discover mentions the availability of new package updates (rough observation).
Here is what I have in ~/.cache/fwupd/remotes.d/lvfs:
-rw-rw-r-- 1 XXX XXX 6250399 août 25 16:28 metadata.xml.gz
-rw-rw-r-- 1 XXX XXX 488 août 3 00:47 metadata.xml.gz.asc
-rw-rw-r-- 1 XXX XXX 2229 août 25 16:28 metadata.xml.gz.jcat
As a test, running wget https://cdn.fwupd.org/downloads/firmware.xml.gz works correctly on my end.
Another test (after I've already faced message "Failed to update metadata for lvfs" once today):
$ fwupdmgr refresh
WARNING: UEFI firmware can not be updated in legacy BIOS mode
See https://github.com/fwupd/fwupd/wiki/PluginFlag:legacy-bios for more information.
Updating lvfs
Downloading… [***************************************]
Downloading… [***************************************]
Successfully downloaded new metadata: 0 local devices supported
Just to chime in. Been having the same message pop up every time I open the update/Discovery for the past six weeks, Kubuntu 20.04.
Tested the wget today, will report tomorrow if it works.
Just reporting here, I've been seeing the exact same message as @Mastercroft for the last one or -maybe- two months. Kubuntu 20.04
This may be a subset of the infrastructure; I work at System76, and a customer reports Ubuntu Software will hang with lvfs errors. Running fwupdmgr refresh gets the same error:
fwupdmgr refresh
Updating lvfs
Downloading… [***************************************]
Failed to update metadata for lvfs: no signature method in results
He is in Vermont, and when I run it at the same time in Denver, I get clean results:
fwupdmgr refresh
Firmware metadata last refresh: 10 hours ago. Use --force to refresh again.
fwupdmgr refresh --force
Updating lvfs
Downloading… [***************************************]
Downloading… [***************************************]
Successfully downloaded new metadata: 0 local devices supported
Looking for that error code I see:
/* should never happen due to %JCAT_VERIFY_FLAG_REQUIRE_SIGNATURE */
g_set_error_literal(error,
FWUPD_ERROR,
FWUPD_ERROR_INVALID_FILE,
"no signature method in results");
Could this be something to do with the system being upgraded? e.g. if you stop fwupd, then do rm /var/lib/fwupd/remotes.d/* then fwupdmgr refresh --force does it magically start working?
Didn't seem to fix:
sudo rm /var/lib/fwupd/remotes.d/*
[sudo] password for lao:
rm: cannot remove '/var/lib/fwupd/remotes.d/lvfs': Is a directory
lao@Sys:~$ fwupdmgr refresh --force
Updating lvfs
Downloading… [***************************************]
Failed to update metadata for lvfs: no signature method in results
Still seems to get the same error:
sudo rm /var/lib/fwupd/remotes.d/* -rf
[sudo] password for lao:
lao@Sys:~$ fwupdmgr refresh --force
Updating lvfs
Downloading… [***************************************]
Failed to update metadata for lvfs: no signature method in results
Is this snap? If so, I assume snap stores the data somewhere different perhaps?
Okay scrap the upgrade idea, I've traced the failure a bit. On a failing system, try this:
wget https://cdn.fwupd.org/downloads/firmware.xml.gz
wget https://cdn.fwupd.org/downloads/firmware.xml.gz.jcat
then do:
jcat-tool verify firmware.xml.gz.jcat --public-keys /etc/pki/fwupd-metadata
firmware-02230-stable.xml.gz:
PASSED sha1: OK
PASSED sha256: OK
PASSED pkcs7: O=Linux Vendor Firmware Project,CN=LVFS CA
PASSED gpg: 3FC6B804410ED0840D8F2F9748A6D80E4538BAC2
I suspect on a failing system the snap isn't able to read out the certificate store, or maybe the package (the snap?) isn't being built with GPG or PKCS support? I don't see any other way this can fall through to the no signature method in results failure.
Perhaps fwupd was built against a different version of libjcat than is installed on the system? If you downgrade libjcat does that work? 0.1.3 had a behaviour change with signatures, although that was released about 15 months ago...
Needless to say, I don't see this on Fedora.
Well, isn't this fun:
jcat-tool verify firmware.xml.gz.jcat --public-keys /etc/pki/fwupd-metadata | tee jcat.log
firmware-02230-stable.xml.gz:
FAILED: Failed to open file “./firmware-02230-stable.xml.gz”: No such file or directory
Validation failed
apt policy libjcat1 jcat
libjcat1:
Installed: 0.1.3-2
Candidate: 0.1.3-2
Version table:
*** 0.1.3-2 500
500 http://us.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
100 /var/lib/dpkg/status
jcat:
Installed: 0.1.3-2
Candidate: 0.1.3-2
Version table:
*** 0.1.3-2 500
500 http://us.archive.ubuntu.com/ubuntu hirsute/universe amd64 Packages
100 /var/lib/dpkg/status
Both firmware.xml.gz and firmware.xml.gz.jcat downloaded and are located in the PWD.
That was on my system, which is Pop!OS 21.04; I'm seeing the same error on customer machine that is running Ubuntu 20.04 (with updates all run).
So my guess here was that fwupd was compiled against (i.e. build time, not run time) a newer version of libjcat than is being shipped. I'm pretty sure updating to libjcat 0.1.4 (released 2020-10-23) will fix this, although, you should really update to 0.1.8 for other fixes too.
Yep. I tracked this down to the fwupd that is built and shipped for System76 customers; when we backed out to the version shipped in 20.04 by Ubuntu, the update works fine. I'm somewhat baffled that I don't see the same error on live hardware or in a VM when trying to recreate this. This is the set of commands that has him fixed (for those that find this error):
sudo apt-add-repository -r ppa:system76-dev/stable
sudo apt update
sudo apt full-upgrade
sudo apt remove fwupd
sudo apt install fwupd
wget https://cdn.fwupd.org/downloads/firmware.xml.gz did the trick for me.
Did a fwupdmgr refresh --force and it was successful.
No idea how to recreate this.
fwupdmgr refresh --force fixed it for me as well (kubutu 20.04) Iǘe had th message for the last two months or so.
I think we need to get Ubuntu to update fwupd and its dependencies. System76 only ships an override (to our customers on Ubuntu and to Pop users) because the Ubuntu version is missing Launch support and we also want maximum hardware support for all vendors on Pop.
Regarding fwupdmgr --force refresh, on my Kubuntu 20.04 systems, that command didn't fix the "Failed to update metadata for lvfs: checksum failure: failed to verify data" error, the error was back 24 hours later.
Edit
I also wrote: "However, I don't see that error in weekends, if I'm not mistaken. If I recall correctly, there was some update some time ago that limits updates to weekdays, so it also limits the error to weekdays, probably."
I must correct that.
On my Kubuntu 20.04 system, in Discover, I saw the "Failed to update metadata for lvfs: checksum failure: failed to verify data" error this morning, on Sunday, so my idea that the error is limited to weekdays was not correct.
@SnowballV You are correct, the error is back (this sunday though), three days later.
I'm pretty sure updating libjcat will fix this. I'm not responsible for this in Ubuntu, and I don't think this is a fwupd bug.
@hughsie, Do you know how we can find out if updating libjcat is what's needed to fix the issue? And who at Ubuntu should be contacted regarding this matter?
I'm really perplexed why this just started to show up in Ubuntu 21.04, is it just people adopting it more lately?
Neither libjcat nor fwupd in 21.04 have been touched in a very long time.
Regarding reporting it, the correct location would be Launchpad under the appropriate package.
