Red Hat Bugzilla – Bug 1013867
does not boot directly into graphical target
Last modified: 2015-02-17 12:26:16 EST
Description of problem:
When I turn the power on and boot with the latest kernel (kernel-3.11.1-200.fc19.x86_64), it never gets to the graphical login screen (kdm). Usually I just end up with the Fedora "f" symbol in the middle of this screen. After this last set of updates I ended up with a error message telling me tsc calibration failed.
When I boot into single-user mode and remove "rhgb" and "quiet" from the boot line, I see a lot of systemd errors (services failing to start). I can easily get to the graphical login from there by exiting the root shell or just pressing ctrl-d before I enter my root password.
I don't know that this is a systemd bug, but it started happening after the last systemd update (systemd-204-15.fc19.x86_64).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
never reaches graphical login screen
boots to graphical login screen
Please provide some logs here when things fail. For example "journalctl -b" would be good.
Created attachment 808159 [details]
output of 'journalctl -b'
I booted my computer this morning as if to hit the graphical target. After the Fedora 'f' appeared and disappeared I ended up with a blank screen. I was unable to enter commands at this point, so I rebooted into single-user mode. The above attachment (see previous comment) is the output of 'journalctl -b' after that second boot into single-user mode. I hope it is helpful, or maybe there's something else I could look at?
Unfortunately you attached output for the rescue boot (-b means "current boot"). There's nothing suspicious there. We need logs from a failed boot.
If logs are properly captured, you can just do 'journalctl --since=yesterday', after a failed boot, and attach the part that was the failed boot.
Created attachment 808244 [details]
logs from failed boots
guess I coulda read the man page...
Here is the log from the failed boot this morning. I ran 'journalctl --since=yesterday' and then grepped for 'Oct 05 08:1', so it shows the failed graphical boot and some of the logs from the successful single-mode boot that followed.
Created attachment 808245 [details]
failed boot into single-user mode
This afternoon I tried to boot into single-user mode and it failed. I got to the point where it tells me to type the root password or else ctrl-d to continue, then I typed ctrl-d, and it got to the point where the log says virbr0 entered a failed state (about 14:54 in the attachment). This is only the second time this has happened (a failed boot from single-user mode). Afterwards I rebooted and did the exact same thing (ctrl-d) and arrived at the graphical login screen.
Hm, it seems that something fishy is happening with your dbus. From the first log:
Oct 05 08:12:58 zonotrichia dbus: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
Oct 05 08:12:58 zonotrichia dbus: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
Oct 05 08:12:58 zonotrichia polkitd: Started polkitd version 0.112
Oct 05 08:12:58 zonotrichia dbus-daemon: dbus: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
Oct 05 08:12:58 zonotrichia dbus-daemon: dbus: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
Oct 05 08:12:58 zonotrichia accounts-daemon: ** (accounts-daemon:386): CRITICAL **: error getting polkit authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached
Oct 05 08:12:58 zonotrichia accounts-daemon: Failed to initialize daemon
Oct 05 08:12:58 zonotrichia polkitd: Loading rules from directory /etc/polkit-1/rules.d
Oct 05 08:12:58 zonotrichia polkitd: Loading rules from directory /usr/share/polkit-1/rules.d
Oct 05 08:12:59 zonotrichia polkitd: Finished loading, compiling and executing 7 rules
Oct 05 08:12:59 zonotrichia polkitd: Acquired the name org.freedesktop.PolicyKit1 on the system bus
So accounts-daemon doesn't start, because it times out on starting polkit. But normally the dbus timeout should be 25s (?), and here it all happens within one second.
In the second log, logind fails to acquire a name on dbus.
So, do you have any special dbus configuration? What's your dbus version? I'll reassign this to dbus, maybe they'll have some idea what's going on.
no special dbus configuration
Maybe I should take off the freedesktop connection applet in kde, neither of which I ever use. Or I might just switch to gdm.
My issue is resolved. The only thing I can think of that might have fixed it was that I installed several i686 packages, including avahi-libs-0.6.31-11.fc19.i686, in an unsuccessful attempt to get gnash to work. The only reason I think this might be connected is that avahi comes up in the errors from the journals of the failed boots.
So, I don't know that this is a bug. I did find one other user in the forums who had a similar problem that started about the same time.
I'm seeing a similar problem. A cold boot frequently results in no login screen. ctrl-alt-f2 sometimes gets a login prompt but often just shows a black screen. Rebooting the system, either from the login prompt or using ctrl-alt-del, always seems to result in a grapical login screen (gdm).
The failed boots always have the PolicyKit1 timeout in the log.
Looking at /var/log/messages I see that this started happening more frequently after a yum update on Oct 15, though there were a small number of instances prior to that. The first was on Oct 6, after I'd increased the memory in the machine. I tried reducing it again in case there was a hardware problem with inconclusive results: the first cold boot with reduced memory failed to reach the graphical login prompt but the next two succeeded.
I'll attach some details.
Created attachment 814441 [details]
journalctl -b of failed boot
Created attachment 814442 [details]
What was updated on Oct 15
Created attachment 814630 [details]
journalctl -b of failed boot from 21 Oct 2013
I'm still having issues with this. I thought it had fixed itself, but after a few clean boots it started happening again. I can work around it by working in KDE, which is configured (at least on my machine) to suspend the session on shutdown. So if I shut down from the menu in KDE and then turn the power back on, it brings me back to my KDE session without having to log in (bypasses the kdm login screen, I guess). But if I restart from the menu, it reboots and brings me (usually) to a blank screen. From the blank screen I cannot get a console with ctrl-alt-f2, but I can get a console by sshing in from another computer (which is how I generated the attached log from this morning).
If I boot in single-user mode, I can press ctlr-d at the point where it asks for the root password and it brings me to the kdm login screen.
It's getting worse. My system is fully updated as of last night. This morning I had to boot four times before I got to the login screen. When the boot fails ctrl+alt+f2 no longer gives me a login prompt.
Looking at boot logs (like the one in attachment 814441 [details]) I saw that I was getting this from sendmail:
My unqualified host name (vulcan) unknown; sleeping for retry
After a minute sendmail carries on with:
unable to qualify my own domain name (vulcan) -- using short name
I fixed my DNS so that there was an entry for vulcan and now the system appears to boot to the graphical login every time. The weird thing is that it still works even if I change the hostname to something that isn't in DNS.
Appear to be seeing this bug too, the same complaint from sendmail in the logs and failed polkit initialization.
The hostname on this machine was set using hostnamectl, I'm wondering if there's a connection and something it's not doing.
Things have got worse again. Almost every time I boot the system it fails to reach the login screen. And ctrl+alt+f2 no longer gives me a login prompt, so my only option is ctrl+alt+del. Fortunately the reboot almost always results in a login screen. But all this boot-fail-reboot nonsense is getting a bit tedious,
Ron, Ian: do you have myhostname in /etc/nsswitch.conf?
Does it help if you add a line like:
hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns
(It depedends on local settings, so just add myhostname as the second word).
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
Putting myhostname before mdsn4_minimal makes no difference.
I've been reading bugs 967521 and 1006386. It appears there's a problem with the journal which has been causing all sorts of havoc with booting.
Adding Storage=volatile to /etc/systemd/journald.conf has speeded up my boot time by 20 seconds and resulted in a graphical login every time. (OK, I've only tried twice so far, but it's encouraging.)
It seems to me that not having the journal in persistent storage is a Bad Thing, so Storage=volatile is a workaround at best. It would be nice to have the journal fixed in F19, it it is indeed the cause of this problem.
> Ron, Ian: do you have myhostname in /etc/nsswitch.conf?
> Does it help if you add a line like:
I'm afraid I'm no longer hitting this bug (well, for the purposes of debugging, otherwise I'm quite happy...). I did try making a change to /etc/hosts to fix the sendmail error, but that didn't seem to help with this and I reverted it. A number of packages got updated, which seems to have fixed it, but I was unable to narrow it down to a single one (the problem had also become intermittent by that point, which made this quite tricky). KDE-settings or one of 3 co-dependent packages *may* have been involved.
FWIW I also previously had
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
(IIRC the NOTFOUND=return rule disables subsequent modules?)
"And ctrl+alt+f2 no longer gives me a login prompt"
I experienced this too at one point, the virtual console seemed to be in some kind of sleep state, hitting return did bring up a login prompt, don't know if that will work for you.
This message is a notice that Fedora 19 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 19. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 19 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.