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): 13.42-1.fc13
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.