fwupd failed to update metadata for lvfs

Bug #1943833 reported by Forage
80
This bug affects 15 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Medium
Yuan-Chen Cheng
fwupd (Ubuntu)
Status tracked in Jammy
Focal
Undecided
Unassigned
Jammy
Undecided
Unassigned
libjcat (Ubuntu)
Status tracked in Jammy
Jammy
Undecided
Unassigned
plasma-discover (Ubuntu)
Undecided
Unassigned
Focal
Undecided
Unassigned

Bug Description

When running `fwupdmgr refresh` from the command line or when performing an update from the Software application the following error will be thrown:

Failed to update metadata for lvfs: checksum failure: failed to verify data, expected 98261db7124c8026fb88f77768787efc2f8355c3

The cause is an outdated libjcat, as explained in the upstream bug report: https://github.com/fwupd/fwupd/issues/3652#issuecomment-912677175

0.1.3 is included in Ubuntu but at least 0.1.4 of libjcat is required to function properly.

Firmware can not be updated any longer as a result unless forcing the update manually by performing `fwupdmgr refresh --force`.

This means the libjcat dependency of this package needs to be set to 0.1.4 minimum and the libjcat package itself needs to be updated.

ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: fwupd 1.5.11-0ubuntu1~21.04.1
ProcVersionSignature: Ubuntu 5.11.0-34.36-generic 5.11.22
Uname: Linux 5.11.0-34-generic x86_64
ApportVersion: 2.20.11-0ubuntu65.3
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: GNOME
Date: Thu Sep 16 16:19:33 2021
InstallationDate: Installed on 2019-09-12 (735 days ago)
InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
SourcePackage: fwupd
UpgradeStatus: Upgraded to hirsute on 2021-05-26 (112 days ago)
modified.conffile..etc.fwupd.remotes.d.lvfs-testing.conf: [modified]
modified.conffile..etc.fwupd.remotes.d.lvfs.conf: [modified]
mtime.conffile..etc.fwupd.remotes.d.lvfs-testing.conf: 2021-03-25T16:21:42.746540
mtime.conffile..etc.fwupd.remotes.d.lvfs.conf: 2021-06-07T11:13:00.873724

Revision history for this message
Forage (forage) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in fwupd (Ubuntu):
status: New → Confirmed
Revision history for this message
Brian Murray (brian-murray) wrote :

I'm unable to recreate this on an up to date install of Ubuntu 20.04.

