Created attachment 862610 [details] screenshot Description of problem: Version-Release number of selected component (if applicable): systemd-208-9.fc20.x86_64 How reproducible: Steps to Reproduce: 1. Boot the machine 2. Do not click anything in grub menu until timeout and it enters the default kernel 3. it stop a "f" screen as shown in the attachment. Additional info: If I click the menu in grub, fedora doesn't hang. If I edit the grub's timeout to be shorter, fedora doesn't hang. It seems to related to time.
When I disable systemd-readahead related services, the problem is gone.
If I only enable systemd-readahead-replay, I can't enter the system in any way.
I found fedora always stop at the screen when booting. I cannot login today. Any comments.
Can you paste the logs from a failed boot: journalctl --since <date> --until <date> would work, or just pipe them into a file and cut out the interesting part with an editor. You could try debugging following the instructions at http://www.freedesktop.org/wiki/Software/systemd/Debugging/#earlydebugshell. If you can get to the shell at TTY9, then you can inspect the status. The output from 'systemctl list-jobs' would be interesting.
I found that if I enable debug-shell.service and switch to terminal 9, the login screen would show up. However, if I do not switch to terminal 9, the boot just stops as previous. I've put the log file in the attachment.
Created attachment 863940 [details] logfile
Created attachment 863941 [details] Please use this logfile, which is more complete
Any comments? Or additional information do you need?
Created attachment 863966 [details] log in plain text format
It seems that you're hitting the race condition in bug 1043212. Can you test with systemd-208-13 when it in updates-testing (tomorrow)? Hopefully this update might help here too. If it *doesn't*, let's do the log gathering a bit differently: can you look at any message from a failed boot with 'journalctl -o verbose', make note of the BOOT_ID=... line, and then attach the output from 'journalctl -o short-monotonic BOOT_ID=...'. And please do it after logging in, so that unrelated stuff is not in the logs. And please do not compress logs when attaching them - it's easier to view them when they're plain/text.
I updated to the latest one from koji. The problem still persists. I attach the output of journalctl -o short-monotonic _BOOT_ID=...
Created attachment 863991 [details] journalctl -o short-monotonic BOOT_ID=...
[ 10.949881] localhost.localdomain audispd[411]: queue is full - dropping event [ 10.957670] localhost.localdomain audispd[411]: queue is full - dropping event This looks like selinux issue. I see that you have an unupdated rtkitd, and also selinux. Can you do 'yum update' to get the latest versions of everything?
I just run update yesterday. So it should be the latest version. However, my machine is affected by previous yum bug that prevents execution of pre/post execution of rpm scripts. Any way to fix this?
You mean https://fedoraproject.org/wiki/Common_F20_bugs#RPM_scriptlets_fail_during_updates?
I've reinstalled selinux and rtkit. The problem still exists.
I found that I can always enter the login screen if I switch to debug terminal (f9). If I do not switch during the boot, the screen just stop at "f" icon screen.
Any comments?
Note that when the system stops at "f" screen, I can use ctrl+alt+del to reboot.
I found a way to solve the problem. I remove plymouth and dependencies using yum. Now I can enter the system. Previously, I tried reinstall plymouth using yum. But it didn't work.
since it may be related to plymouth, I file another report https://bugzilla.redhat.com/show_bug.cgi?id=1067247
do things work if you boot with selinux=0 or with audit=0 on the kernel cmdline?
I don't know now. I just remove plymouth and it works.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.