Description of problem: When I boot the computer, the graphical screen appears and the 'f' fills in. Once it has fully filled, the computer just hangs, or alternately, it will switch to display the boot messages. I can see that various services are trying to start up, like avahi, r...kit, firewalld and login service and they all fail. After a long time of watching them all fail, a message will appear that the graphical target has been reached and then the computer just sits there, without the graphical actually ever starting; however, it is, at this point, possible to switch to another virtual terminal and work in text mode. My only option to get into graphical is to reboot the computer and do it all over again. Anywhere from one to three reboots (most frequently one reboot) and it all works fine. Both the desktop (x86_64) and the laptop (i686) are affected. Both computers have Intel graphics. Version-Release number of selected component (if applicable): systemd-204-11.fc19.x86_64 systemd-204-11.fc19.i686 How reproducible: Boot the computer. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Can you log in on the text console on tty2? If so, please provide the output of journalctl -b here. Thanks.
Created attachment 797042 [details] first trial I simply rebooted the computer; I did not turn it off and turn it back on again. Like explained in the bug report, the computer rebooted and once the plymouth 'f' flashed, it switched over to text to display the output. The last line stated that the graphical target had been reached, but nothing happened. I switched to vt2 and got this output.
Created attachment 797051 [details] Second Trial Since the computer wouldn't boot, I exited vt2 and switched back to vt1 and typed ctrl-alt-del and the computer automatically rebooted. This time, upon filling the plymouth 'f' entirely, the screen flashed to black once or twice and then kdm kicked in and commenced the passwordless login, as I have configured it to do. Once I was fully logged in and it appeared that all the background stuff had fully loaded, I again switched to vt2 and ran the requested command again. That output is provided here.
You now have the desktop x86_64 output. I also experience the problem on my i686 laptop. If you want me to run the command there, too, just say so. It really is blöd to have to try 2-4 times to get the computer up and running :-(
There seems to be something wrong with PolicyKit not responding... Sep 12 15:58:32 desk accounts-daemon[338]: ** (accounts-daemon:338): CRITICAL **: error getting polkit authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: Timeout was reached Sep 12 15:58:32 desk accounts-daemon[338]: Failed to initialize daemon
Sounds suspiciously like bug 983688.
I just upgraded to systemd-204-13.fc19.x86_64. I them turned off the computer and performed a 'cold' boot. The system hung, so I executed the ctrl-alt-del sequence and rebooted. The system hung, so I executed the ctrl-alt-del sequence to initiate another reboot. The system hung, but this time switched from the 'f' screen to the text screen, showing that I had reached the graphical target, so I executed the ctrl-alt-del sequence to initiate yet another reboot. Everything went normally. This is how it always seems to go: one or more 'f' screens, followed by one text screen, followed by a successful boot. I notice that speech-dispatcherd.service never starts. I have it configured to start at boot. This is the only change to the daemons I have made. Could this have some bearing on the problem?
Earlier this evening, I booted the laptop and it took me 7 tries to get to the graphical.target. That is the record so far. This is horrible! The computers are nearly unusable. With the desktop, I can suspend, but the laptop battery is gone, so I am reliant on electricity. Also, once I finally got logged in to KDE, the network was not working. I don't know whether this has any relationship to this bug, but I was unable to establish a wireless connection, but I was able to establish a wired connection in order to do the updates. I sure hope that last systemd update at least reduced the problem from 7 boots down to 2-3.
After today's updates (another systemd and kernel), the situation has gotten so bad that: the laptop (i686) is unbootable. I have tried for a couple of hours all afternoon and it is impossible to boot to the graphical target. Going into non-graphical is no help, since the network does not work and I am unable to get the network to start (systemctl start NetworkManager.service says that it is running, but there is no dns, so I am unable to downgrade or anything). I will have to reinstall F18, since F19 is unusable. the desktop (x86_64) is barely bootable. I downgraded systemd\* to the versions from updates (I had been using updates-testing). That didn't help. After about 9 reboots, I finally got the computer started, so I downgraded the entire system to updates and will no longer use updates-testing, even though I have successfully used it for many years. Even with a downgraded system, including the kernel, it has still takes a 'cold' start plus 4 reboots to get the computer running. If it continues like this, I will be forced to revert back to Fedora18.
By the way, I don't have nscd installed, but I do have dnsmasq installed. It is not running, says dead.
OK, forget the need to downgrade to f18 ;-) I just remembered that old trusty command, startx. I have successfully downgraded both computers, so I am no longer using any updates-testing packages and have a fully straight system. I have also disabled speech-dispatcherd from starting at boot, so I have no daemons configured that weren't set by default. Still, the multiple reboots are required on both computers and, on the laptop, I am pretty well down to startx in order to be able to use it at all :-(( I am in about the 8th reboot on the laptop right now, so I haven't tried the wireless, but wired does work when I use the startx method. NetworkManager won't let me start the network from the command line, because it is managed. Catch 22, every which way.
Please post a convenient workaround so that I will be able to use my computers normally until this problem is resolved.
A minor improvement that affects both computers. I switched from kdm to gdm on both computers (systemctl enable --force gdm.service). In both cases, I was able to get to the graphical target not on the boot, but on the reboot. I have done this once on each computer. I had the impression that the hard drives on both computers were working for quite a long time before gdm finally appeared; however, I was able to log in (perform a login) on both computers to each of gnome and kde. Only on the laptop, wireless continues to be mostly unusable. Both NetworkManager.service and wpa_supplicant.service are working, but there is a strange message on wpa_supplicant that says that due to some condition, the wireless has been disabled, and I am not able to enable it. This occurs both in kde and in gnome. However, in both kde and gnome, I am able to use unsecured wireless connections (no wpa/wep). The last time I was able to use my wpa-secured wireless was 7 days ago, so some software update between then and the last few days has blocked it.
(In reply to Peter Gückel from comment #12) > Please post a convenient workaround so that I will be able to use my > computers normally until this problem is resolved. If this is indeed related to bug 983688 (as Lennart suggested), a workaround would be to remove the /var/log/journald directory.
(In reply to Michal Schmidt from comment #14) > > If this is indeed related to bug 983688 (as Lennart suggested), a workaround > would be to remove the /var/log/journald directory. Thanks for breaking the silence and posting some constructive assistance :-) Deleting the journal directory would be very radical, but if the switch to gdm doesn't prove to be helpful (I need to try a few power-down cycles), then I might need to resort to it, at least on the laptop, as it had become unusable. Lightdm is another possibility, one that intrigues me, as Fedora should use a unified *dm by default, instead of all of this unnecessary duplication that adds unproductive complexity :-) Early on in the other thread, if this is indeed related, someone suggested removing rhgb and quiet from the kernel boot line. This is tedious, but less radical, so it is also worth a try. I wonder if the slow response of kmail in the last couple of days (it takes about 30 seconds to display/delete a message) is also related to this problem. If there are other ideas, I would welcome reading them, as I would like to be able to use the computers normally. I am, after all, not using rawhide or the updates-testing repos. I am still committed to Fedora. This is just a little bump to temporarily manoeuvre around as the road to an even greater Fedora becomes repaved.
Progress Report: Laptop: The wpa-secured wireless firewall problem is not related. Although the stored password and the router's password were identical, something must have gotten messed up in the update to kde-4.11 last week. I changed the password and secured wireless now works. I suspect that the kmail problem is likely due to virtuoso. There is another complaint on the kde-redhat mailing list, but Rex has not yet commented. The early suggestion in the other thread about removing 'rhgb quiet' from the grub boot line is useless. The timeouts for services and startup failures occurred undeterred. I was forced to follow your suggestion and have moved /var/log/journal to /var/log/journal.bak. Status: The laptop works as it should. Desktop: I have been subsisting on suspend/resume cycles, so I have not rebooted the computer since my last status report. I am very optimistic about the switch from the old, unmaintained kdm to gdm. The journal is still active, but I have no idea whether all daemons that should have gotten started really are running. Notwithstanding, all seems fine. Assessment: Having diagnosed the various maladies of these computers and having treated those I could, the symptom profile is now consistent with bug 983688. I hope that a vaccine can be created soon :-) as the beginning of an outbreak appears imminent, judging by the appearance of a new thread on the fedora users mailing list.
Thanks for the confirmation. *** This bug has been marked as a duplicate of bug 983688 ***