Star Labs Firmware Update Issue with qubes-fwupdmgr

d-arcy · February 15, 2026, 12:09pm

My Starlabs laptop is running firmware 25.02. The newest version is 25.12. Star Labs documentation refers to Qubes documentation: when I run the instructions listed here I get a “No updates available” message.

Is this expected?

OvalZero · February 15, 2026, 12:24pm

It’s only one of several ways to update. I don’t have a starlabs machine but for those who have:

What is the output of sudo qubes-fwupdmgr refresh ; sudo qubes-fwupdmgr get-updates?

What version of QubesOS are you running?

d-arcy · February 15, 2026, 3:01pm

I’m following the instructions you linked.

“No updates available” (I’m on 25.02; 25.12 should be available)

4.3

OvalZero · February 15, 2026, 3:06pm

There are some issues with fwupdmgr in R4.3 … like this one:

github.com/QubesOS/qubes-issues

qubes-fwupdmgr incompatible with fwupd in Qubes 4.3: remote not enabled, `Uri` not found

opened 05:37PM - 06 Jan 26 UTC

mattmccutchen

P: default needs diagnosis C: updates affects-4.3 C: firmware

### Qubes OS release Qubes OS 4.3 ### Brief summary After I upgraded my Qubes… OS 4.2 system in place to Qubes OS 4.3, I tried to run `qubes-fwupdmgr refresh` and `qubes-fwupdmgr update` and ran into several problems, all of which appear to relate to breaking changes between the fwupd versions used by Qubes 4.2 and 4.3 (1.8.17 and 2.0.16 respectively) that qubes-fwupdmgr hasn't caught up with. Details below. ### Steps to reproduce 1. Run `qubes-fwupdmgr refresh` in dom0. ### Expected behavior Some progress output indicating that the metadata is being downloaded. ### Actual behavior The command exits with status 0 and no output. ### Additional information I added some debug code to qubes-fwupdmgr and found that `get_remotes` finds no remotes. [This check](https://github.com/fwupd/fwupd/blob/471528b7cfe4e24337d81448e80bc125ed1fc171/contrib/qubes/src/qubes_fwupdmgr.py#L114) failed because fwupd [changed](https://github.com/fwupd/fwupd/commit/eee24b164255d655a8586569a682024d83266e98) to use a JSON boolean instead of the string `"true"`. I fixed that on my system. Then [this check](https://github.com/fwupd/fwupd/blob/471528b7cfe4e24337d81448e80bc125ed1fc171/contrib/qubes/src/qubes_fwupdmgr.py#L121) failed because [the `KeyringKind` field was removed from fwupd](https://github.com/fwupd/fwupd/commit/80d5f98eef9cc91724a4fbbcdab237cae4d1a722). That commit updated the copy of qubes-fwupdmgr in the fwupd repo to no longer check for the `KeyringKind` field, but that change apparently hasn't made it into Qubes OS. I applied the qubes-fwupdmgr change to my system. At this point, `qubes-fwupdmgr refresh` appeared to work as intended, but `qubes-fwupdmgr update` gave me an exception [here](https://github.com/fwupd/fwupd/blob/471528b7cfe4e24337d81448e80bc125ed1fc171/contrib/qubes/src/qubes_fwupdmgr.py#L204) because [the `Uri` field was removed from fwupd](https://github.com/fwupd/fwupd/commit/51cf6674435ece2febab15e8fe645d77eea70056). I changed qubes-fwupdmgr on my system to use `update["Locations"][0]` instead of `update["Uri"]`, which should be equivalent to the previous behavior in which fwupd synthesized the `Uri` field from the first location. At this point, `qubes-fwupdmgr update` offered me updates for several devices I had never seen it offer to update before: KEK CA, UEFI CA, and UEFI dbx on my Dell Precision 7550. I'm not certain this is safe / intentional, so I'm planning to hold off on these updates until someone more knowledgeable than me has a chance to look at the other issues I identified and maybe will have an opinion about these devices too. If appropriate, a separate forum thread could be started about this topic. To review, I found three issues with qubes-fwupdmgr: 1. `"true"` versus `True` 2. `KeyringKind` (already fixed in the fwupd repo) 3. `Uri` It looks like the current fwupd-qubes-dom0 package is based on version 1.9.28 of the fwupd repo. I imagine that fwupd-qubes-dom0 should be changed to be based on the same version of the repo as the fwupd package in dom0, which depends on the Fedora version in dom0. That way, any fixes that the upstream fwupd maintainers choose to make to the `contrib/qubes` files (such as (2)) will naturally flow to Qubes OS. Then issues (1) and (3) will need to be fixed, preferably in the fwupd repo and then flowing to Qubes OS. I would be open to submitting a PR for that part if it isn't too much work. For the convenience of other Qubes users looking for a workaround, here's the patch I'm currently using on my system that includes (1), (2), and (3). Of course, if you apply this patch and see behaviors you don't expect, I can't vouch for whether it's safe to proceed with the updates. ```diff --- /usr/share/qubes-fwupd/src/qubes_fwupdmgr.py.mattorig 2025-02-27 19:00:00.000000000 -0500 +++ /usr/share/qubes-fwupd/src/qubes_fwupdmgr.py.mattnew 2026-01-06 11:49:02.882719572 -0500 @@ -113,19 +113,12 @@ for remote in remotes_list: name = remote["Id"] # skip disabled - if remote.get("Enabled", "true") != "true": + if remote.get("Enabled", "true") != True: continue # skip local - for metadata refresh, we only care about those # actually needing refreshing if remote.get("Kind") != "download": continue - # skip unsupported keyring kind - if remote.get("KeyringKind") not in ("jcat",): - print( - "Skipping remote '{}' due to unsupported keyring type '{}'".format( - name, remote.get("KeyringKind") - ) - ) assert "MetadataUri" in remote remotes[name] = remote["MetadataUri"] @@ -221,7 +214,7 @@ "Releases": [ { "Version": update["Version"], - "Url": update["Uri"], + "Url": update["Locations"][0], "Checksum": update["Checksum"][-1], "Description": update["Description"], } ```

