Created attachment 610018 [details] console output from boot process before forcibly shutting it down I have a fairly bog-standard rawhide VM that I use for testing. For the last several weeks, that VM has been unable to boot all the way up. Figuring it was that something got broken during one of the many yum updates, I reinstalled a F17 VM from scratch and then did a distro-sync to bring it up to rawhide. That also failed to boot in the same fashion. I'm not certain what component has the real problem, but I am able to boot with the original F17 kernel. So, opening this bug against dracut. What happens at boot time is that the console seems to cycle endlessly on trying to do something with systemd and then restarts part of the boot process: [ OK ] Started Dracut pre-udev hook. Starting udev Kernel Device Manager... [ OK ] Started udev Kernel Device Manager. Starting Dracut pre-trigger hook... [ OK ] Reached target Basic System. [ 114.791847] systemd-udevd[2426]: starting version 188 [ 145.347941] systemd-journald[2373]: Received SIGTERM [ 145.365040] systemd[1]: Running in initial RAM disk. Welcome to Fedora 19 (Rawhide) dracut-023-2.fc18 (Initramfs)! [ 145.404333] systemd[1]: Cannot add dependency job for unit systemd-journal-flush.service, ignoring: Unit systemd-journal-flush.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-journal-flush.service' for details. Starting Dracut cmdline hook... [ OK ] Reached target Sockets.
$ rpm -q systemd systemd-188-3.fc18.x86_64 which systemd version do you have?
[root@rawhide ~]# rpm -q systemd systemd-188-3.fc19.x86_64
Do you have the file "/etc/initrd-release" in your real root?
No: # cat /etc/initrd-release cat: /etc/initrd-release: No such file or directory
Does it help to regenerate the initramfs? # dracut -f --kver <newest kernel version>
bug 847418 https://bugzilla.redhat.com/show_bug.cgi?id=847418#c13 somebody messed up the rawhide version.
Thanks Harald. Ok, I did a downgrade to systemd-188-3.fc18 and regenerated the initramfs, and it seemed to fix the problem. Closing this as a duplicate of 847418. *** This bug has been marked as a duplicate of bug 847418 ***