Red Hat Bugzilla – Bug 126147
kudzu broken with dhcp vs. static IP
Last modified: 2014-03-16 22:46:13 EDT
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): How reproducible: Always 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. Additional info:
I wonder if this is related to bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108576
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 modules.conf.
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] modules.conf
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] ifcfg-eth0 DHCP
Created attachment 101514 [details] ifcfg-eth1 DHCP This file stays the same for both kudzu -p runs.
Created attachment 101515 [details] ifcfg-eth0 STATIC 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 MTU setting?
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-1.1.22.5-1, available at: http://people.redhat.com/notting/kudzu/
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 up2date?
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.
Pushed.
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. http://rhn.redhat.com/errata/RHBA-2004-509.html