Skip to content

Conversation

@zombiepigdragon
Copy link

The current udev rule name will not actually apply the uaccess tag in time for it to have the intended effect of setting the permissions to allow the local seated user to access the device. To do this, the rule must have a prefix <73 due to 73-seat-late.rules being the rule that actually uses the tag to set the appropriate permissions. This change moves the rule to a position where it will function as originally intended.
I suspect that the reason this was not noticed until now is because if the plugdev group is set up, it would permit access even without a functioning uaccess tag. At least on my desktop system (Fedora Linux) this group does not exist by default, and so with neither the group nor uaccess being set correctly the rules had no affect until the file was renamed as shown.

The current udev rule name will not actually apply the uaccess tag
in time for it to have the intended effect of setting the
permissions to allow the local seated user to access the device.
To do this, the rule must have a prefix <73 due to
"73-seat-late.rules" being the rule that actually uses the tag to
set the appropriate permissions. This change moves the rule to a
position where it will function as originally intended.
@zombiepigdragon
Copy link
Author

I did just notice that I missed #167 while troubleshooting the issue, and I would like to point out that in my case rebooting was not sufficient to fix the issue (I did try it). However, once I had renamed the file to change its priority, the change took affect without a further reboot.

@will-v-pi
Copy link
Contributor

Thanks for this - could you rename it to 60- as that's the priority used by the similar rules file in raspberrypi-sys-mods, and then I'm happy to merge this

@lurch
Copy link
Contributor

lurch commented Apr 16, 2025

Thanks for this - could you rename it to 60- as that's the priority used by the similar rules file in raspberrypi-sys-mods, and then I'm happy to merge this

If these udev rules files serve a similar purpose, should we try to make them more similar to each other, or make them identical and give them the same name? Or are they deliberately different because they're doing different things?

@will-v-pi
Copy link
Contributor

I think they serve different purposes - the sys-mods one is general for all Raspberry Pi devices (debug probe, picos, etc) so it doesn't need to be updated when new ones are released; whereas the specific rules in picotool (and openocd) are only targeting the specific devices those tools interact with, and provide a useful base for people to modify further (eg to support white-labelled Pico 2s with different VIDs/PIDs)

will-v-pi added a commit that referenced this pull request Apr 22, 2025
Adding the instructions is useful for linking to the file from elsewhere

Order fix supercedes #199
@will-v-pi
Copy link
Contributor

Superceded by #230

@will-v-pi will-v-pi closed this Apr 24, 2025
will-v-pi added a commit that referenced this pull request Apr 30, 2025
Adding the instructions is useful for linking to the file from elsewhere

Order fix supercedes #199
kilograham pushed a commit that referenced this pull request May 30, 2025
Adding the instructions is useful for linking to the file from elsewhere

Order fix supercedes #199
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants