NVMe Firmware: I Need Your Data

In a recent Google Plus post I asked what kind of hardware was most interesting to be focusing on next. UEFI updating is now working well with a large number of vendors, and the LVFS “onboarding” process is well established now. On that topic we’ll hopefully have some more announcements soon. Anyway, back to the topic in hand: The overwhelming result from the poll was that people wanted NVMe hardware supported, so that you can trivially update the firmware of your SSD. Firmware updates for SSDs are important, as most either address data consistency issues or provide nice performance fixes.

Unfortunately there needs to be some plumbing put in place first, so don’t expect anything awesome very fast. The NVMe ecosystem is pretty new, and things like “what version number firmware am I running now” and “is this firmware OEM firmware or retail firmware” are still queried using vendor-specific extensions. I only have two devices to test with (Lenovo P50 and Dell XPS 13) and so I’m asking for some help with data collection. Primarily I’m trying to find out what NMVe hardware people are actually using, so I can approach the most popular vendors first (via the existing OEMs). I’m also going to be looking at the firmware revision string that each vendor sets to find quirks we need — for instance, Toshiba encodes MODEL VENDOR, and everyone else specifies VENDOR MODEL. Some drives contain the vendor data with a GUID, some don’t, I have no idea of the relative number or how many different formats there are. I’d also like to know how many firmware slots the average SSD has, and the percentage of drives that have a protected slot 1 firmware. This all lets us work out how safe it would be to attempt a new firmware update on specific hardware — the very last thing we want to do is brick an expensive new NMVe SSD with all your data on.

So, what do I would like you to do. You don’t need to reboot, unmount any filesystems or anything like that. Just:

  1. Install nvme (e.g. dnf install nvme-cli or build it from source
  2. Run the following command:
    sudo nvme id-ctrl --raw-binary /dev/nvme0 > /tmp/id-ctrl
  3. If that worked, run the following command:
    curl -F type=nvme \
        -F "machine_id="`cat /etc/machine-id` \
        -F file=@/tmp/id-ctrl \

If you’re not sure if you have a NVMe drive you can check with the nvme command above. The command isn’t doing anything with the firmware; it’s just asking the NVMe drive to report what it knows about itself. It should be 100% safe, the kernel already did the same request at system startup.

We are sending your random machine ID to ensure we don’t record duplicate submissions — if that makes you unhappy for some reason just choose some other 32 byte hex string. In the binary file created by nvme there is the encoded model number and serial number of your drive; if this makes you uneasy please don’t send the file.

Many thanks, and needless to say I’ll be posting some stats here when I’ve got enough submissions to be statistically valid.

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

25 thoughts on “NVMe Firmware: I Need Your Data”

  1. Already sent data your way, mine is a Lenovo T460p with SSD 256 GB, PCIe-NVMe OPAL2.0.

    Thank you for working on this!

  2. How to upload data for multiple NVMe drives on the same machine? Trying to upload data for the second drive I received “already reported from this machine-id”. Commands used:

    curl -F type=nvme -F “machine_id=”`cat /etc/machine-id` -F file=@id-ctrl-nvme0 https://staging.fwupd.org/lvfs/upload_hwinfo


    curl -F type=nvme -F “machine_id=”`cat /etc/machine-id` -F file=@id-ctrl-nvme1 https://staging.fwupd.org/lvfs/upload_hwinfo


      1. After changing dba1cd96c90e4d73908ae79cbc149bc9 to dba1cd96c90e4d73908ae79cbc149bca I was able to upload the file. Also uploaded data extracted from a 3rd disk, from a different manufacturer.

  3. Right now I see things are very much desktop focused – do you have plans to encourage manufacturers/promote support for server hardware?

    1. Yes, although it’s harder, as “enterprise” hardware is a huge cash cow for support. I can’t share info yet, but the “redfish” plugin in fwupd should hearten you.

      1. Good to hear, and agreed it’s a bit chicken and egg, I’d love to try to pressure vendors, however it’s a tough sell if no one else is doing it yet. I’ll keep an eye out for the redfish support, I’d be interested to see if that can only do remote via ip or also covers the host interface spec for in-band support. Looking forward to it either way :)

  4. Sent you the info on my Intel 750 256 GB NVMe SSD, which required a firmware update to not corrupt FAT32 partitions hideously on shutdown if they were written to in the last couple of minutes without the hacky workaround of using a “sync” mount option. (Given I habitually use systemd-boot which runs kernels from UEFI, this caused… problems… every time a new kernel was installed until I figured it out, and longer for them to release the update.)

      1. Nope – Sorry, it’s been a year and a half since this was resolved, and I’m not sure if I would have or did keep anything that would let me know that, let alone where it is.

  5. Can’t seem to get the curl command to work on my system, curl seems to really dislike the output file produced:

    root@viper:~# nvme id-ctrl –raw-binary /dev/nvme0 > /boot/id-ctl
    binary output
    root@viper:~# curl -F type=nvme -F “machine_id=”`cat /etc/machine-id` -F file=@/boot/id-ctrl https://staging.fwupd.org/lvfs/upload_hwinfo
    Warning: setting file /boot/id-ctrl failed!
    curl: (26) read function returned funny value

  6. Done. btw, on openSUSE you can install the tool with:

    sudo zypper in nvme-cli

    Further more many thinks for all your work!

  7. Can’t get it to send the file.
    If i leave the machine-id as is it says that it has already been reported, which is not true.
    If i put a random machine-id it says it’s invalid

  8. Just sent the data for the Toshiba THNSN51T02DUK that came with my Dell XPS 15 9560. Thanks for the hard work!

Comments are closed.