Hello
I would like to know why do we need to run things like:
udevadm trigger --subsystem-match=bluetooth --action=add
or even simpler:
udevadm trigger
Manually or using a "bluetooth" init.d script to simply run that or,
otherwise, bluetooth adapter is not detected. Reading OpenSuSE Changelog
in their bluez package seems that this is caused because dbus needs to
be running to get it detected. In that case, I would like to know why
only bluez looks to be affected by this problem and, also, know if there
is another way to workaround (or fix) this issue than needing to add a
bluez init.d script to simply run this
Thanks a lot
El mié, 04-01-2012 a las 22:59 +0100, Pacho Ramos escribió:
> Hello
>
> I would like to know why do we need to run things like:
> udevadm trigger --subsystem-match=bluetooth --action=add
>
> or even simpler:
> udevadm trigger
>
> Manually or using a "bluetooth" init.d script to simply run that or,
> otherwise, bluetooth adapter is not detected. Reading OpenSuSE Changelog
> in their bluez package seems that this is caused because dbus needs to
> be running to get it detected. In that case, I would like to know why
> only bluez looks to be affected by this problem and, also, know if there
> is another way to workaround (or fix) this issue than needing to add a
> bluez init.d script to simply run this
>
> Thanks a lot
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Looks like, on Gentoo, we have an init.d script that runs:
udevadm trigger --type=failed -v
after dbus is running, but looks like running udevadm trigger with
"--type=failed" option won't start bluetoothd... will investigate it a
bit more, sorry for the noise :S