On Tue, Mar 22, 2011 at 8:44 AM, Tom Gundersen <teg@xxxxxxx> wrote: > On Tue, Mar 22, 2011 at 3:59 AM, Seblu <seblu@xxxxxxxxx> wrote: >> So, this situation is a bit confusing, so why do not remove >> /lib/udev/rules.d/97-bluetooth.rules? > > I don't think it is a good idea to remove these rules, at they allow > bluez to be started on demand rather than unconditionally. I'd rather > try to fix it :-) I agree about trying to fix it. But I don't see how to do this except by running a kind of "/sbin/udevadm trigger --action=add" at end of rc.multi. > > Could you try running "/sbin/udevadm trigger --action=add > --type=failed" after dbus has started? It does nothing. And that's why I lost time before going to look at why dbus does not start. I feel that udevadm do not realize that launching dbus failed. Maybe based on return code (i don't yet checked). But in any case, if we do not modify the initscripts, the call for errors is done too early. -- Sébastien Luttringer www.seblu.net
