From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040202
Description of problem:
IBM Thinkpad T30
Cisco MPI350 wireless card
Intel e100 LAN
/etc/sysconfig/network-scripts/ifcfg-eth0 configured for static IP,
onboot=yes, ifcfg-eth1 dhcp, onboot=no.
/etc/modules.conf eth0 e100, eth1 airo
kudzu -p (attached) matches above configuration.
Edit ifcfg-eth0 and remove static IP info (change to DHCP). Rerun
kudzu -p (attached) and the device eth0 and eth1 swap incorrectly.
This means that if I have eth0 and eth1 defined as DHCP and reboot,
kudzu tries to remove airo and re-add airo incorrectly as eth0 (even
though modules.conf has eth1 airo).
When ifcfg-eth0 has a static IP, kudzu behaves correctly.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set up ifcfg-eth0 and ifcfg-eth1 with DHCP.
2. Set up modules.conf alias eth0 e100, alias eth1 airo.
3. Reboot and kudzu will do its magic incorrectly.
4. Put the files back in place, but set ifcfg-eth0 to static IP and
kudzu behaves properly.
Actual Results: kudzu behavior changes incorrectly when DHCP is
specified in ifcfg-eth0 file.
Expected Results: kudzu should behave the same whether ifcfg-ethX
files specify static or DHCP addresses.
I wonder if this is related to bug
Created attachment 101191 [details]
Kudzu -p output when ifcfg-eth0 and ifcfg-eth1 are both DHCP
This shows device: eth0 and device: eth1 in reverse order from that defined in
Created attachment 101192 [details]
kudzu -p output when ifcfg-eth0 is static and ifcfg-eth1 is dhcp
This shows device: eth0 and device: eth1 match the modules.conf configuration.
Created attachment 101193 [details]
Odd. It shouldn't make any difference, really.
Exactly, this is RHEL 3 U2 and it's broken. I would like to see this
fixed for U3 this fall if at all possible.
FYI, there is a Tech Support case 337302 open about this issue.
This breakage is also a problem for Laptop users at MIT.
Are you changing the ONBOOT settings at all when this fails?
Created attachment 101513 [details]
Created attachment 101514 [details]
This file stays the same for both kudzu -p runs.
Created attachment 101515 [details]
This file in combination with ifcfg-eth1 yields attachment 101192 [details].
The only thing changed is static IP -> DHCP. The DHCP ifcfg file has
an MTU entry and the static does not. The kudzu output I attached to
this bug was generated by changing BOOTPROTO=dhcp to BOOTPROTO=static
and defining the static IP. I have attached the ifcfg-eth0 and
ifcfg-eth1 files which cause this problem. If I replace ifcfg-eth0
with a static IP config, kudzu -p has correct output. Could it be the
Are you going to accept this bug and remove it from "NEW"? Also, I
just noticed my static eth0 config has the HWADDR flag tieing it to a
MAC address while the DHCP eth0 does not.
The main problem as I see it is that Anaconda populates the following
in modules.conf whether I kickstart via DHCP or static IP.
alias eth0 e100
alias eth1 airo
When I reboot after kickstart, kudzu does not complain. When I reboot
a second time and my config files are both DHCP, kudzu tries to make
eth0 "airo" even though modules.conf says otherwise. When kudzu
rewrites the ifcfg-eth file, it hoses the system. If I kickstart over
static IP and ifcfg-eth0 is static, kudzu never complains or tries to
change the configuration.
Is this possibly an issue in that Anaconda should populate HWADDR even
when eth0 is DHCP? Or is this truly a kudzu bug?
Yes, anaconda should populate the HWADDR even when it's DHCP. If not,
that's a bug.
If you add the HWADDR to the dhcp config files, does it start working?
Created attachment 101517 [details]
kudzu -p output with eth0 hwaddr defined
What should show up as eth0 shows up as eth2 in this output.
The issue only appears when ifcfg-eth0 has ONBOOT=no. I was mistaken
earlier. When ONBOOT=no on eth0 AND HWADDR is not defined, kudzu
tries to swap the "airo" device to eth0 even though modules.conf has
it defined as eth1. What is the fix for this? Shouldn't kudzu pay
attention to the config in modules.conf?
Please try kudzu-18.104.22.168-1, available at:
The updated kudzu RPM solves a similar problem we were seeing at MIT
with RHEL on the IBM R40 and the builtin aironet card. Thanks! Is
there an ETA for when we could see this updated kudzu package in
Update 4 at the latest (barring new problems being discovered with the
fix, of course.)
Can you build the x86_64 version of kudzu for
http://people.redhat.com/notting/kudzu/RHEL3? This way our kudzu will
match on i386 and x86_64 images.
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.