Created attachment 396228 [details, diff] bluez5-udevadm_path_fix.diff This occurs because bluez udev rule /lib/udev/rules.d/97-hid2hci.rules expects udevadm to reside at /sbin/udevadm But on systems using either sys-fs/udev or sys-apps/systemd, udevadm lives at /usr/bin/udevadm sys-fs/eudev is not affected as it's udevadm is at /sbin/udevadm
The problem of that conditional change is that people would need to manually remember to rebuild bluez if they switch to eudev Looking to udev Changelog seems that the /sbin/udevadm link was dropped on purpose: 02 Mar 2014; Samuli Suominen <ssuominen@gentoo.org> udev-9999.ebuild: Punt /sbin/udevadm compability symlink which has been removed from sys- apps/systemd with 207's ebuild without bugs filed. The consumers should be fixed to not hardcode the path. Then, I was wondering if maybe would be better to always call /usr/sbin/udevadm (bluez will need /usr to be mounted always anyway) and eudev package should provide a symlink to support both locations
(In reply to Pacho Ramos from comment #1) > The problem of that conditional change is that people would need to manually > remember to rebuild bluez if they switch to eudev > > Looking to udev Changelog seems that the /sbin/udevadm link was dropped on > purpose: > 02 Mar 2014; Samuli Suominen <ssuominen@gentoo.org> udev-9999.ebuild: > Punt /sbin/udevadm compability symlink which has been removed from sys- > apps/systemd with 207's ebuild without bugs filed. The consumers should be > fixed to not hardcode the path. > > Then, I was wondering if maybe would be better to always call > /usr/sbin/udevadm (bluez will need /usr to be mounted always anyway) and > eudev package should provide a symlink to support both locations Or the other way around. Why not carry the /sbin/udevadm sym link in gentoo. It doesn't seem to be that much of a burden and maintains backwards compatibility.
Well, will CC the other teams then :/ (I don't mind either option...)
(In reply to Pacho Ramos from comment #3) > Well, will CC the other teams then :/ (I don't mind either option...) Rereading my post, I'm not trying to be difficult. The safest thing to do is just keep backwards compatibility. Not knowing why the link was removed, I am a bit reluctant to just add it to eudev. Nonetheless, that conditional in bluez is annoying and we will get rid of it. @systemd people. Any advice here.
From udev Changelog "The consumers should be fixed to not hardcode the path". This comment could be seen to contradict udev rules functionality, from 'man udev': "Execute an external program specified as the assigned value. If no absolute path is given, the program is expected to live in /usr/lib/udev; otherwise, the absolute path must be specified." It could also be argued that the source's udev rule should be generated with the correct path at build time but once again, people would still need to manually remember to rebuild bluez if they switch to eudev. I tried creating a udev rule with for example 'RUN+=$(which udevadm) ...' so the udevadm location will always be found but couldn't get this to work. Seems like the symlink is the way to go?
Is there a way to make the udev rule to try both? (if one fails, fallback to the other)
(In reply to Pacho Ramos from comment #6) > Is there a way to make the udev rule to try both? (if one fails, fallback to > the other) This works changing: ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \ ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb --property-match=HID2HCI_SWITCH=1" to be: ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \ ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb --property-match=HID2HCI_SWITCH=1" \ ENV{REMOVE_CMD}="/usr/bin/udevadm trigger --action=change --subsystem-match=usb --property-match=HID2HCI_SWITCH=1" It does result in an error being logged to syslog when it can't find /sbin/udevadm, but does successfully fall through and use the /usr/bin/udevadm command. Also had a look to see how other systemd enabled distros are handling the udevadm binary and any symlinking to it. # Fedora # /usr/bin/udevadm /usr/sbin/udevadm -> ../bin/udevadm # Ubuntu # /bin/udevadm /sbin/udevadm -> /bin/udevadm # Suse # /usr/bin/udevadm /sbin/udevadm -> /usr/bin/udevadm None of them edit the bluez rule, so is kept as using /sbin/udevadm As can be seen above, Ubuntu and Suse add the /sbin/udevadm symlink for compatibility. Fedora doesn't and so bluetooth resume would seem broken on this distro? And from udev Changelog as of udev-176: "The default install location of the 'udevadm' tool moved from 'sbin' to /usr/bin. Some tools expect udevadm in 'sbin', a symlink to udevadm needs to be manually created if needed, or --bindir=/sbin be specified." This looks like it still applies.
But doesn't make much sense to generate again the symlink on systemd/udev only for 1 package. What really surprises me is that bluez upstream keeps ignoring the issue :S
(In reply to Pacho Ramos from comment #8) > But doesn't make much sense to generate again the symlink on systemd/udev > only for 1 package. What really surprises me is that bluez upstream keeps > ignoring the issue :S Yes, if it really is one package. I mean we are currently aware of only one, but are there more ? I did see your query about it in the bluez mailing list archive with as yet no reply. I guess from their view they find the widest support by using /sbin/udevadm as this takes care of old udev versions and distros are providing compatibility symlinks anyway.
+*bluez-5.29 (22 Mar 2015) + + 22 Mar 2015; Pacho Ramos <pacho@gentoo.org> +bluez-5.29.ebuild, + +files/bluez-udevadm-path.patch, -bluez-5.27.ebuild: + Version bump, try both udevadm paths (#539844 by Rick Harris), drop old. +
(In reply to Rick Harris from comment #7) > (In reply to Pacho Ramos from comment #6) > > Is there a way to make the udev rule to try both? (if one fails, fallback to > > the other) > > This works changing: > > ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", > ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \ > ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change > --subsystem-match=usb --property-match=HID2HCI_SWITCH=1" > > to be: > > ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", > ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \ > ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change > --subsystem-match=usb --property-match=HID2HCI_SWITCH=1" \ > ENV{REMOVE_CMD}="/usr/bin/udevadm trigger --action=change > --subsystem-match=usb --property-match=HID2HCI_SWITCH=1" > > It does result in an error being logged to syslog when it can't find > /sbin/udevadm, but does successfully fall through and use the > /usr/bin/udevadm command. Re-opening this bug as the 'fix' no longer works. Due to changes in udev/systemd the failed command no longer falls through to the second command. Looks like our only available option now is to symlink as already discussed.
What systemd commit broke this again?
(In reply to Pacho Ramos from comment #12) > What systemd commit broke this again? Best info I can provide is that the fall through started failing in >=systemd-218.
@eudev, @udev, @systemd: can we agree on a common location for udevadm? It looks like rules need to specify the absolute path :|
(In reply to Pacho Ramos from comment #14) > @eudev, @udev, @systemd: can we agree on a common location for udevadm? It > looks like rules need to specify the absolute path :| Uh, why are rules calling udevadm in the first place? That to me would seem to be the primary issue.. let me look at what bluez is doing here. If they really need to, likely we should just add udevadm to the list of permitted executables/paths, so that it can always be called from rules files regardless.
(In reply to Ian Stakenvicius from comment #15) > (In reply to Pacho Ramos from comment #14) > > @eudev, @udev, @systemd: can we agree on a common location for udevadm? It > > looks like rules need to specify the absolute path :| > > Uh, why are rules calling udevadm in the first place? That to me would seem > to be the primary issue.. let me look at what bluez is doing here. > > If they really need to, likely we should just add udevadm to the list of > permitted executables/paths, so that it can always be called from rules > files regardless. hm seems to be a rather specific hack.. well, the alternative is to install a helper .sh script and call that instead; the .sh could call udevadm (and should work with the system $PATH, iirc).
How would it behave if we provide two different .rules files? One running with one path and one with the other path? In that case one of them will always succeed in udev/eudev/systemd setups :/
sys-apps/systemd-238 has moved udevadm location again and now installs at /bin/udevadm And so again breaks net-wireless/bluez udev rule 97-hid2hci.rules when udevadm is not in the specified path.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d0fe48785cce688dd6838794c810a3786c1bc1ef commit d0fe48785cce688dd6838794c810a3786c1bc1ef Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2019-06-10 11:22:54 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2019-06-10 11:22:54 +0000 net-wireless/bluez: Backport lots of fixes (from Fedora)... - Include multiple fixes backported by Fedora people - Stop relying on plugdev group and follow upstream policy (#679034) - Update udevadm PATH for current systemd (#539844) - Rename USE alsa to midi (#658862) Closes: https://bugs.gentoo.org/679034 Closes: https://bugs.gentoo.org/658862 Bug: https://bugs.gentoo.org/539844 Package-Manager: Portage-2.3.67, Repoman-2.3.13 Signed-off-by: Pacho Ramos <pacho@gentoo.org> net-wireless/bluez/Manifest | 1 + net-wireless/bluez/bluez-5.50-r3.ebuild | 267 +++++++++++++++++++++ .../bluez/files/bluez-5.50-sink-connect.patch | 72 ++++++ .../bluez/files/bluez-udevadm-path-r1.patch | 10 + net-wireless/bluez/metadata.xml | 9 +- 5 files changed, 354 insertions(+), 5 deletions(-)
