Bug 156864

Summary:	boot up does not complete because kmodule -d fails to terminate
Product:	[Fedora] Fedora	Reporter:	Alexandre Oliva <oliva>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED DUPLICATE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	katzj, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-05-05 04:27:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***