On Sat, Aug 14, 2010 at 18:16, Andrey Borzenkov <arvidjaar@xxxxxxx> wrote: > I was puzzled why my bluetoothd was not started on boot. It turned out > the following: > > - bluetoothd requires D-Bus so attempt to start it early (may be, as > early as initrd) fails > > - event is saved as failed event; but only device path is preserved, no > information about which event type failed > > - later udevadm trigger --type=failed is run; but by default this > triggers "change" event instead of "add". There is no "change" action > for bluetooth subsystem (nor do I think it normally emits such event) so > nothing happens. > > This change was introduced relatively recently in > > commit 236fae6cf1a619a92174efdf84cd7d91e7d4348d > Author: Kay Sievers <kay.sievers@xxxxxxxx> > Date: Mon Apr 12 17:56:32 2010 +0200 > > udevadm: trigger - switch default action from "add" to "change" > > > Now, I could of course just go and add --action=add to udev-post > initscript. The question is - is it correct to assume that every failed > event is "add"? Should not event type be preserved for later correct re- > trigger? It should match what we do in the initial init scripts, so adding --action=add seems right. The defaults seems fine, which are always 'change'. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html