Red Hat Bugzilla – Bug 119916
[firewire] kudzu service hangs
Last modified: 2007-11-30 17:10:39 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;
Q312461; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Description of problem:
After installing FC2T2, system hung at Detecting New Hardware. Had
to hard boot to advoic. Used prompted boot to bypass Detecting New
Hardware. Next I stopped the kudzu service and updated the config.
After upgrading to kernel 2.6.4-1.303smp tried to start kudzu service
and got hard freeze--no mouse, no keyboard. Reboot and update kudzu
to 1.1.54-1. Service still won't start, however, no longer hard
freeze, but never get a failure dialogue, start button stays greyed,
and have to kill services. Review bugzilla on kudzu and didn't find
anything like this, tho did see corrupted alias lines in
modprobe.conf issue which I had and fixed by deleting the bad line.
Version-Release number of selected component (if applicable):
1.1.54-1 and prior
Steps to Reproduce:
1.select Services from Server Settings menu
2.highlight service kudzu
Actual Results: Nothing. Start box stayed grayed. Waited 20 mins,
nothing. X out of services won't work, get Force Quit dialogue box,
select Force Quit.
Expected Results: kudzu service should start, and then Detect New
Hardware on boot should work properly.
Same system, RHEL3.0 works fine as did FC2T1.
Try removing the firewire modules?
I removed the firewire modules and then used interactive boot to
bypass new hardware detection.
I have resolved the problem, at least for now. I started kudzu from
a terminal and discovered that it was finding that my hardware had
changed and was asking me if I wanted to update. After replying
appropriately, I then went back to the gui and starting the service
by clicking the start button resulted in a message that kudzu had
run. I then added kudzu back into the startup routine and booting
was normal. The problem seems to be that if you have disabled kudzu
and then try to start it from the gui and it wants to talk to you, it
is not doing so and so it waits forever for your response which you
don't see. Starting it from a terminal allows you to see its query
and respond. I don't know if this is a bug or not.
BTW, now running kernel 305smp with firewire added back in and no
problems as far as I can see.
*** This bug has been marked as a duplicate of 119262 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.