Red Hat Bugzilla – Bug 138916
Initializing Hardware locks up after starting udev
Last modified: 2015-01-04 17:11:55 EST
Description of problem:
On a Toshiba Tecra 8100 laptop, booting stops and locks up the
machine. The last messages on the the screen are:
Starting udev: [ OK ]
Initializing hardware... storage network audio
Version-Release number of selected component (if applicable):
I have upgraded to udev-039-10 by booting into gnoppix and chrooting
Using kernel 2.6.9-1.667 with standard kernel boot parameters.
Using Toshiba ACPI BIOS version 2.50
Every time, the machine wont boot beyond the error message stated.
Steps to Reproduce:
1. allow machine to boot
2. wait for udev to be started
3. wait for "Initializing hardware..."
4. watch progression of "storage", "network", "audio" appear
5. machine locks up (no caps lock)
6. can not press CTRL^C or any other command
7. requires a power down
Machine can not boot.
Machine to be able to progress through the boot proceedure
This machine was happily running Fedora Core 2.
Have also tried booting with selinux=0
Initializing hardware.. is done by rc.sysinit, which is component
initscripts, and it just loads kernel modules... reassigning to kernel.
The problem was to do with loading one of the (sorry forget which one)
'OTHER' modules returned by /sbin/kmodule, and used in rc.sysinit.
I added 'pci=noapic' to the kernel cmdline, and all seems to boot well
The process also hangs in the 'storage' phase if my (only) USB device
is unplugged. If the device is plugged in at that point, the process
picks up and completes normally. 2.6.9-1.667smp
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.