After a fresh install of FC4-re0503.0, boot would stop right after printing the message: Initializing hardware... It appears that the kmodule -d command never completes, or at least the while read ... keeps waiting for some even that never happens even though kmodule -d has already printed all output expected from it. Oddly, running `kmodule -d > /dev/null 2>&1' before the eval command works around the problem, and enables the boot up to complete. I suspect there's something wrong with the kernel, because if I run kmodule -d within strace -f, I get an Oops after the a child process is clone()d. Going back to kernel-2.6.11-1.1282_FC4 didn't avoid the need for the additional kmodule -d, and I don't have earlier kernels handy. I suspect we might have to go with the work-around proposed above for FC4test3.
Does this happen on all your machines? Do you have selinux enabled?
Seen on at least one machine here as well... will try to reproduce on some more
I'm tracking rawhide on only two boxes in this cycle, and re0503.0 was only installed on one of them. The other is my main workhorse, so I didn't want to risk it before finding workarounds for all the issues I ran into. SELinux is enabled, yes.
Does it work with a) enforcing=0 b) selinux=0 ?
It works with enforcing=0, and I can sort of see why: as soon as I introduce the the work-around for the udev bug 156862, it no longer hangs. So this turns out to be a dupe. *** This bug has been marked as a duplicate of 156862 ***