From ArchWiki

usbtiny extra udev rule?

In the udev rules for usbtiny, there are 2 rules listed. Howver, adding the second one to my udev rules resulted in me not an "rc=-1" communication error when I tried to use my usbtiny. When I commented out this rule:

"SBSYSTEMS=="usb", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="0479", GROUP="users", MODE="0666"

everything worked fine. Not sure what the root of the issue is, but this rule makes the usbtiny programer unusable. -- Ssalenik (talk) 04:09, 6 March 2012‎

About udev rules

udevadm info -a -n [device name]


udevadm info -a -p $(udevadm info -q path -n [device name])

gives the same output but the latter is recommended by some Khampf (talk) 20:57, 5 February 2013 (UTC)Reply[reply]

Use of 'uaccess' instead of GROUP and MODE?

Bug openobex - relies on non-existing group plugdev, conflict with systemd made me rethink the rules I have been using for Logitech_Unifying_Receiver.

Currently, the following rule is taught to the user:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0666"

What about changing it to:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", TAG+="uaccess"

As a developer note, Ubuntu versions before 13.04 Raring needs TAG+="udev-acl" instead of uaccess. For compatibility with modern and legacy systems:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", TAG+="uaccess", TAG+="udev-acl"


Lekensteyn (talk) 10:16, 6 June 2013 (UTC)Reply[reply]

This discussion is about udev#Accessing firmware programmers and USB virtual comm devices.
I don't know the exact answer. Hopefully, I can add that I think does have a point that might be relevant.
Regid (talk) 13:08, 13 September 2019 (UTC)Reply[reply]



If you use multiple printers, /dev/lp[0-9] devices will be assigned randomly on boot, which will break e.g. CUPS configuration.

I don't use multiple printers, but doesn't system-config-printer handle this automatically? If so, a tip could be added. --Alad (talk) 08:38, 28 June 2014 (UTC)Reply[reply]

It might, unfortunately its gtk3 dependency discouraged me from even trying... -- Lahwaacz (talk) 09:01, 28 June 2014 (UTC)Reply[reply]

Mounting drives in rules

@Lahwaacz (how do I ping you?) The best reference I can find for the sytemd-mount line is here, from the issue I linked in the article. Presumably that will eventually turn up on as well. I tried to address the other two issues you flagged, please feel free to remove or modify the templates you added. Thank you for checking my additions. Herodotus (talk) 07:15, 25 March 2019 (UTC)Reply[reply]

Thanks, but the accuracy flag is due to the following statement, i.e. "As of this writing, however, it was found to be slow and unreliable." -- Lahwaacz (talk) 08:11, 25 March 2019 (UTC)Reply[reply]
Got it. There was also a style flag which I think you left. As for the statement in question, I know that it would be "original research" on Wikipedia; I'm not sure what our standards are here. Did you test the command yourself (in a udev rule) and find it to be fast and reliable, or did you just want references? Herodotus (talk) 08:47, 25 March 2019 (UTC)Reply[reply]
Even original research needs evidence, otherwise it's just empty statements. If something "was found", there has to be something (e.g. a bug report) especially considering that the previous sentence says that it is "recommended by systemd". -- Lahwaacz (talk) 19:34, 26 March 2019 (UTC)Reply[reply]