Bug 178165

no... you should bind the interfaces to the MAC address using
HWADDRESS=00:50:FC:A3:23:D8
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.

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

HWADDR is working 100% either.


[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
HDADDR=00:A0:CC:23:A4:E7
BOOTPROTO=dhcp
PEERDNS=no
ONBOOT=yes
TYPE=Ethernet
[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=00:11:09:C8:F2:61
BOOTPROTO=static
IPADDR=192.168.54.1
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth2
DEVICE=eth2
HWADDR=00:48:54:8E:C1:48
BOOTPROTO=static
IPADDR=66.224.116.98
NETMASK=255.255.255.248
ONBOOT=yes
TYPE=Ethernet
[root@proton ~]$ cat /etc/sysconfig/network-scripts/ifcfg-eth3
DEVICE=eth3
HWADDR=00:13:D3:AE:BC:0A
BOOTPROTO=static
IPADDR=192.168.254.1
NETMASK=255.255.255.0
MTU=9000
ONBOOT=yes
TYPE=Ethernet


[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.
                                                           [FAILED]
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 
separate config. 
 
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 ..