Bug 156864 - boot up does not complete because kmodule -d fails to terminate
boot up does not complete because kmodule -d fails to terminate
Status: CLOSED DUPLICATE of bug 156862
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2005-05-04 15:24 EDT by Alexandre Oliva
Modified: 2014-03-16 22:53 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-05 00:27:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2005-05-04 15:24:02 EDT
After a fresh install of FC4-re0503.0, boot would stop right after printing the

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.
Comment 1 Bill Nottingham 2005-05-04 15:36:53 EDT
Does this happen on all your machines?

Do you have selinux enabled?
Comment 2 Jeremy Katz 2005-05-04 17:22:47 EDT
Seen on at least one machine here as well...  will try to reproduce on some more
Comment 3 Alexandre Oliva 2005-05-04 23:01:25 EDT
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.
Comment 4 Bill Nottingham 2005-05-04 23:38:45 EDT
Does it work with a) enforcing=0 b) selinux=0

Comment 5 Alexandre Oliva 2005-05-05 00:27:39 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.