Red Hat Bugzilla – Bug 178165
udev is loading network card drivers modules in the wrong order
Last modified: 2007-11-30 17:11:21 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
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):
Steps to Reproduce:
1. Set aliases in /etc/modprobe.conf
2. Run depmod -a
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.
no... you should bind the interfaces to the MAC address using
either by hand or using system-config-network...
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.
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.
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.
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,
Bringing up interface eth1: [ OK ]
Bringing up interface eth2: [ OK ]
Bringing up interface eth3: [ OK ]
Nevermind, had a typo on the HWADDR for eth0. I still think this should be redone.
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
Or another way (but horrible, kernel-related):
add new param to network modules: net device name,
and put to modprobe.conf.
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.
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.
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.
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...
you only need HWADDR in ifcfg-eth2 ..