Description of problem:
When debugging early boot kernel problems, it is convenient to use kvm and an external kernel, with a Fedora guest set up without lvm:
qemu-kvm fedora.img -kernel /path/to/kernel -append 'root=/dev/sda1 console=ttyS0 ro' -serial stdio
this works, except that init fails to open a few /dev nodes and hangs (using init=/bin/bash works).
Turns out all that is needed for a successful boot is to set up a few device nodes:
crw-r--r-- 1 root root 5, 1 Jul 3 18:39 console
crw-r--r-- 1 root root 1, 11 Jul 3 18:23 kmsg
crw-r--r-- 1 root root 1, 1 Jul 3 18:22 mem
crw-r--r-- 1 root root 1, 3 Jul 3 18:21 null
crw-r--r-- 1 root root 1, 8 Jul 3 18:22 random
crw-r--r-- 1 root root 4, 64 Jul 3 18:21 ttyS0
crw-r--r-- 1 root root 1, 9 Jul 3 18:22 urandom
crw-r--r-- 1 root root 1, 5 Jul 3 18:21 zero
If anaconda could set up these nodes statically on /dev, everything would be ready for hacking.
Version-Release number of selected component (if applicable):
Why was this assigned to dracut? Without an initrd, dracut would never run?
First thing upstart could do, if no /dev/console is available could be to mount a devtmpfs on /dev.
qemu-kvm fedora.img -kernel /path/to/kernel -append 'root=/dev/sda1
console=ttyS0 ro devtmpfs.mount=1' -serial stdio
works for me
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Of course, we're now talking systemd.
Let me know if you did not want this re-assigned. I re-assigned it to "systemd" on Friday, per my previous comment.
Hmm, systemd relies on devtmpfs which has all these nodes anyway. I am not sure what exactly you are asking for in this bug report.
One of the first things systemd does is mount devtmpfs to /dev if that's not done yet.
Anyway, since i don't understand the bug report, and I got no replies on this I will close this now.