From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98) Description of problem: After installing Hampton B2 to Jaguar, and reboot. I shut down server, removed 5 dual PRO100 NIC cards, and then reboot. Kudzu starts and asks to remove all 5 dual PRO100 NIC cards (I say yes). The process continued, and tried to initialize NIC cards that have been removed. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Jaguar + onboard ROMB + onboard NIC cards + PERC3/QC + PRO1000XT + 5 dual PRO100 NIC cards. 2.Install HAmpton B2 3.Reboot 4.ifconfig to check all NIC are working OK. 5.Shutdown server, and remove 5 dual PRO100 NIC cards. 6.Reboot 7.Pay attention on boot process. 8.Check /etc/sysconfig/network-scripts directory 9.Check /etc/modules.conf file Actual Results: Kudzu doesn't modify, and clean up all the necessary files. Expected Results: It should work without any errors. Additional info:
Created attachment 48506 [details] Attached is JAguar info: dmidecode, dump_pirq, mptable, etc.
Was that modules.conf file from before or after the removal? I'd need the modules.conf from both before and after, as well as the /etc/sysconfig/hwconf from before.
After the removal. I will upload all necessary files later.
Created attachment 48524 [details] The files you need
not fixed in beta3
Fixed in kudzu-0.99.48-1; it should remove all the relevent aliases, renumber any aliases higher than the one removed, and rename the ifcfg-<foo> files of any interfaces that are renumbered.
This doesn't work as it suppose to. See attachment if ifcfg-eth8
Created attachment 52486 [details] Content of ifcfg-eth8
Also, please see the bug # 62732
*** Bug 62732 has been marked as a duplicate of this bug. ***
Deferring this, as it doesn't look like it's going to get fixed in this release.
IS THIS FIXED IN GINGIN (8.1)?
No.
Do we have a target fix date or release since it looks like we missed gingin?
No. Fixing this the rgiht way involves reimplenting the way we treat network interfaces systemwide.
Opened Feature Tracker #795 to keep this on the radar screen.
*** Bug 70279 has been marked as a duplicate of this bug. ***
Danny, have you tested this against Taroon Alpha4? Is it still a problem?
It will behave the same under Taroon A4 as it did under previous releases.
*** Bug 85372 has been marked as a duplicate of this bug. ***
Fixed in the combination of: kudzu-1.1.16-x initscripts-7.29-x Requirements for configurations for this to be handled correctly: - HWADDR=<hardware address> in ifcfg-<whatever> - kernel driver support for ethtool GDRVINFO for any drivers in use Note that now in the case where there is eth0, eth1, and eth2 and eth1 is removed, you will have eth0 and eth2, *not* eth0 and eth1.
FROM ISSUE TRACKER Event posted 09-09-2003 03:29pm by dtrinh with duration of 0.00 issue-10027.zip It still doesn't work right on Taroon B2 (kernel 421). Server tested: Merlot + 24Gb + 2 onboard NICs When I insert 1 dual e100, 3 dual e1000, 1 dual broadcom 1000, 1 e1000 NICs and reboot. Kudzu see them all, but failed to generate ifcfg-ethX and modules.conf correctly. When I removed all above NICs but 2 onboard NICs, kudzu remove all ifcfg-ethx and clean up all ethx in modules.conf. I have to edit hwconf file and rerun kudzu again for seeing 2 onboard NICs. Attached is a zip of log files. Conclusion: It's worse than when I open this issue. I increase this issue to severity 2. Status set to: Waiting on Tech File uploaded: issue-10027.zip Severity set to: High
Created attachment 94377 [details] Issue-10027.zip
CHANGEING PRODUCT AND VERSION TO REFLECT CURRENT TAROON WORK.
Note that taking a month to test means your problem may not get fixed.
Which version of kudzu was this with?
FROM ISSUE TRACKER Event posted 09-11-2003 11:49am by dtrinh with duration of 0.00 I retested this morning with kudzu-1.1.20-1. - When I insert all those NICs, kudzu seems to see all NICs correctly, but tg3, and e1000 modules are loaded (e100 module is not loaded ????). That is why modules.conf misses 2 entries for a e100 dual nic, ifcfg-ethx are not created for a e100 dual nic also. If I manually "insmod e100" and rerun kudzu then modules.conf fills up with 2 entries for e100 dual NIC, ifcfg-ethx are created also. I have tested with hugemem-423, smp-423 kernels with the same results. - Removing NICs seems to work fine this time.
That attachment is not really useful at all.
OK, so, this works for me in testing smaller amounts of cards (I don't have that kind of hardware on hand.) It *could* be something related to having more than 10 interfaces, but the code doesn't have any obvious problems with that on visual inspection.
NOTE THAT BUG 85372 WAS MARKED AS A DUP OF THIS BUG. Thsi bug is against RHEL3. BUG 85372 IS AGAINST 2.1 WITH TARGET QU3.
Bug 85372 is against RHEL 2.1; it describes the same issue though, and that issue will not be fixed for RHEL 2.1.
FROM ISSUE TRACKER Event posted 09-18-2003 05:00pm by dtrinh with duration of 0.00 Ok, I tried with 1 dual e100 NIC, and 1 dual e1000 NIC; It acts the same thing (didn't load e100 module).
So, you simultaneously add a dual e100 and dual e1000? I'm still not certain that we have such hardware.
FROM ISSUE TRACKER Event posted 09-30-2003 11:31am by dtrinh with duration of 0.00 I replaced a dual e100 NIC, and a dual e1000 NIC with 2 e100 NICs, and 2 e1000 NICs. It works fine with 2.4.21-3.EL kernel. So, the problem only occurs on dual e100 NIC card. Status set to: Waiting on Tech
Bill doesn't have a dual port NIC and can't recreate the bug with single port NICs.
Per Dell, neither MUSTFIX or SHOULDFIX for Update1. Removing 106472.
Bill has the dual port NICs. RH will try to fix but not high priority since neither MUSTFIX or SHOULDFIX for U1.
Oops! need to put this back in ASSIGNED status. Since U1 cutoff has passed, can't add to MUST FIX list at thsi time.
Please read comment #22 and comment #35. Removing.
Bill, per your note above, WONTFIX for 2.1 (Comment #35): Bug 85372 is against RHEL 2.1; it describes the same issue though, and that issue will not be fixed for RHEL 2.1. The dual bug is per RH Engineering request to open a bug for each level that experiences a problem :-( I agree our multi-release bug handling is busted... Per comment #43: Bill has the dual port NICs. RH will try to fix but not high priority since neither MUSTFIX or SHOULDFIX for U1. So........ Status on fixing for RHEL3 (this bug)?
As of yet unable to reproduce under RHEL3.
*** Bug 114517 has been marked as a duplicate of this bug. ***
FROM BUG 61169 (RHEL2.1) Additional Comment #13 From Bill Nottingham (notting) on 2004-01-28 14:13 ------- If you would like some more detailed explanation, just off the top of my head, fixing this properly requires changing (significantly, in many respects): - kudzu - the init scripts - the network configuration tools - ethtool - the kernel drivers - anaconda - *and requires rewriting all existing configurations* It's just completely out of scope for an update release. BUG CLOSED AS WONTFIX.... This bug looks like a DUP of Bug 61169. Should we close as WONTFIX for RHEL 2.1 ????
*** Bug 128276 has been marked as a duplicate of this bug. ***
Bug 128276 is not tied to Intel Dual Port 10/100 NICS. Furthermore it is a RHEL 2.1 issue, not a RHEL 3. I am not sure if we should neccessarily tie these two issues as duplicates.
Well, this started out as the RHEL 2.1 bug. RHEL 2.1 is WONTFIX for this in any case.
Please try kudzu-1.1.22.5-1, available at: http://people.redhat.com/notting/kudzu/
New kudzu seems to fix the issue on RHEL3, U3 (8/16 release)
Kudzu is now no longer working in Update4 beta1
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
Most kudzu fixes in RHEL4 kernel have been resolved, reopening on RHEL3 for code to be merged.
Please refer to comment #60. Kudzu is still buggy in RHEL 3. Can the person putting the issue in the "modified" state, please list what version of Kudzu resolves this bug and where that version of Kudzu can be found ?
kudzu-1.1.22.11-1 solves comment #62, namely: Most kudzu fixes in RHEL4 kernel have been resolved, reopening on RHEL3 for code to be merged. It's currently scheduled for U5.
Since we do not have access to the U5 Beta yet, any chance that you can post that version of Kudzu on a people page ? We promise to provide testing feedback ;-)
Kudzu is still broken in U5 Beta1 PE1800 with the following configuration: Kudzu version: kudzu-1.1.22.11-1 kudzu-devel-1.1.22.11-1 ---- hwconf : device,hwaddr,driver,pciaddr eth0,00:0F:1F:FA:36:71,e1000,3:7.0 (Onboard Intel Gigabit) eth1,00:04:23:08:7E:6F,e1000,2:5.1 (Dual port Intel Gigabit) eth2,00:04:23:08:7E:6E,e1000,2:5.0 (Dual port Intel Gigabit) eth3,00:10:18:04:5A:0E,tg3,3:9.0 (Broadcom) ----- kernel : device,hwaddr,driver,pciaddr eth0,00:0F:1F:FA:36:71,e1000,3:7.0 eth1,00:04:23:08:7E:6F,e1000,2:5.1 eth2,00:04:23:08:7E:6E,e1000,2:5.0 eth3,00:10:18:04:5A:0E,tg3,3:9.0 ---- modprobe.conf : device,driver eth0,e1000 eth1,e1000 eth2,e1000 eth3,tg3 ---- network-scripts : device,hwaddr eth0,00:0F:1F:FA:36:71 eth1,00:04:23:08:7E:6F eth2,00:04:23:08:7E:6E eth3,00:10:18:04:5A:0E If the onboard Gigabit NIC is disabled in the BIOS, after kudzu runs on the next boot the configuration is: Kudzu version: kudzu-1.1.22.11-1 kudzu-devel-1.1.22.11-1 ---- hwconf : device,hwaddr,driver,pciaddr eth0,00:04:23:08:7E:6E,e1000,2:5.0 eth1,00:04:23:08:7E:6F,e1000,2:5.1 eth3,00:10:18:04:5A:0E,tg3,3:9.0 ----- kernel : device,hwaddr,driver,pciaddr eth1,00:04:23:08:7E:6F,e1000,2:5.1 eth2,00:04:23:08:7E:6E,e1000,2:5.0 eth3,00:10:18:04:5A:0E,tg3,3:9.0 ---- modprobe.conf : device,driver eth1,e1000 eth2,e1000 eth3,tg3 ---- network-scripts : device,hwaddr eth1,00:04:23:08:7E:6F eth2,00:04:23:08:7E:6E eth3,00:10:18:04:5A:0E So eth2 has moved to eth0, but kudzu does not update the other settings properly
Created attachment 112436 [details] Network configuration - valid state (LOM enabled)
Created attachment 112437 [details] Network state - after LOM disable
Not a bug. What you say the kernel 'sees' as eth0 will be renamed to eth2 on interface bringup; as it hasn't changed, the device name will not change.
On a PE1600, with one onboard Intel gigabit interface, one Intel Pro100S card and one Intel Gigabit card, all interfaces startup fine. Here is the status before hardware change: Kernel version: 2.4.21-32.ELsmp Kudzu version: kudzu-1.1.22.11-1 ---- hwconf : device,hwaddr,driver,pciaddr eth0,00:C0:9F:40:15:C1,e1000,0:2.0 eth1,00:0E:0C:2F:0F:7A,e1000,1:6.0 eth2,00:0E:0C:51:98:9C,e100,0:6.0 ----- kernel : device,hwaddr,driver,pciaddr eth0,00:C0:9F:40:15:C1,e1000,0:2.0 eth1,00:0E:0C:2F:0F:7A,e1000,1:6.0 eth2,00:0E:0C:51:98:9C,e100,0:6.0 ---- modprobe.conf : device,driver eth0,e1000 eth1,e1000 eth2,e100 We disabled the onboard interface in the BIOS. Boot the OS. Kudzu detects the change, we remove the hardware config. During network startup both eth1 AND eth2 *FAIL* to start. Running /etc/init.d/network restart repeatedly brings up eth1, but eth2 never comes up. Here is the status AFTER hardware change: Kernel version: 2.4.21-32.ELsmp Kudzu version: kudzu-1.1.22.11-1 ---- hwconf : device,hwaddr,driver,pciaddr eth0,00:0E:0C:2F:0F:7A,e1000,1:6.0 eth2,00:0E:0C:51:98:9C,e100,0:6.0 ----- kernel : device,hwaddr,driver,pciaddr eth0,00:0E:0C:2F:0F:7A,e1000,1:6.0 eth1,00:0E:0C:51:98:9C,e100,0:6.0 ---- modprobe.conf : device,driver eth1,e1000 eth2,e100 I will attach Network state info before and after the LOM was disabled.
Created attachment 114048 [details] /var/log/messages failed to bring up eth2
What do the ifcfg files look like?
Created attachment 114152 [details] Network status before the LOM is disabled
Created attachment 114153 [details] Network status after the LOM is disabled
Network config files do not have HWADDR included; configuration is incorrect to start out with. Leaving as modified, re comment #65.
If you know what wrote the ifcfg files (i.e., if they were originally written by the installer, etc.), you may want to file a separate bug that HWADDR isn't put in the config files.
Opened Issue Tracker 72965 - RHEL3 U5: Anaconda does not set HWADDR in ifcfg-eth config files
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-2005-125.html
Opened Issue Tracker 74404 to continue discussion on this defect.
Closing, again. Please open *NEW* bugs on new issues.
To be more precise, the previous 82 comments probably have very little to do with any new problems that are seen at this point, and therefore aren't really relevant for new issues, bugzilla, etc.