Red Hat Bugzilla – Full Text Bug Listing
|Summary:||udev is loading network card drivers modules in the wrong order|
|Product:||[Fedora] Fedora||Reporter:||Nathan G. Grennan <redhat-bugzilla>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-01-18 13:14:09 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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. Example: 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): udev-078-4.x86_64 How reproducible: Always 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 HWADDRESS=00:50:FC:A3:23:D8 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 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=22.214.171.124 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 ]
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 ..