Bug 246529 - on a system with two network cards, kudzu switches cards at boot time
on a system with two network cards, kudzu switches cards at boot time
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
7
i386 Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-02 16:33 EDT by pf
Modified: 2014-03-16 23:07 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-02 16:38:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description pf 2007-07-02 16:33:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4

Description of problem:
on a system with 2 ethernet cards, the identifiers eth0 and eth1 are assigned  (reassigned) randomly to the cards at boot time.

Entries in /etc/modprobe.conf are not used.
/etc/sysconfig/hwconf is modified with the current assignment.

The cards are NOT switched if at boot time they are not connected.
The cards are NOT switched if you fix the HWADDR in the ifcfg-eth* files.

I have reproduced this bug on a i386 (Pentium IV) server with one build-in e100 card and one 3c59x.
The same bug appears on an x86_64 (Athlon 3000+) server with one build-in 8139too and one e1000.

The fault appears 50% of the time. I have logged it with restarts each 10 minutes, and can send you the logs if you want them.


Version-Release number of selected component (if applicable):
kudzu-1.2.71.1-1

How reproducible:
Sometimes


Steps to Reproduce:
1.install fedora 7 and update to latest packages
2.connect both cards and comment HWADDR lines in all ifcfg-eth* files if they where added by the installer
3.reboot several times and check which driver is assigned to eth0 and eth1 each time. You can use "ethtool --driver eth0" or "kudzu -p -c NETWORK" or "fgrep eth -A3 /etc/sysconfig/hwconf"

Actual Results:
Sometimes the driver for eth0 was e100, sometimes it was 3c59x. Each time the cards are not assigned the right configuration, I lose conectivity.


Expected Results:
Each time I reboot, there should be the same driver assigned to eth0.


Additional info:
Comment 1 Bill Nottingham 2007-07-02 16:38:48 EDT
HWADDR= is required for stable device mapping.
Comment 2 pf 2007-07-03 11:37:30 EDT
I think that if this behavior has changed from previous versions of fedora, at
least this change should be documented.
Comment 3 Bill Nottingham 2007-07-03 12:02:06 EDT
Not sure what you mean - it's been this way since roughly FC3/FC4 (when udev
started being used to load modules.)
Comment 4 pf 2007-07-03 12:29:10 EDT
Most of my servers are FC3 (FC4 didn't work on most of them, so I stopped
upgrading). On FC3 you only had to change modprobe.conf entries like "alias eth0
e100". Changing the assignment ethx to driver there, you changed which card was
used on each eth, and this assignment remained stable (I checked, I have a udev
command on these systems).
Now, modprobe.conf continues to have entries like "alias eth0 e100", but this
statement is not used to assign drivers to the cards. You now say I have to use
HWADDR on ifcfg to make the setup stable. 
I found no reference to this procedure in the documentation. Also, if the new
procedure is to change the ifcfg to assign eth to cards, then why does
modprobe.conf continue having statements like "alias eth0 e100"? Perhaps these
statements should be modified to "alias eth e100" or any generic mapping?

Now I remember another problem that is related with this stuff: On systems with
redhat 7, if a network card failed I just swapped it with another one of the
same type, and the server was ready to go. On fedora systems, if I do this then
the setup of the card is destroyed at startup, so I had to backup the setup and
restore it after the first restart. Now I think this is related if the hardware
detection uses HWADDR and not the card type to identify network cards.
Comment 5 Bill Nottingham 2007-07-03 13:14:26 EDT
The issue is that the 'alias ...' isn't used at all; modules are loaded on
bootup, in parallel, by udev.

Since they're loaded in parallel, which interface initializes first depends on
timing within the drivers, and can change. Hence, there needs to be additional
information to have perisitent ordering - since we already used HWADDR, and all
the config tools (including anaconda) write it, it was the logical choice.
However, it doesn't necessarily get applied on upgrade (as we don't rewrite
config files there.)
Comment 6 pf 2007-07-03 13:33:23 EDT
Now I understand the process. Thanks.

Note You need to log in before you can comment on or make changes to this bug.