Issues initializing onerng on ubuntu artful (17.10)

[kakobrekla]

Hi,

there is an issue with the onerng software v3.6 on ubuntu 17.10 (and reportedly Debian 8 is affected as well). I have been debugging this for some time and it seems that the problem boils down to udev limitations, namely when udev service is ran at boot time, it will remain in read-only mode (reasoning being that at boot time (when udev runs), fs devices are not guaranteed to be writable). This in turn will prevent a successful run of onerng.sh and therefore device will not get initialized automatically upon insertion into USB port. This behavior been observed/confirmed on desktop machine and laptop. Manually restarting udev service via service udev restart will result udev service operating in in non-read-only mode, after which the onerng.sh will execute successfully.

Some details on udev read-only issue discussed elsewhere: https://www.raspberrypi.org/forums/viewtopic.php?t=210243#p1298398

Syslog:

Jan 27 20:40:48  kernel: [164242.854983] usb 3-1: new full-speed USB device number 9 using xhci_hcd
Jan 27 20:40:48  kernel: [164243.001833] usb 3-1: New USB device found, idVendor=1d50, idProduct=6086
Jan 27 20:40:48  kernel: [164243.001838] usb 3-1: New USB device strings: Mfr=1, Product=3, SerialNumber=3
Jan 27 20:40:48  kernel: [164243.001841] usb 3-1: Product: 00
Jan 27 20:40:48  kernel: [164243.001844] usb 3-1: Manufacturer: Moonbase Otago http://www.moonbaseotago.com/random
Jan 27 20:40:48  kernel: [164243.001847] usb 3-1: SerialNumber: 00
Jan 27 20:40:48  kernel: [164243.002775] cdc_acm 3-1:1.0: ttyACM0: USB ACM device
Jan 27 20:40:48  mtp-probe: checking bus 3, device 9: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
Jan 27 20:40:48  mtp-probe: bus: 3, device: 9 was not an MTP device
Jan 27 20:40:48  systemd-udevd[30474]: Process '/sbin/onerng.sh daemon 3-1' failed with exit code 1.
Jan 27 20:40:54  systemd-udevd[30474]: Process '/sbin/onerng.sh daemon ttyACM0' failed with exit code 1.

(Sidenote: Running /sbin# ./onerng.sh daemon ttyACM0 manually at this stage will result in a working device.)

After running service udev restart:

Jan 27 20:41:36  kernel: [164291.114909] usb 3-1: new full-speed USB device number 10 using xhci_hcd
Jan 27 20:41:36  kernel: [164291.257625] usb 3-1: New USB device found, idVendor=1d50, idProduct=6086
Jan 27 20:41:36  kernel: [164291.257630] usb 3-1: New USB device strings: Mfr=1, Product=3, SerialNumber=3
Jan 27 20:41:36  kernel: [164291.257633] usb 3-1: Product: 00
Jan 27 20:41:36  kernel: [164291.257636] usb 3-1: Manufacturer: Moonbase Otago http://www.moonbaseotago.com/random
Jan 27 20:41:36  kernel: [164291.257639] usb 3-1: SerialNumber: 00
Jan 27 20:41:36  kernel: [164291.258489] cdc_acm 3-1:1.0: ttyACM0: USB ACM device
Jan 27 20:41:36  mtp-probe: checking bus 3, device 10: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1"
Jan 27 20:41:36  mtp-probe: bus: 3, device: 10 was not an MTP device
Jan 27 20:41:36  systemd-udevd[30649]: Process '/sbin/onerng.sh daemon 3-1' failed with exit code 1.
Jan 27 20:41:42  OneRNG: firmware verification passed OK - version=3
Jan 27 20:41:42  systemd[1]: Stopping rng-tools.service...
Jan 27 20:41:52  rng-tools[30731]: Stopping Hardware RNG entropy gatherer daemon: rngd.
Jan 27 20:41:52  systemd[1]: Stopped rng-tools.service.

[MoonbaseOtago]

On Monday, 28 January 2019 9:14:48 AM NZDT Matic wrote: there is an issue with the onerng software v3.6 on ubuntu 17.10 (and reportedly Debian 8 is affected as well). I have been debugging this for some time and it seems that the problem boils down to udev limitations, namely when udev service is ran at boot time, it will remain in read-only mode (reasoning being that at boot time (when udev runs), fs devices are not guaranteed to be writable). This in turn will prevent a successful run of `onerng.sh` and therefore device will not get initialized automatically upon insertion into USB port. This behavior been observed/confirmed on desktop machine and laptop. Rebooting udev service via `service udev restart` will result udev service operating in in non-read-only mode, after which the `onerng.sh` will execute successfully.

Yes this was noted on the mailing list last year - it's a systemd implementation bug - I've reported it upstream, and I'm told it's fixed in later releases Paul