Bug 178165 - udev is loading network card drivers modules in the wrong order
udev is loading network card drivers modules in the wrong order
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Harald Hoyer
Depends On:
  Show dependency treegraph
Reported: 2006-01-18 01:25 EST by Nathan G. Grennan
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-18 13:14:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nathan G. Grennan 2006-01-18 01:25:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20051215 Galeon/2.0.0

Description of problem:
I expect the configurtion in modprobe.conf for network interfaces to be respected.


alias eth0 tulip
alias eth1 sky2
alias eth2 8139too
alias eth3 forcedeth

Instead I get

eth0 forcedeth
eth1 8139too
eth2 tulip
eth3 sky2

I found udev directly or indirectly is causing the modules to be loaded. If I rename /sbin/start_udev then they aren't loaded on startup. A workaround I found is to rmmod the drivers in /etc/rc.modules, then they are reloaded properly on the startup of the network service.

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

How reproducible:

Steps to Reproduce:
1. Set aliases in /etc/modprobe.conf
2. Run depmod -a
3. Reboot

Actual Results:  Network card drivers load in the wrong order and networking doesn't start correctly.

Expected Results:  Network card drivers load in the correct order and the networking starts up correctly.

Additional info:
Comment 1 Harald Hoyer 2006-01-18 04:45:24 EST
no... you should bind the interfaces to the MAC address using
either by hand or using system-config-network...
Comment 2 Nathan G. Grennan 2006-01-18 11:21:51 EST
I will give this a try, but setting mac addresses in configuration files is a
pain in the ass. I would love to see another way, especially the old way. I have
in the past generally removed them, because they tend to get in the way.
Comment 3 Nathan G. Grennan 2006-01-18 11:37:03 EST
I think you meant HWADDR=00:50:FC:A3:23:D8.

That seems to work, though it is still messy. dmesg still reports udev is
loading them in the wrong order, and then the network scripts are fixing it, my
guess is with something like nameif, and it only shows half of them have been
changed. I think it would be better if udev just didn't load the modules at all.
The network service is going to do it anyway, and it does a better and cleaner
job of it.

dmesg | grep eth

forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.49.
eth0: forcedeth.c: subsystem: 01462:7125 bound to 0000:00:0a.0
eth1: RealTek RTL8139 at 0xffffc20000020000, 00:48:54:8e:c1:48, IRQ 50
eth1:  Identified 8139 chip type 'RTL-8139B'
eth2: Lite-On 82c168 PNIC rev 32 at ffffc20000022000, 00:A0:CC:23:A4:E7, IRQ 58.
sky2 eth3: addr 00:11:09:c8:f2:61
eth0: no IPv6 routers present

At this point udev has loaded them in the wrong order.

eth0 forcedeth
eth1 8139too
eth2 tulip
eth3 sky2

sky2 eth1: enabling interface
ADDRCONF(NETDEV_UP): eth1: link is not ready
sky2 eth1: phy interrupt status 0x1c40 0xbc0c
sky2 eth1: Link is up at 1000 Mbps, full duplex, flow control both
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth2: link up, 100Mbps, full-duplex, lpa 0x45E1
eth1: no IPv6 routers present
eth2: no IPv6 routers present

Now I see sky2 became eth1 and something unknown became eth2. It doesn't mention
eth0 and eth3 also changed.

eth0 tulip
eth1 sky2
eth2 8139too
eth3 forcedeth
Comment 4 Nathan G. Grennan 2006-01-18 13:12:17 EST
HWADDR is working 100% either.

[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1
[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth2
[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth3

[root@proton ~]$ service network restart
Shutting down interface eth1:                              [  OK  ]
Shutting down interface eth2:                              [  OK  ]
Shutting down interface eth3:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  tulip device eth0 does not seem to be present,
delaying initialization.
Bringing up interface eth1:                                [  OK  ]
Bringing up interface eth2:                                [  OK  ]
Bringing up interface eth3:                                [  OK  ]
Comment 5 Nathan G. Grennan 2006-01-18 13:14:09 EST
Nevermind, had a typo on the HWADDR for eth0. I still think this should be redone.
Comment 6 Anton Guda 2006-02-08 09:49:10 EST
Proposed HWADDR method is not perfect. 
Consider remote server without keyboard and monitor with 
couple of network cards. The only access to console -- via ssh. 
Then netcard died (lighting ...).  
Reparers replace dead card with nearly the same: from one box. 
Power on: new card have different MAC: order of network card is broken: 
network is dead. The way to recover: bring server to place with  
keyboard/monitor or bring them to server (slow and painfull). 
So, must be a way to tell udev, in which order [pre]load  
network modules. Or by reading modules.conf, or by 
separate config. 
Or another way (but horrible, kernel-related): 
add new param to network modules: net device name, 
and put to modprobe.conf. 
Comment 7 Trevor Cordes 2006-10-01 18:38:15 EDT
Perhaps related to bug 72472 (see my 2006 posts).  I have a situation where udev
seems to load NIC modules in a semi-random order, ignoring modprobe.conf.  If
the 2 NIC modules are loaded out of order, the NICs become seriously demented
and no interface will come up or work properly.

I was not using HWADDR's because it is very hard to manage the way I configure
my systems (ifcfg-ethX's are generated from templates).  I fully agree with
Anton that the current "solution" is far from ideal for us folks that have to
remotely manage headless systems!

I will add HWADDR's to my templates and see if that fully solves the problem. 
If it does not I will report back.

This smacks of one of those problems that if you do it the "standard" or "old"
way (not forced to use HWADDR) that you are screwed, but if you do it the "RH
way", using redhat-network-config (or whatever such nonsense for command-
line-o-phobes), then you're ok.
Comment 8 Trevor Cordes 2006-10-01 19:22:30 EDT
Adding HWADDR fields to the ifcfg-ethX files does indeed appear to solve the
problem.  I just did so and tested it and the modules are loaded in the correct
order (ne2k then 8139too) and eth0/eth1 are assigned correctly.

I think the "bug" here is the change in human interface from using modprobe.conf
to specify ethX aliases to using HWADDR.  modprobe.conf not only is greatly
ignored (by udev) but it still seems to be used by ifup/down/etc and thus really
messes things up by creating conflicts.
Comment 9 Anton Guda 2006-10-02 04:52:56 EDT
It will be more flexible, if iface name can be selected
not only by HWADDR, but also by PCI slot, 
kernel module name (or alias), 
or as a option to kernel module.

Comment 10 Trevor Cordes 2006-10-29 19:40:44 EST
Another problem with the HWADDR approach.  Someone please help!  How is one
supposed to specify HWADDR's for tagged/VLAN/802.11q interfaces?  I have an
eth2.2 and eth2.3 that run off the same NIC.  Do I specify HWADDR in
ifcfg-eth2.2, ifcfg-eth2.3 and/or eth2??  Not to mention that with the system
running, I can't seem to find a command that will tell me eth2's HWADDR!  They
all display as 00:00...
Comment 11 Harald Hoyer 2006-10-30 10:04:55 EST
you only need HWADDR in ifcfg-eth2 .. 

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