Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156864 - boot up does not complete because kmodule -d fails to terminate
Summary: boot up does not complete because kmodule -d fails to terminate
Keywords:
Status: CLOSED DUPLICATE of bug 156862
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-04 19:24 UTC by Alexandre Oliva
Modified: 2014-03-17 02:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-05 04:27:39 UTC


Attachments (Terms of Use)

Description Alexandre Oliva 2005-05-04 19:24:02 UTC
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.

Comment 1 Bill Nottingham 2005-05-04 19:36:53 UTC
Does this happen on all your machines?

Do you have selinux enabled?

Comment 2 Jeremy Katz 2005-05-04 21:22:47 UTC
Seen on at least one machine here as well...  will try to reproduce on some more

Comment 3 Alexandre Oliva 2005-05-05 03:01:25 UTC
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-05 03:38:45 UTC
Does it work with a) enforcing=0 b) selinux=0

?

Comment 5 Alexandre Oliva 2005-05-05 04:27:39 UTC
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.