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?
BTW both init/udev-retry.service from udev GIT and udev-post from Fedora
have the same problem (Mandriva is using Fedora version).
Attachment:
signature.asc
Description: This is a digitally signed message part.