bdmurray@atom:~$ sudo rm -rf /var/lib/fwupd/remotes.d/*
[sudo] password for bdmurray:
bdmurray@atom:~$ fwupdmgr refresh
Updating lvfs
Downloading… [***************************************]
Downloading… [***************************************]
Successfully downloaded new metadata: 1 local device supported
bdmurray@atom:~$ apt-cache policy fwupd libjcat1
fwupd:
  Installed: 1.5.11-0ubuntu1~20.04.2
  Candidate: 1.5.11-0ubuntu1~20.04.2
  Version table:
 *** 1.5.11-0ubuntu1~20.04.2 500
        500 http://192.168.10.7/ubuntu focal-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.3.9-4ubuntu0.1 500
        500 http://192.168.10.7/ubuntu focal-security/main amd64 Packages
     1.3.9-4 500
        500 http://192.168.10.7/ubuntu focal/main amd64 Packages
libjcat1:
  Installed: 0.1.3-2~ubuntu20.04.1
  Candidate: 0.1.3-2~ubuntu20.04.1
  Version table:
 *** 0.1.3-2~ubuntu20.04.1 500
        500 http://192.168.10.7/ubuntu focal-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     0.1.0-2 500
        500 http://192.168.10.7/ubuntu focal/universe amd64 Packages

Changed in fwupd (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Forage (forage) wrote :

Brian is correct, I just tried to reproduce it on a different 21.04 system and it passes without a hitch as well.

----------------------------------------------------------------------
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
----------------------------------------------------------------------

----------------------------------------------------------------------
apt-cache policy fwupd libjcat1
fwupd:
  Installed: 1.5.11-0ubuntu1~21.04.1
  Candidate: 1.5.11-0ubuntu1~21.04.1
  Version table:
 *** 1.5.11-0ubuntu1~21.04.1 500
        500 http://fr.archive.ubuntu.com/ubuntu hirsute-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.5.8-0ubuntu1 500
        500 http://fr.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
libjcat1:
  Installed: 0.1.3-2
  Candidate: 0.1.3-2
  Version table:
 *** 0.1.3-2 500
        500 http://fr.archive.ubuntu.com/ubuntu hirsute/main amd64 Packages
        100 /var/lib/dpkg/status
----------------------------------------------------------------------

As a result I tried the initial system again and it also passed.

People in the upstream bug report to have seen similar behaviour as well, where it magically works in the weekend but not during the week.

Revision history for this message
Dominik (dominalien) wrote :

I've been getting this on 20.04 in KDE's Discover application.

When I just ran fwupdmgr refresh, it completed fine.

Revision history for this message
Hákon Örn (mastercroft) wrote :

Still popping up, week after fwupdmgr refresh.

20.04 Kubuntu discover.

Revision history for this message
pelm (pelle-ekh) wrote :

Anyone having a solution for this? Kubuntu 20.04 discover.

Revision history for this message
Sarah Hide (sarahhide) wrote :

When opening KDE Discover on Kubuntu 20.04 I get the same error.

"Failed to update metadata for lvfs: checksum failure: failed to verify data, expected 98261db7124c8026fb88f77768787efc2f8355c3"

Running "fwupdmgr refresh" completes successfully without error but doesn't solve the issue.

Revision history for this message
Botch Lestat (ccbmailroom) wrote :

I've been getting this error too. I did a Kubuntu 20.01 ISO reinstall this past Saturday (6 days ago) and I'm getting this error.

Changed in fwupd (Ubuntu):
status: Incomplete → Invalid
Changed in libjcat (Ubuntu):
status: New → Triaged
no longer affects: fwupd (Ubuntu Focal)
no longer affects: fwupd (Ubuntu Hirsute)
no longer affects: fwupd (Ubuntu Impish)
Changed in libjcat (Ubuntu Focal):
status: New → Triaged
Changed in libjcat (Ubuntu Hirsute):
status: New → Triaged
Changed in libjcat (Ubuntu Impish):
status: New → Triaged
Revision history for this message
Mario Limonciello (superm1) wrote :

As mentioned in the description of this issue, libjcat is out of date and needs to be upgraded to 0.1.4 or later to solve this issue.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libjcat - 0.1.9-1

---------------
libjcat (0.1.9-1) unstable; urgency=low

  [ Debian Janitor ]
  * Trim trailing whitespace.
  * Use secure copyright file specification URI.
  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository,
    Repository-Browse.
  * Remove Section on libjcat1 that duplicates source.

  [ Mario Limonciello ]
  * Upgrade to 0.1.9 release. (LP: #1943833)

 -- Mario Limonciello <email address hidden> Fri, 14 Jan 2022 14:57:07 -0600

Changed in libjcat (Ubuntu Jammy):
status: Triaged → Fix Released
Changed in oem-priority:
importance: Undecided → Critical
Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

AI: add a condition for libjcat version on the debian control.

Changed in oem-priority:
assignee: nobody → Yuan-Chen Cheng (ycheng-twn)
summary: - Failed to update metadata for lvfs
+ fwupd failed to update metadata for lvfs
Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

create a pull request on upstream debian/control just to make the story complete

https://github.com/fwupd/fwupd/pull/4182

Changed in oem-priority:
status: New → In Progress
Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

As we are going to SRU fwupd 1.7.13 all the way back to focal, it seems to be more natural and will give consistent behaviors if we also SUR libjcat, and given the dependency of libjcat is quite simple.

I'll proceed in that way and we will see what the SRU team thinks then.

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote (last edit ):

I create a ppa with libjcat 0.1.9-1~20.04.1 for focal (and other debs).

https://launchpad.net/~ycheng-twn/+archive/ubuntu/fwupd-17x-jcat

If you can reproduce this issue on focal (maybe with kubuntu?), could you
just upgrade the libjcat1 from the ppa and update your test result?

Note: the PPA is for testing only, don't use it for production. And I will
not provide future upgrade paths not downgrade paths. It's on your own.

Changed in oem-priority:
importance: Critical → High
Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

lower priority to high as the reproduce step seems unclear yet.

Rex Tsai (chihchun)
tags: added: oem-priority
Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

I install Kubuntu 20.04.3 iso, I can reproduce this issue by remove files in ~/.cache/fwupd/remotes.d/lvfs/* and re-run discovery.

Then I install the libjcat in the ppa in #15, and reboot (just in case something not updated).
Then I run the test again, it still failed.

I think the failure might come from something hard-coded in plasma-discovery, but not in libjcat itself.

Well, maybe libjcat also needs an update but also needs to check source code for discovery.

Changed in oem-priority:
status: In Progress → Incomplete
Revision history for this message
Mario Limonciello (superm1) wrote :

Yeah; perhaps there is actually multiple bugs here.

One of them is definitely in the engine, using libjcat 0.1.3 or later (at compile time) will change daemon behavior:
https://github.com/fwupd/fwupd/blob/d7b682430efb8f0718306579f64ed4bda423b4a0/src/fu-engine.c#L3963
It needs this commit to be able to verify the timestamp properly: https://github.com/hughsie/libjcat/commit/6fa790b2f458557cbf0c5caf573a9d377ce4bd44

So the engine has been built against 0.1.3 in the most recent release in Ubuntu focal: https://launchpadlibrarian.net/549854359/buildlog_ubuntu-focal-amd64.fwupd_1.5.11-0ubuntu1~20.04.2_BUILDING.txt.gz

libjcat 0.1.4 fixes some ABI problems introduced by 0.1.3. I however don't find a reason to believe compiling against it (vs runtime) will fix this issue.

I looked at KDE discover source code (at least the latest version).
https://github.com/KDE/discover/blob/master/libdiscover/backends/FwupdBackend/FwupdBackend.cpp#L294

Looking at that I don't see any reason to think it's a problem in their code. They use the libfwupd client library for the update process, so any problems should be contained into that library and it's interaction with the daemon's engine.

That is both fwupdmgr and KDE discover use the exact same libfwupd for the refreshing of metadata.

I think we should approach debugging this a different way. YC can you take the files from ~/.cache that fail and see if they fail in jcat-tool as well? If so, it should be easier to walk through why they're failing with a debugger.

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

Hi Mario, Could you share the command to verify?

A quick cross-check, the file in ~/cache/fwupd/remotes.d/lvfs is the same if I compare the one downloaded by plasma-discover and "fwupdmgr refresh"

One more thing, it looks like the backends/FwupdBackend/FwupdBackend.cpp has been through lots of re-factoring. Mind have a look at the source code for the one used in focal.

One thing I can see is: new code just use fwupd_client_get_remotes_async, while old code seems download file and call fwupd_client_update_metadata.

Revision history for this message
Mario Limonciello (superm1) wrote (last edit ):

> Hi Mario, Could you share the command to verify?
$ jcat-tool info firmware.xml.gz.jcat --public-keys /etc/pki/fwupd-metadata/ --verbose

Compare the sha1/sha256 output from this to:
$ sha1sum firmware.xml.gz.jcat
$ sha256sum firmware.xml.gz.jcat

Then run this and make sure it passes:
$ jcat-tool verify firmware.xml.gz.jcat --public-keys /etc/pki/fwupd-metadata/ --kind pkcs7 --verbose

If that passes run this:
$ jcat-tool verify firmware.xml.gz.jcat --public-keys /etc/pki/fwupd-metadata/ --kind pkcs7 --verbose

> A quick cross-check, the file in ~/cache/fwupd/remotes.d/lvfs is the same if I compare the one downloaded by plasma-discover and "fwupdmgr refresh"

Good, so we don't have a downloader problem most likely.

>One thing I can see is: new code just use fwupd_client_get_remotes_async, while old code seems download file and call fwupd_client_update_metadata.

But in both cases it's using daemon and libjcat to do the verification. I think we need to fixate on the downloaded files to see what makes them complain from libjcat.

Revision history for this message
Mario Limonciello (superm1) wrote :

I was looking and have reason to believe this failure shouldn't occur on libjcat 0.1.6, which contains this: https://github.com/hughsie/libjcat/commit/98f747fb5d41e3e0d2a09a2c58adbd5f3df3a567

If you see it with newer version than 0.1.6, I want to see that daemon verbose output and the jcat-tool commands.

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :
Download full text (5.0 KiB)

~/.cache/fwupd/remotes.d/lvfs # jcat-tool info metadata.xml.gz.jcat --public-keys /etc/pki/fwupd-metadata/ --verbose
(jcat-tool:2361): GLib-GIO-DEBUG: 14:25:51.627: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
JcatFile:
  Version: 0.1
  JcatItem:
    ID: firmware-02863-stable.xml.gz
    AliasId: firmware.xml.gz
    JcatBlob:
      Kind: sha1
      Flags: is-utf8
      Timestamp: 2022-01-18T04:06:33Z
      Size: 0x28
      Data: 8cc4c03942af0835b85b38aee2f48227f91a1695
    JcatBlob:
      Kind: sha256
      Flags: is-utf8
      Timestamp: 2022-01-18T04:06:33Z
      Size: 0x40
      Data: 566d21eceb00017ade5d20fdfcf64efd81b3d20ac6f5c8d1b55df3b8846f6bfe
    JcatBlob:
      Kind: gpg
      Flags: is-utf8
      Timestamp: 2022-01-18T04:06:33Z
      Size: 0x1e8
      Data: -----BEGIN PGP SIGNATURE-----

                         iQEzBAABCAAdFiEEP8a4BEEO0IQNjy+XSKbYDkU4usIFAmHmPMkACgkQSKbYDkU4
                         usIogwf+OdBsBsj9WoBtcT1EumbopbUY6ul2azjQvPXGw+gCJrDbeokgEBUUuy5I
                         bnakPYKchg0HENviWKN+md2aMAu/ZoDl/eYdiKA6Hcz6daiumbDL0/jOU/SP9VOI
                         pgtdwTmmGIKz2PISuaiGN78jxfgDe02m7TAP/P7TK7ND7Yp7zMg+I7HZokPpM0+L
                         xllNsgMb7y7nIjAc4fTefdZkX88tyZHlDiwrJJbCjg8VcQX6M0eCGAl1vNTrIWGp
                         VBk3Du95+p5zWTvtJthYjuvewH2KwgJvetxB/5uG/VOBjHW6Kpf1mXr51Ippn7Hs
                         8qObBSW3fSsDtLJR+ifgCf3qIpYh/g==
                         =DW2w
                         -----END PGP SIGNATURE-----

    JcatBlob:
      Kind: pkcs7
      Flags: is-utf8
      Timestamp: 2022-01-18T04:06:34Z
      Size: 0x8c0
      Data: -----BEGIN PKCS7-----
                         MIIGUgYJKoZIhvcNAQcCoIIGQzCCBj8CAQExDTALBglghkgBZQMEAgEwCwYJKoZI
                         hvcNAQcBoIIEOjCCBDYwggKeoAMCAQICDFprhisibP88kP07YjANBgkqhkiG9w0B
                         AQsFADA6MRAwDgYDVQQDEwdMVkZTIENBMSYwJAYDVQQKEx1MaW51eCBWZW5kb3Ig
                         RmlybXdhcmUgUHJvamVjdDAeFw0xODAxMTYwMDAwMDBaFw0yODAxMTYwMDAwMDBa
                         MBkxFzAVBgNVBAMTDlJpY2hhcmQgSHVnaGVzMIIBIjANBgkqhkiG9w0BAQEFAAOC
                         AQ8AMIIBCgKCAQEArR5nseG3+Zs+o41P9LTspiVSGVcp6ifNHhbKKxBvZZXsy0gX
                         +P/VRlsHLiKQrFulQ8GbPODytFv0o+y/0MkiJxv/fY3yEZ2bwNpsSeXFQSGHI6yz
                         jaVNeNCu8lnnDtD7kiC8UNUNHcnA4+2h/Yv4k+KPqYF+Qb6nWAEIID1ObMnjeJUb
                         dbPPvy12aasV3gZcZ+goYNFc0ua6OU/CNEuzAVVCTAJ/EpCdGpll1+6BGU5ImIUG
                         TlMTWq2xmCfCPugakHrmWA66yHWwE6LmC/U7qQDWFemsSNnmzyBB9HPkqsW1DjHr
                         +ZmNUPj3+q2UGnNwP/Cne462XbsZB569w7pnzQIDAQABo4HcMIHZMAwGA1UdEwEB
                         /wQCMAAwNwYDVR0RBDAwLoYXaHR0cHM6Ly9md3VwZC5vcmcvbHZmcy+BE3JpY2hh
                         cmRAaHVnaHNpZS5jb20wEwYDVR0lBAwwCgYIKwYBBQUHAwMwDwYDVR0PAQH/BAUD
                        ...

Read more...

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote (last edit ):

# sha256sum metadata.xml.gz
b404fbe5d61c7b1c530c748db81f54215b2a759f2a247410de10dbe5708a115d metadata.xml.gz
# sha1sum metadata.xml.gz
30c4401b2b36b65943b878fd173ee94035e57af8 metadata.xml.gz

There is no firmware-02863-stable.xml.gz nor firmware.xml.gz in ~/.cache/fwupd/remotes.d/lvfs

There only have metadata.xml.gz metadata.xml.gz.jcat in that directory.

Note the sha1sum and sha256sum are different from those above.

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

Note #23 and #24 is tested with fwupd 1.7.3 and libjcat1 0.1.9~20.04.1 from ppa

https://launchpad.net/~ycheng-twn/+archive/ubuntu/fwupd-17x-jcat

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

Mario, sorry that I didn't manage to collect all log you need, yet. Will try when I can.

Revision history for this message
Mario Limonciello (superm1) wrote :

> Note the sha1sum and sha256sum are different from those above.

Are you sure these files got updated using fwupd 1.7.3? Can you please confirm timestamps updated for them and these aren't old stale files.

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote (last edit ):

fwupd 1.7.3 + jcat 0.1.9 on kubuntu/focal

  1. fwupdmgr refresh (with non-root account)
    metadata.xml.gz metadata.xml.gz.jcat goes to /var/lib/fwupd/metadata/lvfs
    sha1sum and sha256sum: match

# sha1sum *
a6a3e64a224ff04142c1d693f3c6e201a79d2dbb metadata.xml.gz
8a72e4e6b2280d81bc630807e58a1eef852dc595 metadata.xml.gz.jcat

  2. clean up /var/lib/fwupd/metadata/lvfs and run discover
    metadata.xml.gz metadata.xml.gz.jcat goes to ~/.cache/fwupd/remotes.d/lvfs
    sha1sum and sha256sum: not match

$ sha1sum *
ebda81ea07252679f402904c6172e4707fc60884 metadata.xml.gz
8a72e4e6b2280d81bc630807e58a1eef852dc595 metadata.xml.gz.jcat

Based on the above result, it's likely that discover downloaded the wrong metadata.xml.gz

AI: revert to fwupd 1.5.11 + jcat 0.1.3 and test again.

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

fwupd 1.5.11 + libjcat 0.1.3 on kubuntu/focal

  1. fwupdmgr refresh (with non-root account)
    metadata.xml.gz metadata.xml.gz.jcat goes to /var/lib/fwupd/remotes.d/lvfs
    sha1sum and sha256sum: match

# sha1sum *
a6a3e64a224ff04142c1d693f3c6e201a79d2dbb metadata.xml.gz
8a72e4e6b2280d81bc630807e58a1eef852dc595 metadata.xml.gz.jcat

  2. clean up /var/lib/fwupd/remotes.d/lvfs and run discover
    metadata.xml.gz metadata.xml.gz.jcat goes to ~/.cache/fwupd/remotes.d/lvfs
    sha1sum and sha256sum: not match

$ sha1sum *
ebda81ea07252679f402904c6172e4707fc60884 metadata.xml.gz
8a72e4e6b2280d81bc630807e58a1eef852dc595 metadata.xml.gz.jcat

PS: this is not consistent with my 2nd statement in #19.

Changed in oem-priority:
status: Incomplete → Triaged
Revision history for this message
Mario Limonciello (superm1) wrote :

Can you upload those bad files that discover fetched?

Revision history for this message
Mario Limonciello (superm1) wrote :

And does the daemon verbose log show anything?

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :

all good and bad files attached

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote :
Download full text (3.9 KiB)

Below is the log of fwupd during running discover in verbose mode. (-v)

 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(acpi_dmar)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuCommon reading /sys/firmware/acpi/tables/DMAR with 184 bytes
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPluginAcpiDmar OemTableId: Dell Inc
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPluginAcpiDmar CreatorId:
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPluginAcpiDmar Flags: 0x05
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(linux_lockdown)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(pci_bcr)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(uefi_pk)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(acpi_facp)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuCommon reading /sys/firmware/acpi/tables/FACP with 276 bytes
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPluginAcpiFacp Flags: 0x20c4f5
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(linux_tainted)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(linux_sleep)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(tpm)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(cpu)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(pci_mei)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0328 FuPlugin add_security_attrs(linux_swap)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0343 FuPluginLinuxSwap /swapfile file is unencrypted
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0343 FuPlugin add_security_attrs(iommu)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0343 FuPlugin add_security_attrs(msr)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0343 FuPlugin add_security_attrs(tpm_eventlog)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0343 FuPlugin add_security_attrs(uefi_capsule)
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0346 FuMain Called GetRemotes()
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extreme fwupd[2317]: 03:53:11:0391 FuMain Called GetDevices()
 一 20 11:53:11 ycheng-Latitude-7330-Rugged-Extre...

Read more...

Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote (last edit ):

full journal log from fwupd, most are not verbose, just for reference.

Revision history for this message
Mario Limonciello (superm1) wrote :

OK so comparing the good and bad - the downloads are both "good" downloads but the bad is an already extracted tarball! Unpacking the good, the good and bad both have the same checksums.

Revision history for this message
Mario Limonciello (superm1) wrote :

OK so KDE discover in 5.18 version downloads natively in QT using a QNetworkRequest. AFAICT QNetworkRequest doesn't by default request a compressed file, but needs to explicitly request this to the server: https://stackoverflow.com/questions/2340548/does-qnetworkmanager-get-accept-compressed-replies-by-default

Because of that this bug occurs with KDE discover. KDE discover 5.20.90 and newer have adopted libfwupd for doing the download and should no longer encounter this.

no longer affects: libjcat (Ubuntu Focal)
no longer affects: libjcat (Ubuntu Hirsute)
no longer affects: libjcat (Ubuntu Impish)
no longer affects: plasma-discover (Ubuntu Jammy)
Changed in plasma-discover (Ubuntu):
status: New → Fix Released
no longer affects: libjcat (Ubuntu Focal)
Changed in fwupd (Ubuntu Focal):
status: New → Invalid
Revision history for this message
Yuan-Chen Cheng (ycheng-twn) wrote (last edit ):

Based on this new result, SRU libjcat back to focal will be optional.

Changed in oem-priority:
importance: High → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers