libera/#eudev/ Friday, 2022-11-11

NrmlHello everyone. I'm having a permission issue in a directory inside /sys which I think is being caused by eudev (vv~.09:27
Nrmler, eudev v.3.2.909:31
Nrmlthis is the issue:09:31
Nrmlls -l /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/09:31
Nrml[...]09:31
bb|hcbNrml: Can you try if the same problem is present in 3.2.11?09:32
Nrmldrw------- 6 root root    0 Nov 11 04:37 usb109:33
Nrmldrwxr-xr-x 6 root root    0 Nov 11 04:37 usb209:33
Nrmlusb1 being 0600 prevents Xorg server from detecting mouse and keyboard09:33
Arsenwouldn't that file be a symlink?09:33
Nrmlusb2, on the other hand, has the correct permissions09:34
NrmlArsen: no, these are directories (symlinks are elsewhere)09:34
Nrmlso, here's my question: why is usb1 permissions wrong, while usb2 is correct?09:35
Nrmlbb|hcb: I can try09:35
Nrmlbb|hcb: lemme see if I have eudev 3.2.11 in backports or wherever (3.2.9 is the newest for my distro right now)09:36
Nrmlbb|hcb: nope, no eudev >3.2.9 in backports or anywhere else I can see :-(09:52
NrmlBut back to my question: how can I find out why usb2 is being set up correctly (with 0755) while usb1 is wrong?09:53
Nrmlis there some kind of debug mode or extended logging or something I can set in eudev so it tells me why it did (or failed to do) that?09:54
* Nrml sighs10:12
Nrmljus10:12
Nrml*just looked at https://github.com/eudev-project/eudev, and you folks are all there (Arsen, bb|hcb, etc)10:14
Nrmlso if you can't or won't help me, I guess I'm just fscked... :-/10:15
Arsenpeople are busy10:17
Arsensorry, I haven't had a chance to offer help10:18
Arsen``udevadm info'' should offer help when ran on that device10:18
NrmlArsen: thanks, will have a look into that10:21
NrmlArsen: I ran `udevadm info` on both /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1 and usb2, and diffed the output: https://paste.debian.net/1260338/10:27
NrmlI can't see anything even remotely related to permissions or mode or 0600 vs 075510:27
Arsenit wouldn't be permissions, it'd be info on how the two devices differfrom the eye of udev10:29
NrmlOK10:29
Arsencanyou try udevadm test -a add /sys/...10:30
Arsenon the 0600 device10:30
NrmlArsen: will do, 1 min please10:30
Nrml(and thanks for the help BTW, and sorry if I sounded grumpy or discorteus at first)10:31
NrmlArsen: here it is: https://paste.debian.net/1260342/10:32
Nrml(full output, both stderr and stdin)10:33
Arsenhmm, are you sure this file is the problem at all?10:37
Arsenthis is a hub device, I don't think Xorg should be touching it anyway10:37
Arsenthough admittedly I don't know how Xorg decides what to touch10:37
Arsenworst case scenario, you might be best off adding a /etc/udev/rules.d/99-makehubs755.rules file that triggers on the variables ``test'' printed to set the permissions the way you want them10:38
NrmlArsen: Xorg does not touch it directly, as it's a directory. What it does is to traverse it down, to access the devices (keyboard and mouse) which are under it (ie, inside it)10:39
NrmlArsen: what I would really like to do is to find out *why* eudev is setting usb1 permissions differently than usb210:40
Arsenthe line ``test'' is referencing doesn't contain the code to set it's perms like that upstream it'd seem10:42
Arsentry running test on both and seeing the difference10:42
Arsenit should be listing the matched rules10:42
NrmlArsen: here's the diff: https://paste.debian.net/1260346/10:46
Arsenif you reboot are permissions still wrong?10:46
Arseneudev appears to be setting them to the same in both cases (since there's no diff on the MODE lines)10:46
NrmlArsen: yep, reboot changes nothing10:49
Arsencan you start udevd with --debug and check logs?10:50
NrmlArsen: I saw no MODE lines referring to /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb{1,2}, just to /dev/bus/usb/001/001 and /dev/bus/usb/002/00110:51
Nrml(in the `udevadm test` output)10:51
Arsenare those files not links? or do they not contain a node that is a link to those two /dev/ nodes?10:51
Arsenoh wait10:52
Arsenhmm10:52
NrmlArsen: they are not files nor links, they are plain diretories10:52
Arsenyeah, I'm not sure what'd be setting the permission on those sysfs nodes10:52
NrmlHummmrmr10:52
sam_can you try with latest eudev please or file a bug with your distribution?10:54
NrmlArsen: the default permissions on everything in /sys are set by the kernel, right? Is it possible/probable that it's the *kernel* that's setting them differently, and eudev is simply not touching them?10:56
Arsenas sysfs is a pseudofs the kernel is indeed doing the permissions10:57
NrmlOK10:57
Arsennot sure if eudev sets them anywhere explicitly to be honest... sorry10:57
NrmlHummmrmrm10:57
Nrmlre: "start udevd with --debug", do I just kill the current udevd, then restart it with --debug?10:58
ArsenI'd do it on a fresh boot10:58
Arsento have it be as clean as possible10:58
NrmlArsen: by fresh boot, you mean modifying initrd?10:59
bb|hcbNrml: BTW. What system is that? My hubs are like /sys/devices/pci0000:00/0000:00:14.0/usb1, while yours contain platform/scb11:01
Arsenunsure, no clue how your system boots ;)11:01
bb|hcbAnd yes, for kernel created stuff it may differ across different drivers11:02
Nrmlbb|hcb: This is a Raspberry Pi 4B 8GB running Devuan Chimaera11:03
bb|hcbAbout permissions, I do not think that eudev will touch anything outside /dev; based on the *.rules it will create /dev/something with the specified perms; that is why I recomended to try latest version, because there are changes to the rules there11:04
NrmlArsen: it does run eudev from initrd, AFAICT11:04
bb|hcbOh, good, I have couple of those handy11:04
Nrmlbb|hcb: they are *fantastic* machines11:04
NrmlI think I do have a kernel problem, then11:05
Nrml(ie, the kernel is setting the permissions differently for usb1 and usb2)11:05
bb|hcbOn mine the kernel is 5.10.74-v8 #1 SMP PREEMPT Tue Oct 19 04:33:14 CEST 2021 aarch64 GNU/Linux; and both usb1/2 are drwxr-xr-x11:08
Nrmlbb|hcb: what distro?11:09
bb|hcband eudev is 3.2.9-10~chimaera111:09
bb|hcbBTW. For Devuan there is a build in experimental but that would work on testing/ceres and not in chimaera11:10
NrmlOK, so yours is running Chimaera too11:10
NrmlHere eudev is the same 3.2.9-10~chimaera1 as yours, but my kernel is 5.15.65 #1 SMP PREEMPT Tue Sep 6 05:41:26 EDT 2022 aarch64 GNU/Linux11:11
NrmlOK, trying with another kernel11:13
NrmlSo, tried with another kernel (5.19.7 #1 SMP PREEMPT Tue Sep 6 05:43:43 EDT 2022 aarch64 GNU/Linux) and the permissions to /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1 changed to 770, unfortunately no cigar yet as I need 75511:31
NrmlBut it proves it's the kernel doing the setting, and that eudev is not touching it11:31
NrmlRight?11:31
bb|hcbYes, looks like...11:53
Nrmlbb|hcb: thanks for the confirmation.12:44
NrmlI just escalated the issue to the kernel guy. Let's see what he says.12:46
NrmlMeanwhile, I added a script to my /etc/boot.d that just does a `chmod 755 /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb*`, I think it's better than kludging a rule into udev to do the same12:48
NrmlThanks everyone and specially bb|hcb and Arsen for the assistance12:48

Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!