Bug 1789 - udev rules don't work right in ubuntu 20.04.4
Summary: udev rules don't work right in ubuntu 20.04.4
Status: CONFIRMED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Other (show other bugs)
Version: 0.4.1
Hardware: All All
: Normal blocker
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-12 01:23 CEST by Brian
Modified: 2023-07-03 11:21 CEST (History)
3 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian 2022-08-12 01:23:22 CEST
Using several different editions of sigrok, including the 0.4.2 release,
and a couple different nightlies, of about this date, I found it possible to find USB hardware only by running as root.

With the sigrok-provided udev rules installed, the pulseview invocations didn't work with any hardware, with or without being root, and the system log (category Other) reported many errors of the form:

/etc/udev/rules.d/61-libsigrok-uaccess.rules:26 Invalid key/value pair, ignoring

for numerous item numbers 8..26, and for all three rules.
Comment 1 Peter Mortensen 2022-08-12 17:32:55 CEST
What did you use?

I have used these command lines without any problems on both Ubuntu 18.04 (18.04.06 LTS. Kernel version 4.15.0-191.202-generic 4.15.18) and Ubuntu MATE 20.04 with Cinnamon (underlying Ubuntu 20.04.04 LTS. Kernel version 5.4.0-122.138-generic 5.4.192):

    sudo bash
    cd /etc/udev/rules.d/
    wget -O 60-libsigrok.rules "https://sigrok.org/gitweb/?p=libsigrok.git;a=blob_plain;f=contrib/60-libsigrok.rules"
    wget -O 61-libsigrok-plugdev.rules "https://sigrok.org/gitweb/?p=libsigrok.git;a=blob_plain;f=contrib/61-libsigrok-plugdev.rules"
    wget -O 61-libsigrok-uaccess.rules "https://sigrok.org/gitweb/?p=libsigrok.git;a=blob_plain;f=contrib/61-libsigrok-uaccess.rules"
    sudo udevadm control --reload-rules

It is more or less from direct the manual, <https://sigrok.org/doc/pulseview/unstable/manual.html>. The instructions were changed at some point (several years go). The corrected instructions are the ones listed here. 

The manual link broke and is still broken. Alternatives are:

  <https://sigrok.org/doc/pulseview/0.4.1/manual.pdf>

  <https://sigrok.org/doc/pulseview/0.4.2/manual.pdf>
Comment 2 Peter Mortensen 2022-08-12 17:34:03 CEST
*direct from the manual
Comment 3 Brian 2022-08-12 23:13:48 CEST
Thank you, Peter.

My script is slightly different from the given one in that it includes making a local copy of the udev files, but I have done it both ways and diffed the resulting files.  They are in fact identical.

So, I am unclear whether the log messages are normal, or not.  Perhaps, it is something like there is no hardware connected that matches most of the rules.
Or perhaps, something has changed and they haven't changed accordingly.
I don't understand the content of the udev rules at all.

I was wrong in saying that configuring the rules prevented pulseview from seeing USB hardware when run as root.  That actually works fine; with or without the sigrok udev rules.

It is still the case that the rules don't fix the main problem, which is that you have to run pulseview as root for it to see USB hardware; with or without the sigrok udev files.

I have tried all these combinations with a current nightly appimage, a current release appimage, and a version of pulseview that I have built from source, and am running from the sr directory.
Comment 4 Peter Mortensen 2022-08-14 03:25:30 CEST
I can not confirm this problem.

After a lot of yak shaving, I tested it on a fresh Ubuntu 22.04 system and the udev rules worked just fine, just as they did on the same hardware with a Ubuntu 20.04 system and on a 18.05 system on another computer.

I built PulseView from source as the AppImage didn't work ("... Symbol lookup error: /usr/lib/x86_64-Linux-GNU/libgio-2.0.so.0: Undefined symbol: g_module_open_full"), even after installing FUSE 2.
Comment 5 Brian 2022-08-14 23:20:56 CEST
Thank you, Peter

OK, looking across the web there have been many comments about not being able to run pulseview as non-root over the last several years.  Many said that they had put the rules in, without success, as with me.

Therefore, it seems to me that the rules probably do work as required, and are probably necessary, but are not sufficient to enable operation non-root.

I do not know enough about USB to further troubleshoot the problem, at this time.
Anyway, it seems that the title of this bug report is incorrect and this report should be closed or cancelled, or something.  Who does this?

Thank you for your efforts.
Comment 6 Brian 2022-08-16 15:09:48 CEST
One additional note.

Running the same SR build of pulseview as root, and as normal user,
with the log level set to 5 shows that there are two basic differences.

1. Different config directories are used.

2. The root instance reports 1 devices found, while
   the user instance reports 0 devices found.

This seems to indicate that the USB really is still not visible to pulseview even with the UDEV rules installed.  Unfortunately the log does not indicate the exact response from the USB system (unless the count is the response).
Comment 7 Brian 2022-08-18 23:52:10 CEST
It is finally working.  It is vary strange.  I discovered that both my script and the one taken from the manual were in fact not delivering the real udev files, and they were both delivering the identical files with each other.  The files delivered were full of html stuff that was naturally ignored.  I discovered this when I finally looked at the files in libsigrok/contrib.  They are the real files, and using them worked perfectly.

I am not sufficiently acquainted with wget to figure out what went wrong.

So now this issue is complete other than the wget mystery.
Comment 8 Peter Mortensen 2022-08-31 01:25:49 CEST
The result with wget is often some HTML content if something goes wrong.

Say, trying to download some large binary file that doesn't exist any longer, or the URL is incorrect. Then some HTML content of a small size is returned instead.
Comment 9 Vojtech Vesely 2023-07-03 11:21:28 CEST
Shouldn't this issue be closed?