Description of problem: the udev block devices are missing - preventing dracut from booting the system Version-Release number of selected component (if applicable): dracut-*.fc17 How reproducible: always Steps to Reproduce: 1. create initramfs using dracut 2. reboot system using new initramfs Actual results: Using dracut 017-019 the system is unable to locate the root device and will not boot. It is unable to drop to a dracut shell for troubleshooting. Using dracut-013-100.git20111021.fc17 the system is unable to locate the root device and drops to a dracut shell. Expected results: System boot as expected. Additional info: The dracut-013 shell shows no block devices were created by udev. Dmesg output shows that the kernel sees the storage devices. The block devices appear in the sysfs. Bug initially reported in https://bugzilla.redhat.com/show_bug.cgi?id=811003 and https://bugzilla.redhat.com/show_bug.cgi?id=827019.
does your kernel have CONFIG_DEVTMPFS ? quick check: $ mount |fgrep devtmpfs devtmpfs on /dev type devtmpfs (rw,nosuid,size=1959264k,nr_inodes=489816,mode=755) or try to mount it: # mount -t devtmpfs -o mode=0755,nosuid,strictatime devtmpfs /dev
(In reply to comment #1) > does your kernel have CONFIG_DEVTMPFS ? > No, it did not... Thank you Harald. That solved the problem! So it seems there was not really a bug regarding this issue, but that my kernel config was not compatible with the new dracut. I did not know about devtmpfs. It would have been helpful if there had been something posted somewhere on the need for it. Arch has something on their wiki about the need for it with custom kernels. But I did not find anything regarding the need for it in Fedora. As I noted in https://bugzilla.redhat.com/show_bug.cgi?id=811003, I initially thought it could be a kernel configuration issue. So I tried making a new initramfs from the last F17 kernel: dracut -v -H -f initramfs-3.3.7-1.fc17.x86_64-test.img 3.3.7-1.fc17.x86_64 That still resulted in the same udev issue. So then I assumed that it was not the kernel config. This time, after your post, I tried using the kernel config from 3.4.0-1.fc17.x86_64. It worked this time. So it seems my issue is resolved. Thank you for your patience, Harald.