I don’t know if the patches have been finally merged and rolled out yet. If I were you, I’d boot some compatible linux distro image on that machine and perform the updates via linux.

marmarek · February 16, 2026, 8:47pm

Indeed fixes for qubes-fwupdmgr needs to be installed for it to work. They are currently in the testing repository - you can either enable it, or wait for it to land in the stable repo - likely later this week.

d-arcy · February 25, 2026, 9:51am

Updated Qubes. This is the output of sudo qubes-fwupdmgr refresh:

cat: /home/user/.cache/fwupd/metadata firmware.xml.zst.asc: No such file or directory
Failed to refrest remote ‘lvfs’: qvm-run Copying metadata signature failed!!

d-arcy · February 26, 2026, 5:15pm

Unfortunately qubes-fwupdmgr is still not working for me - please see post above.

remedy · February 27, 2026, 7:46pm

Also not working for me. I’m not on Star Labs though and this is after doing a dom0 update and reboot.

sudo qubes-fwupdmgr refresh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 15418  100 15418    0     0   115k      0 --:--:-- --:--:-- --:--:--  115k
Validating directories
Traceback (most recent call last):
  File "/usr/libexec/qubes-fwupd/fwupd_download_updates.py", line 154, in <module>
    main()
    ~~~~^^
  File "/usr/libexec/qubes-fwupd/fwupd_download_updates.py", line 146, in main
    dn.download_metadata(url=url)
    ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/usr/libexec/qubes-fwupd/fwupd_download_updates.py", line 110, in download_metadata
    self._download_metadata_jcat()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/libexec/qubes-fwupd/fwupd_download_updates.py", line 96, in _download_metadata_jcat
    os.rename(path, new_path)
    ~~~~~~~~~^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/home/user/.cache/fwupd/metadata/firmware-08628-stable.xml.zst.p7b' -> '/home/user/.cache/fwupd/metadata/firmware.xml.zst.p7b'
Failed to refresh remote 'lvfs': Metadata download failed.

remedy · March 4, 2026, 2:51pm

Updated Dom0 again yesterday and now it works.