Currently we need to manually run: udevadm trigger --subsystem-match=bluetooth --action=add or simply: udevadm trigger because udev-postmount fails to get it triggered. Seems that it's because of using "--type=failed" option :-/ Reproducible: Always
an you test with udev-171-r5 and let me know if the issue is still there?
Is it safe enough for a "stable" system? I mean, I am running a mostly stable system, I guess I will be able to update && reboot and downgrade again without major problems, no? (I usually have no problems on running packages from testing, but as udev as a bit more "critical"... :)) Thanks for the info
I am actually about to open a stabilization request for that version of udev, so go for it. Also, if you have issues you should be able to downgrade.
Just tested and it's exactly the same issue :(
What would be the problem on simply running "udevadm trigger" in udev-postmount?
Can you please attach the udev rules you are having issues with to this message? I believe I may know what the problem is, but I need to see your udev rules to be sure. Thanks, William
Created attachment 298413 [details] 97-bluetooth.rules This one is upstream rule that should work
Created attachment 298415 [details] 70-bluetooth.rules And this is our customized rule that, personally, I think should be dropped. It was used in the past to start /etc/init.d/bluetooth, but, since bluez-4, that init.d script is needed to simply run udevadm trigger as udev-postmount doesn't trigger it
+*bluez-4.97-r3 (09 Jan 2012) +*bluez-4.97-r2 (09 Jan 2012) + + 09 Jan 2012; Pacho Ramos <pacho@gentoo.org> +bluez-4.97-r2.ebuild, + +bluez-4.97-r3.ebuild, +files/bluetooth-init.d-r1, -bluez-4.97-r1.ebuild, + -bluez-4.97.ebuild: + Reintroduce a bluetooth init.d script to trigger bluetooth devices after dbus + is started because, as talked with WilliamH, udev-postmount will be removed in + the near future due upstream no longer detecting failed triggers at early + boot. This should also solve bug 397673 by a.m. Drop old. +