On Mon, 2009-07-13 at 18:07 -0500, Mario Limonciello wrote: > Hi Bastien: > > Mario Limonciello wrote: > > Hi Bastien: > > > > Bastien Nocera wrote: > > > > Currently in the Ubuntu udev init script there is a call to 'udevadm > > trigger' (without any arguments). Without any arguments it appears the > > default is "--type=devices". When I add --type=failed (--retry-failed > > is deprecated), the system fails to boot up to X. If I return it back > > to it's old state and add a second call right afterward of > > "--type=failed", there is no difference in behavior. bluetoothd still > > fails to spawn by the udev rule. > > > I'm actually suspecting that this is caused by dbus daemon not being > spawned early enough for bluetoothd to have access to. Which is why you need to retry the failed rules later on. > I've come to > this conclusion by putting a shell wrapper around bluetoothd and > capturing exit code status to see that it does get spawned at startup > but immediately exits. I put a pgrep at the same time to check for > dbus, and didn't see it running. > > How are you ensuring that dbus is running by the time that udev starts > processing rules in Fedora then? > > For now the only solution I can come up with is to maintain an init > script that runs "udevadm trigger --subsystem-match=bluetooth". Since > multiple invocations of bluetoothd --udev won't harm the system, it's > not that horrible of a workaround, but still ideally would like to lose > the init script altogether. You need to call with the --retry-failed, after the basics of the system have been brought up. This means starting up D-Bus, mounting network filesystems, etc. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
