Unable to Update Key Ubuntu 20.04

[charles-d-burton]

Currently it looks like the python library is unable to recognize the solo key for updates in ubuntu 20.04, I've tested it on multiple machines with the result being the same that the device is not found while in bootloader mode. This is on a system with the latest release of the solo python library as well.

I've followed the instructions found here: https://docs.solokeys.io/udev/

When I plug in the key I get this from dmesg:

[  853.743595] usb 1-3.1: USB disconnect, device number 10
[  858.588314] usb 1-3.1: new full-speed USB device number 11 using xhci_hcd
[  858.913760] usb 1-3.1: New USB device found, idVendor=0483, idProduct=a2ca, bcdDevice= 2.00
[  858.913764] usb 1-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  858.913766] usb 1-3.1: Product: Solo
[  858.913767] usb 1-3.1: Manufacturer: Solo Keys
[  858.913768] usb 1-3.1: SerialNumber: 0123456789ABCDEF
[  858.945011] hid-generic 0003:0483:A2CA.000E: hiddev0,hidraw0: USB HID v1.11 Device [Solo Keys Solo] on usb-0000:03:00.0-3.1/input0
➜  udev git:(master) 

But when I run the update I get:

➜  udev git:(master) solo key update 

No Solo key found!

If you are on Linux, are your udev rules up to date?
Try adding a rule line such as the following:
ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a2ca", TAG+="uaccess"
For more, see https://docs.solokeys.io/solo/udev/

What's interesting is that when it's not in bootloader mode the python library picks it up and runs fine, but fails because the device is not in bootloader mode. Meaning the key still works fine on Linux I just can't update/patch it.

[nickray]

Do you have udev rules installed? I think with such recent Ubuntu you'd have a systemd that automatically detects FIDO2 keys (F1D0 HID usage page), but for the update / in bootloader mode you'd still need a dedicated udev rule.

[charles-d-burton]

Udev rules are installed as outlined in the report. That's an interesting thought though because I wonder if maybe it's not using the udev rules in normal operating mode but the udev rules aren't working in bootloader mode.

[TinLe]

I was seeing exact same errors as @charles-d-burton on 20.04 server. Turns out to be udev rules. It works if I test it as root. Fixing udev rules allow non-root users to access solokeys.

Also tested on Fedora 32 and saw exact same errors till I installed correct udev rules.

The file 70-solokeys-access.rules is missing a few items. Here is a diff.

diff 70-solokeys-access.rules.orig 70-solokeys-access.rules
12,13c12,13
< SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a2ca", TAG+="uaccess"
< SUBSYSTEM=="tty", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a2ca", TAG+="uaccess"
---
> SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a2ca", TAG+="uaccess", GROUP="plugdev", MODE="0660"
> SUBSYSTEM=="tty", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a2ca", TAG+="uaccess", GROUP="plugdev", MODE="0660"
16c16
< SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess"
---
> SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", TAG+="uaccess", GROUP="plugdev", MODE="0660"
19c19
< SUBSYSTEM=="hidraw", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="8acf", TAG+="uaccess"
---
> SUBSYSTEM=="hidraw", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="8acf", TAG+="uaccess", GROUP="plugdev", MODE="0660"

[uli-heller]

For me, I didn't do any modifications to the udev rules on ubuntu-20.04 desktop. Updating vom 3.0 to 4.0 worked perfectly:

uli@ulicsl:~/git/cloned$ solo key update
Not using FIDO2 interface.
Wrote temporary copy of firmware-4.0.0.json to /tmp/tmpztr486by.json
sha256sums coincide: b1822355eb1151f004cd7886ba338deee8c844...
using signature version >2.5.3
erasing firmware...
updated firmware 100%             
time: 7.56 s
bootloader is verifying signature...
...pass!

Congratulations, your key was updated to the latest firmware version: 4.0.0

[mikegee81]

I am encountering a similar problem were the key appears in normal mode but not bootloader mode. Could you please clarify how you updated to vom 4.0 on Ubuntu 20.04? I installed vom via pip3 but it is showing version 2.0.0.

UPDATE: I was able to successfully update the solokey to version 4.0.0 by removing all the udev rules in 70-solokeys-access.rules

[bofh69]

I had the same problem with a v2.0.0 solo and Ubuntu 20.04LTS.

I had an old udev-rules file so I removed it and then ran udevadm control --reload-rules. It didn't help.

What did help was to reboot the computer after removing the file. udevadm probably didn't completely remove the old rules. udevadm control --exit might have worked as well, but I didn't bother to read the manual until after restarting the computer.

[driehuis]

For whatever it's worth, I had an issue much like this. Systemd's fido_id couldn't access the report descriptor: fido_id[1051010]: 1-2:1.0: Failed to open report descriptor at '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/report_descriptor': No such file or directory I checked, and in fact there is no report_descriptor under that node.

My Solo key was fresh from the bag it arrived in. It was from the very first kickstarter release, and still had firmware that does not report a version.

As Ubuntu 20.04's systemd magic didn't set up the device properly, and there's not even a /dev/hidraw0 device node, I had to reflash the Solo key under Ubuntu 18.04. After reflashing with solo key update, Ubuntu 20.04 recognised the security key out of the box.

My guess is that the ancient firmware somehow did not set up all USB descriptors just right for fido_id to do its job.

[trallen]

I have encountered a similar issue (it sounds like it's a separate issue but may be related), where the device in bootloader mode occasionally won't be recognised under Ubuntu. Running "udevadm monitor -p" when the machine is in this state shows that udev is loading the device correctly, but after adding and binding the device, immediately issues a remove action.

In my case, rebooting the computer seems to reset something (I have no idea what), and the bootloader mode is recognised once more, and updates run successfully.