Description of problem: The first time I login after boot, I always get the "Oh no!" screen. Subsequent login attempts work fine. Looking in /var/log/messages I see this, for the first boot: Oct 18 09:02:57 worm dbus[1171]: [system] Activating service name='org.freedesktop.ColorManager' (using servicehelper) Oct 18 09:02:57 worm dbus-daemon[1171]: dbus[1171]: [system] Activating service name='org.freedesktop.ColorManager' (using servicehelper) Oct 18 09:02:57 worm dbus[1171]: [system] Successfully activated service 'org.freedesktop.ColorManager' Oct 18 09:02:57 worm dbus-daemon[1171]: dbus[1171]: [system] Successfully activated service 'org.freedesktop.ColorManager' Oct 18 09:03:01 worm colord: io/hpmud/pp.c 627: unable to read device-id ret=-1 Oct 18 09:03:11 worm dbus-daemon[1171]: ** Message: No devices in use, exit Oct 18 09:03:26 worm gnome-session[1658]: WARNING: Application 'gnome-settings-daemon.desktop' failed to register before timeout So the question is: what is gnome-settings-daemon doing for 30s after 9:02:57? Version-Release number of selected component (if applicable): colord-0.1.13-1.fc16.x86_64 gnome-settings-daemon-3.2.0-3.fc16.x86_64 I believe the "unable to read device-id" message comes from libsane-hpaio via libsane. Searching for scanner devices does not take 30s though: # time scanimage -L device `v4l:/dev/video0' is a Noname USB Camera (041e:4053) virtual device real 0m3.043s user 0m0.047s sys 0m0.220s How reproducible: 100% Steps to Reproduce: 1. Power on. 2. Log in. Actual results: "Oh no!" Expected results: Login session.
On further investigation this seems to be due to an interdependency between cupsd and colord. When cupsd starts for the first time (i.e. when gnome-settings-daemon connects to the socket), it tries to register colour profiles for each queue. It does this by talking to colord over D-Bus. When colord starts for the first time, as a result of this, it looks around for devices -- and one of the ways it does that is to ask cupsd for a list of printers. Unfortunately, at this point, cupsd hasn't called systemd_checkin() and so it isn't responsive.
*** This bug has been marked as a duplicate of bug 743593 ***