Running KDE on Fedora 19, I have been trying to track down the cause of delays in the boot process. On examining the system log (via journalctl) I noticed a number of failures or errors during the boot. The number isn't even consistent across multiple boots: sometimes it is as few as 12, other times as much as 15.

Is this what happens with most Linux installations? I've been running Linux for some years now (mostly Red Hat and Fedora), but I don't remember as many failure messages in the system log. For what it's worth, here are all of the most recent messages: (The accounts-daemon error is the one I'm most concerned about)

Dec 02 16:12:44 tannhauser19 kernel: acpi PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM
Dec 02 16:12:45 tannhauser19 kernel: firewire_ohci 0000:01:09.0: failed to read phy reg 4
Dec 02 16:12:45 tannhauser19 kernel: firewire_ohci: probe of 0000:01:09.0 failed with error -16
Dec 02 16:12:45 tannhauser19 kernel: nouveau W[ DRM] failed to create encoder 0/1/0: -19
Dec 02 16:12:51 tannhauser19 lvm[174]: /dev/sr0: open failed: No medium found
Dec 02 16:13:42 tannhauser19 dbus[317]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
Dec 02 16:13:47 tannhauser19 NetworkManager[385]: <warn> failed to allocate link cache: (-10) Operation not supported
Dec 02 16:13:47 tannhauser19 bluetoothd[753]: Parsing /etc/bluetooth/input.conf failed: No such file or directory
Dec 02 16:13:50 tannhauser19 systemd[1]: Unit rngd.service entered failed state.
Dec 02 16:13:50 tannhauser19 accounts-daemon[307]: ** (accounts-daemon:307): CRITICAL **: error getting polkit authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached
Dec 02 16:13:50 tannhauser19 accounts-daemon[307]: Failed to initialize daemon
Dec 02 16:13:50 tannhauser19 dbus-daemon[317]: dbus[317]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
Dec 02 16:13:50 tannhauser19 bluetoothd[753]: bluetoothd[753]: Parsing /etc/bluetooth/input.conf failed: No such file or directory
Dec 02 16:13:51 tannhauser19 systemd[1]: Failed to read PID from file /run/sm-client.pid: Invalid argument
Dec 02 16:14:09 tannhauser19 NetworkManager[385]: <info> (em1): IP6 addrconf timed out or failed.

That seems like a lot of failures.
Failures with bluetoothd and dbus concerning org.freedesktop.PolicyKit1 seem to occur twice.
Also note that the first systemd mention is a service that fails.
Could this cause the second failure?
I think you could disregard the NetworkManager, because they are warn and info.
Of course, if you can tackle them it would be even better.

I think the best way to go about this is by just investigating the services one by one.
Restart the service in the current runlevel.
Otherwise, go to a lower runlevel and manually go through the proces.
You could even look in init.d what the commands are that are run.
Maybe there are some extra debugging options.

I would start with lvm, systemd and accounts-daemon.
I suspect they have most inlfuence on the system.
The kernel messages require that you dive into the hardware and the modules more.

1 members found this post helpful.

In some cases you have to "interpret" the messages. E.g. bluetooth: do you have a device present? Only if so, a problem exists (else the driver of course can't read the device) etc.

Even the "critical" label is from a timeout. That does not necessarily mean that the service couldn't be started later. Systemd is trying to parallelize processes during start. If it is not carefully orchestrated, this can run into problems like timeouts or wrong sequence of starting processes.

As hoes wrote, dig into the messages one by one after assessing their relevance.

1 members found this post helpful.

The timeouts could cause the long boot time.
Note that accounts-daemon fails, because org.freedesktop.PolicyKit1 could not be started.
So tackling this might remove two timeouts.
It seems that dbus results in the largest timeout.
It is 53 seconds after the previous commands.

1 members found this post helpful.

I am running gnome on Fedora 19 and recently had a problem similar to yours. Fortunately I had been slow getting the updates. My Dbus got the most updates. I just pulled the updates for the CIFS client & server libs/applications last night which cleared all my open issues except gnome-shell *ducks flying objects* and a strange quirk with my 5Ghz wifi not connecting at all (2.4 is suddenly unstable as well, all of which has been reported in detail and is being worked with the firmware/chip folks as well since it appears to be misidentifying my chipset).

I am not having any issues with the nouveau video driver in any way.

I'm running kernel 3.11.9-200.fc19.x86_64 #1 SMP Wed Nov 20 21:22:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux if that helps in any way.

1 members found this post helpful.

Thanks for all the replies. I'm afraid that debugging this problem is beyond me. (I had some comprehension of how things were done with init.d scripts, but the switch to systemd leaves me at a loss as to how to proceed.) The situation is complicated by the fact that I don't get the exactly the same sequence of errors on successive startups. The main problem, I'm sure, is with dbus and/or systemd, and the differences I see are due to timing differences in concurrent tasks. I guess I'll just have to wait to see if the next Fedora release has the same problem.

I'm not really sure, that this is a bug. But it is certainly annoying.

That is normal. As written above, systemd is trying to parallelize the startup processes. Due to minimal differences in the speed of loading and working on these processes you get their output at differing times. That is also the case for normal information output.

Does your system work normally after boot up? If so, that would be the sensible way to proceed.

As an aside: In many cases (distros) you'll get an error message like "over-current condition at port 3 and 4" or something in that vein. According to google it is an old message which might either be true or not but nobody of the kernel folks seems to care either way and so the message stays and nobody truly understands it...

1 members found this post helpful.

As far as I know, the system works normally after the boot up, but there's a lot of the system I rarely access. At any rate, I'm content to live with the current situation. Thanks for your reassurance about the error messages. I'm sure there are a number of situations where the developer, having ascertained that a particular error is not serious, decides that other problems are more deserving of his time.

Try running "systemd-analyze" to get some overall timings, followed by "systemd-analyze blame". Might help.
In my case a couple of releases of Fedora back it pinpointed sendmail as a major holdup. Goodbye sendmail (startup), hello faster boot.