Hide Forgot
Description of problem: After installting systemd-38-3.fc17 a machine becomes unsable. It does not boot into multiuser or graphics session. An attempt to boot to "level 3" becomes soon painfully slow and it eventually stops after printing on a screen Started Permit User Sessions and it just sits there without any further progress. Nothing is logged anywhere, with an exception of /var/log/boot.log which does not really say very much, so even a postmortem attempts to check what went wrong come to naught. It is possible to boot to level 1, misnamed "rescue", but that is of not much help as even attempts to bring network interfaces up do not succeed. After downgrading, with difficulty, all this mess to systemd-37-4.fc17 a machine boots as it used to. Version-Release number of selected component (if applicable): systemd-38-3.fc17 How reproducible: always Steps to Reproduce: 1. just try to boot
What's the SELinux mode? Try with 'enforcing=0'.
(In reply to comment #1) > What's the SELinux mode? Try with 'enforcing=0'. It is off. Forgot to mention that. On the system in question selinux is never in use. I can see one more option. Due to a bug 768778 a dracut is not updated to the current one. Maybe this has something to do with it? I will check that later. Only if this is the case then the whole concotion is getting waaaay to fragile for a sane init.
When in the rescue shell, does "systemctl --failed" list any units? Does "systemctl status systemd-journald.{socket,service}" show both units as running? What syslog implementation do you use? rsyslog?
(In reply to comment #2) > > I can see one more option. Due to a bug 768778 a dracut is not updated to the > current one. Yes, that was behind it. After hacking broken dracut-014-9.git20111215.fc17.noarch to produce a usable initrd I was able to boot using systemd-38-3.fc17. Only I immediately run into then next bug 781657 (no reboot/shutdown). > ... does "systemctl --failed" list any units? Booting that way an older kernel with initrtd produces by the previous dracut and running "systemctl --failed" gets me: systemd-journald.service loaded failed and nothing else (even with "--all"). I am really glad that this is not a remote machine or I would be totally screwed.
I see this issue on both current rawhide and also on F-16 (from perhaps systemd-37-6.fc16)
(In reply to comment #5) > I see this issue on both current rawhide and also on F-16 > (from perhaps systemd-37-6.fc16) In F-16 you may be seeing bug 786182 or a similar bug in a different service.
With Alt + SysRq + I it boots into graphic mode even if it hangs during "permit user sessions"
Hmm, so is there anything left to fix here that bug 768778 or bug 786182 can't explain?
(In reply to comment #8) > Hmm, so is there anything left to fix here that bug 768778 or bug 786182 can't > explain? AFAICT I already replied to this "No" in a comment #4 from 2012-01-13. Some other people added later comments indicating that they still have issues. What is a status with these I have no idea.
OK, people should probably report new bugs if there's something to fix here from anybody but the original reporter. Closing.