Refreshing metadata from LVFS on every run is overkill about firmware-manager HOT 7 CLOSED

We're using fwupdmgr refresh at the moment, because otherwise I kept getting an error about the signature being invalid when using the DBus bindings. Any idea why fwupd would give this error?

Failed to update metadata for lvfs: '48A6D80E4538BAC2' is not a valid signature

Seems to be related to this fwupd issue, although it works with fwupdmgr refresh.

In the meantime, I can record how often we're calling fwupdmgr refresh.

from firmware-manager.

Have you tried comparing the files downloaded locally to see if you're encountering the same issue exactly? That issue you linked does show a pretty good detail of what's happening.

If it is the same issue just trying again a few minutes later will probably fix it.

The correct fix probably has to be done on the CDN if so.

from firmware-manager.

It must have been a CDN issue. It's working today, though I'm wondering why fwupdmgr refresh would work when our client would get the invalid signature error.

from firmware-manager.

Based on my understanding of the CDN issue my guess would be strictly bad timing on the file as it was cached. Think of this scenario.

0. Metadata and signature are in sync on CDN
1. You download signature file
2. CDN changes metadata file.
3. You download metadata file. Your client caches it.
4. You try to load it and it fails.
5. You try again, but your metadata and signature are marked new so client doesn't do it again?

If that's the hypothetical cause, then the solution to me is to invalidate the cached file from your client if the daemon fails to load it.

from firmware-manager.

That makes sense, and that's probably it.

from firmware-manager.

@superm1 can you please write how do you purge the CDN cache from your computer if this happens? There are two issues mentioning this problem, both suggest purging cache, but none says how to do it. Thanks

from firmware-manager.

@paloha remove the cached files (such as firmware.xml.gz and firmware.xml.gz.asc and firmware.jcat) from your client's cache location as well as from the daemon cache location. I don't know where firmware-manager keeps them (guesses include ~/.cache/firmware-manager or ~/.firmware-manager).
The daemon should have them in /var/cache IIRC.

from firmware-manager.