I’ve got Nitropy working on my Fedora-35 VM, and when I connect my Nitrokey Pro & use the command ‘nitropy pro list’ I get ‘Nitrokey Pro-ADA7 1-1:1.0’. However, when I then type ‘nitropy pro enable-update’ it says ‘Enabling firmware update mode. Done.’
When I then go to update my firmware using the command “nitropy pro update nitrokey-pro-firmware-v0.14-to_update.bin” or “nitropy pro update nitrokey-pro-firmware-v0.14-RC3-to_update.bin” I get an error that
“No Nitrokey Pro found in the update mode.
If you have Nitrokey Pro connected please run (requires libnitrokey):”
When I go back to check if there is a nitrokey connected, nothing shows up, and if I try to put it back in to update mode it says that no device was found, and perhaps one is already in update mode.
Any ideas why the Nitrokey is disappearing from the list and refusing to update when it is being successfully found initially?
After putting the Nitrokey in update mode, it gets detected as another USB device. You need to add the new USB device also as rule that it gets automatically added to the VM.
Things like firmware upgrade should be done natively e.g. by booting a Linux Live distro from USB.
Doing this in a VM could brick a device if the updater can’t handle interruption.
That said, I also update e.g. Nitrokey 3 in a VM when I do not have a native Linux system or a system available where I could boot a Live distro.
I guess Nitrokey Pro should work but with gnuk based Nitrokey Start I would not risk it as the update process is not too robust and tested (e.g. because the upstream author primarily uses hardware JTAG/SWD for flashing).
I’ve just tried this and I don’t get a second USB pop-up after I enable update mode in my Qubes VM’s. So I should be seeing it in my USB devices menu to then attach also to the VM?
I suppose the best move is to create a live Linux USB and try that. I’ll report back with my findings.
The firmware update feature for Nitrokey Pro has been introduced in later versions. So it might also depend on the version you have at hand. The firmware repo only mentions SWD/JTAG and DFU flashing. Both require interaction with the hardware and using a special cable for uploading the firmware. GitHub - Nitrokey/nitrokey-pro-firmware: Firmware for the Nitrokey Pro device
It could be that this has been revised and now also works via USB Serial and a special bootloader mode that you configured with nitropy.
I am not sure, whether this is ready, yet.
According to which documentation did you plan the update?
I would strongly not do this from qubes. At least you would need some udev rule that configures a ttyUSB0 device when the microcontroller is in DFU mode.
It could be that still a cable or jumper is necessary to flash the device.
Found a documentation of the software-only update process. As I thought, you will need udev rules to be created. Seems like it could be easily fixed if you have a recent Nitrokey Pro 2 and the described method works:
Even after apply those udev rules I still get the same issue with nitropy not finding a update-enabled nitrokey after I update-enable it and execute the command.
I’m assuming you are reffering to the following (once again thanks for helping):
SetAddress Request (13) to port 1
[14667.074255] usb 1-2: New USB device found, idVendor=20a0, idProduct=4108, bcdDevice= 1.01
[14667.074273] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[14667.074283] usb 1-2: Product: Nitrokey Pro
[14667.074289] usb 1-2: Manufacturer: Nitrokey
[14667.074294] usb 1-2: SerialNumber: 00000000000000000000ADA7
[14667.091330] hid-generic 0003:20A0:4108.000A: hiddev96,hidraw0: USB HID v1.10 Device [Nitrokey Nitrokey Pro] on usb-vhci_hcd.0-2/input0
Good news, booting in to a live fedora 36 workstation allowed me to successfully update my nitrokey, and I’m now getting the expected behavior (had an issue of inverted LED scheme, now fixed).
Your suggestion to boot to live USB was key. Thank you @nku
