Bug 1013867 - does not boot directly into graphical target
does not boot directly into graphical target
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: dbus (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-30 20:57 EDT by Donald Edward Winslow
Modified: 2015-02-17 12:26 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 12:26:16 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of 'journalctl -b' (89.45 KB, text/plain)
2013-10-05 09:45 EDT, Donald Edward Winslow
no flags Details
logs from failed boots (244.98 KB, text/plain)
2013-10-05 16:28 EDT, Donald Edward Winslow
no flags Details
failed boot into single-user mode (309.71 KB, text/plain)
2013-10-05 16:35 EDT, Donald Edward Winslow
no flags Details
journalctl -b of failed boot (141.93 KB, text/x-vhdl)
2013-10-21 03:36 EDT, Ron Yorston
no flags Details
What was updated on Oct 15 (3.41 KB, text/plain)
2013-10-21 03:37 EDT, Ron Yorston
no flags Details
journalctl -b of failed boot from 21 Oct 2013 (142.16 KB, text/plain)
2013-10-21 10:31 EDT, Donald Edward Winslow
no flags Details

  None (edit)
Description Donald Edward Winslow 2013-09-30 20:57:31 EDT
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):

systemd-204-15.fc19.x86_64

How reproducible:

almost always

Steps to Reproduce:
1.power down
2.power up
3.

Actual results:

never reaches graphical login screen

Expected results:

boots to graphical login screen

Additional info:
Comment 1 Lennart Poettering 2013-10-04 11:22:52 EDT
Please provide some logs here when things fail. For example "journalctl -b" would be good.
Comment 2 Donald Edward Winslow 2013-10-05 09:45:53 EDT
Created attachment 808159 [details]
output of 'journalctl -b'
Comment 3 Donald Edward Winslow 2013-10-05 09:50:54 EDT
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?
Comment 4 Zbigniew Jędrzejewski-Szmek 2013-10-05 12:07:32 EDT
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.
Comment 5 Donald Edward Winslow 2013-10-05 16:28:24 EDT
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.
Comment 6 Donald Edward Winslow 2013-10-05 16:35:38 EDT
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.
Comment 7 Zbigniew Jędrzejewski-Szmek 2013-10-06 09:22:15 EDT
Hm, it seems that something fishy is happening with your dbus. From the first log:

Oct 05 08:12:58 zonotrichia dbus[383]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
Oct 05 08:12:58 zonotrichia dbus[383]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
Oct 05 08:12:58 zonotrichia polkitd[443]: Started polkitd version 0.112
Oct 05 08:12:58 zonotrichia dbus-daemon[383]: dbus[383]: [system] Activating via systemd: service name='org.freedesktop.PolicyKit1' unit='polkit.service'
Oct 05 08:12:58 zonotrichia dbus-daemon[383]: dbus[383]: [system] Failed to activate service 'org.freedesktop.PolicyKit1': timed out
Oct 05 08:12:58 zonotrichia accounts-daemon[386]: ** (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[386]: Failed to initialize daemon
Oct 05 08:12:58 zonotrichia polkitd[443]: Loading rules from directory /etc/polkit-1/rules.d
Oct 05 08:12:58 zonotrichia polkitd[443]: Loading rules from directory /usr/share/polkit-1/rules.d
Oct 05 08:12:59 zonotrichia polkitd[443]: Finished loading, compiling and executing 7 rules
Oct 05 08:12:59 zonotrichia polkitd[443]: 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.
Comment 8 Donald Edward Winslow 2013-10-06 10:17:53 EDT
dbus-1.6.12-1.fc19.x86_64
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.
Comment 9 Donald Edward Winslow 2013-10-10 11:19:18 EDT
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.
<url>http://forums.fedoraforum.org/showthread.php?p=1672183</url>
Comment 10 Ron Yorston 2013-10-21 03:35:21 EDT
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.
Comment 11 Ron Yorston 2013-10-21 03:36:13 EDT
Created attachment 814441 [details]
journalctl -b of failed boot
Comment 12 Ron Yorston 2013-10-21 03:37:01 EDT
Created attachment 814442 [details]
What was updated on Oct 15
Comment 13 Donald Edward Winslow 2013-10-21 10:31:13 EDT
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.
Comment 14 Ron Yorston 2013-11-06 03:46:33 EST
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.
Comment 15 Ron Yorston 2013-11-07 03:40:07 EST
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.
Comment 16 Ian Malone 2013-11-07 17:25:39 EST
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.
Comment 17 Ron Yorston 2013-12-07 16:44:30 EST
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,
Comment 18 Zbigniew Jędrzejewski-Szmek 2013-12-07 18:24:47 EST
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).
Comment 19 Ron Yorston 2013-12-08 04:42:37 EST
I had:

hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostname

Putting myhostname before mdsn4_minimal makes no difference.
Comment 20 Ron Yorston 2013-12-09 16:02:58 EST
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.
Comment 21 Ian Malone 2013-12-09 17:44:10 EST
> 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?)

@Ron:
"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.
Comment 22 Fedora End Of Life 2015-01-09 15:03:26 EST
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.
Comment 23 Fedora End Of Life 2015-02-17 12:26:16 EST
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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.