Red Hat Bugzilla – Bug 108576
redhat-config-network and kudzu fight over wireless adaptor.
Last modified: 2014-03-16 22:40:03 EDT
Description of problem:
Using rhcn to configure a "Harris Semiconductor|Prism 2.5 Wavelan chipset":
I got a wireless card that tried to limp to life. What happens though is on the
next reboot kudzu decides this card has been removed but it hasn't. It turns out
that somehoe an entry for a ~second~ Harris adaptors gets put in
/etc/sysconfig/hwconf. The entry is ~exactly~ the same as the first (should that
even be possible?).
Run rhcn again, and sure enough you see a Prism 2.5 eth1 and an 'orinoco' eth2.
Remove the device, rerun kudzu quietly, nothing.. still there. Reboot and choose
'remove' in Kudzu and it's gone from hwconf until you run rhcn again, then the
eth2 adaptor appears again and on reboot the whole cycle starts again.
I didn't want to continuously look and reboot but to resolve the issue after a
few reboots I had to:
- Manually remove duplicate block from hwconf. Re-run kudzu.
- Manually remove ~both~ eth1 and eth2 from rhcn. Check hwconf, make sure it
wasn't changed (which I wouldn't expect rhcn would do).
- Re-run kudzu, everything still ok.
- Reboot, everything ok.
Then I configured the interface by hand and this problem didn't happen again. So
that's why I'm filing it against rhcn, I ~think~ that is what confused matters
by trying to establish an eth2 (but how would it do it without an entry in
So I'm not sure what starts it but somehow kudzu and rhcn end up with two
interfaces and kudzu wants to remove it (but never can, it comes back) and rhcn
wants to configure it (but obviously can't).
Version-Release number of selected component (if applicable):
Each time I tried.
Steps to Reproduce:
1. (read above description)
desc: "Harris Semiconductor|Prism 2.5 Wavelan chipset"
Will attach lspci -vvv too....
Created attachment 95601 [details]
lspci -vvv of the subject system..
the problem seems to be kudzu and the duplicated block....
http://people.redhat.com/notting/kudzu/kudzu-18.104.22.168-1.i386.rpm ; it
has the known bogons fixed.
Problem still exists with 1.1.36-1. See bug 108178
Created attachment 97971 [details]
hwconf post install
Created attachment 97972 [details]
ifcfg-eth0 as set by anaconda
Created attachment 97973 [details]
ifcfg-eth1 post install
Created attachment 97974 [details]
Modules.conf post install
The above 4 attachments are from the first boot after a fresh install.
I updated kudzu to
during the %post of the kickstart installation. Upon the first boot
kudzu wants to rm one of the nic's config. If I tell it "do nothing"
the interface comes up and works. With kudzu-1.1.21-1.i386.rpm the
machine would need to be rebooted twice to get the nic in a usable state.
Is one of them cardbus? (It doesn't look like it, but making sure...)
not for me.
Another note. I rebooted the machine again and told kudzu to delete
the configuration and then install the config again. It deleted eth1
and relabeled it as eth2 and would not come up. I rebooted 1 more time
and let kudzu reconfigure the nic again. This time it reconfigured the
nic as eth1 and it works. I have the modules.conf, hwconf, and
ifcfg-eth* if it is useful to you let me know and I will post it.
Not sure if the card bus comment is for me or not but no it is not
firstname.lastname@example.org: could you attach the output of 'kudzu -p' when in
Created attachment 97994 [details]
kudzu -p in rl 1 per your request
I wonder if this is related to
which I just logged.
Please try the kudzu-1.1.25-1 packages at:
Make that 22.214.171.124-1. *sigh*.
Presumably you really meant:
It appears to have fixed my problem. I even rm'd the card from the
machine rebooted it rm'd the config, and reinstalled everything. All
appears to work as it should.
Since I was not the OP I cannot change the status of this. In addition
my problem was with wired NICs not wireless so I do not know if this
is fixed for everyone.
Thanks for the fix,
Is 123571 really supposed to be secret or is this an error? Since It
is tied to this bug I am courious what it is.
It's an internal tracking bug.
Changing to another double secret internal tracking bug :-).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.