I’ve tried to upgrade firmware of my new SSD using qubes-fwupdmgr:
$ sudo qubes-fwupdmgr refresh
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2230 100 2230 0 0 14324 0 --:--:-- --:--:-- --:--:-- 14387
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1009k 100 1009k 0 0 2667k 0 --:--:-- --:--:-- --:--:-- 2662k
Validating directories
Successfully refreshed metadata manually
$ sudo qubes-fwupdmgr get-updates
======================================================
Dom0 updates:
======================================================
No updates available.
This is weird, as fwupdmgr sees the device:
$ sudo fwupdmgr get-updates
Devices with no available firmware updates:
• SSD 990 PRO 2TB
• System Firmware
• UEFI dbx
No updatable devices
What am I doing wrong?
EDIT: To make it even more weird, the device is listed as updatable when I run sudo qubes-fwupdmgr get-devices.
EDIT2: I’ve looked into the source of qubes-fwupdmgr. The command qubes-fwupdmgr get-updates calls fwupdmgr --json get-updates, which returns empty array of updatable devices. (Devices with no available update are skipped.) Digging further, it seems that Samsung just hasn’t uploaded the firmware in LVFS :(. So, maybe I’ll need to download it manually (it is signed).
If you’re looking for a way to get the twice-encrypted firmware file from the .iso in order to flash it with nvme instead of Samsung’s proprietary fumagician tool, this seems to work:
$ sudo nvme fw-commit -s 2 -a 0 /dev/nvme0
NVMe status: Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons(0x113)
Multiple Update Detected (MUD) Value: 0
If you are interested how I discovered the correct format:
Not sure what file to provide:
I can provide the decrypted file, but it complains immediatelly when running fw-download.
I can provide the enc file, but it complains when running the first fw-commit about bad size. (The file is slightly smaller.)
Mine was off by a letter, which I guess means there is no firmware update for my exact model. (Might have something to do with this sentence on the download page: “*990 PRO I 990 PRO with Heatsink will be manufactured using a mixed production between the V7 and V8 process starting September 2023.”)
Just for the record, I have the version without heatsink, as I already have a XL SSD heatsink.
So, the conclusion:
qubes-fwupdmgr seems to work well (as far as I have had opportunity to test it), but updatable device doesn’t imply that vendor (or anyone else) pushes updates to LVFS.
The howto above seems to be OK, just missing decryption of DSRD.enc end checking if the update is intended for the specific model.
There seems to be no update for my SSD.
Hopefully the Samsung’s bug doesn’t affect my SSD.
I see, thank you for the hints. On 4.2 RC4 e.g. qubes-dom0-update works fine. Interestingly fwupdmgr seems to be installed (did not install it separately), but the command mentioned above (sudo fwupdmgr get-updates) fails; could not resolve host: cdn.fwupd.org. Did not track down yet where the dns server for fwupdmgr is configured.
As a sidenote I like this tool. It lets you know that there may be many closed source files working on the machine, even if someone tries to set up a preferably opensource system.
Yes, I did try qubes-fwupdmgr as well (btw it looks like at least on earlier versions it worked without qubes as well see above). Thinking about the resolver issue, actually it should use sys-whonix for updates (it is configured for dom0 as well). Not sure yet what is going on.
If you want to debug network communication, you can use Wireshark, preferrably in a separate qube:
#!/bin/bash
# safety settings
set -u
set -e
set -o pipefail
# Assumes that both this VM and the target VM have added the default user to "wireshark" (or similar) group, so the user has enough permission to run dumpcap.
dumpcap -P -w - "$@" | qvm-run-vm @dispvm 'wireshark -k -i -'
@v6ak Thank you for the hints and the tip with Wireshark. That’s what I meant, while using --whonix e.g. in sudo qubes-fwupdmgr refresh --whonix
it fails (it also fails without whonix):
Traceback (most recent call last):
File “/usr/bin/qubes-vmexec”,line 5, in module sys.exit (main())
File “/usr/lib/python3/dist-packages/qubesagent/vmexec.py”, line 55, in main os.execvp(command[0], command)
File “”, line 574, in execvp"
Failed to refresh remote ‘lvfs’": Metadata download failed.
Although sys-whonix seems to work otherwise for dom0 while e.g. installing packages. If it’s only me, not sure why this occurs as I did not change the default settings much.
I also upgraded from 4.1 to 4.2 - Really love the dom0 upgrade and the new interfaces !
I had the same issue, downloaded and refreshed metadata manually to finally find out that I needed to install fwupd-qubes-vm on sys-whonix AppVM. Installing the package in template vm didn’t work probably due to scripts required in userspace.
Now everything works well refreshing and updating.
Thanks. Tried sudo apt install fwupd-qubes-vm in sys-whonix terminal (i.e. installing this package) and a firmware update in dom0 with --whonix. It said successfully refreshed metadata manually. Sometimes it fails but seems to work. There were no updates available atm.
