[4.2] Upgrading SSD firmware

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:

Although I haven’t tried the actual flashing.

I’ve done this:

  1. Download the iso file from Samsung Magician & SSD Tools & Software Update | Samsung Semiconductor Global
  2. Mount it somewhere using sudo mount -o loop file.iso mountpoint
  3. Unpack the initrd using cat …/initrd | gunzip | cpio -id
  4. Decrypt root/fumagician/.enc by GitHub - Qwertylex/samdecrypt.sh (see readme to extract the key)
  5. Unzip the file.
  6. Use samdecrypt.sh to the unzipped file (yes, it is encrypted twice…)
  7. Flash the unzipped file as decribed at Solid state drive/NVMe - ArchWiki

No, I am not done yet:

$ 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.)

I’ve also found some Samsung firmware collection. It contains some older firmware for this SSD, but at least it can allow me to compare with firmware extracted from the official image of the same version:

rw-r--r-- 1 user user 2097152 Nov 18 21:55 ../../../1B2QJXD7_20230201.bin
-rwxr-xr-x 1 user user 2085984 Nov 18 22:00 ./1B2QJXD7.enc*

WTF, it is larger by about 11 kB. Oh, the decrypted file is actually a zip, which contains exactly the (larger) bin.

Does your current 990 Pro drive firmware have one of the three <CURFW> versions in DSRD.bin?


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.”)

1 Like

Nice finding. My current firmware version is also off by one letter (…G7, the update is for …D7). I hope it is not impacted by the rapid degradation bug that eventually leads to SSD becoming read-only.

Just for the record, I have the version without heatsink, as I already have a XL SSD heatsink.

So, the conclusion:

  1. 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.
  2. The howto above seems to be OK, just missing decryption of DSRD.enc end checking if the update is intended for the specific model.
  3. There seems to be no update for my SSD.
  4. Hopefully the Samsung’s bug doesn’t affect my SSD.

You seem to be correct about the V7/V8 process:

Reddit - Dive into anything


1 Like

Is it supposed to work in dom0 out of the box on 4.2 RC4?

IIUC it is supposed to work, qubes-fwupdmgr is a wrapper for fwupdmgr that uses an UpdateQube.

Out of box? Strictly speaking no, as it isn’t installed by default. Nothing else seems to be needed, though.

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.

There might be a difference between clean install (maybe your case) and upgrade (my case).

You cannot use fwupdmgr directly, you need to use **qubes-**fwupdmgr instead.

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.

Maybe you need to use --whonix.

If you want to debug network communication, you can use Wireshark, preferrably in a separate qube:

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