Red Hat Bugzilla – Bug 187878
NICs changing between boots
Last modified: 2007-11-30 17:11:29 EST
Description of problem:
I have a Dell OptiPlex GX260 with an additional NIC. When I boot FC5 eth0 and
eth1 are chosen randomnly, i.e., eth0 may be eth1 after the next boot.
Version-Release number of selected component (if applicable):
FC5 both kernels released so far.
Steps to Reproduce:
1. Install FC5 to Dell OptiPlex GX260 with an additional RTL8139 NIC
3. Notice how eth are assigned randomly
eth are assigned randomly to NICs.
NICs always have the same identifier.
I'll attach dmesg output after boots when NICs were identified differently. My
/etc/modprobe.conf looks like this:
alias eth0 e1000
alias eth1 8139too
And ifcfg-eth0 is like:
And ifcfg-eth1 is like:
Created attachment 127281 [details]
dmesg after 1st boot
Created attachment 127282 [details]
dmesg after 2nd boot
Use the additional HWADDR parameter in your ifcfg-ethX files to assign ethX to a
NIC via its MAC address. Ex:
On clean installs, this is done by default to avoid issues like this, which are
typically more common on laptops w/pcmcia cards, but do happen on desktop
systems as well. HAL/udev just don't always find things in the same order, for
*** Bug 187938 has been marked as a duplicate of this bug. ***
I can't reopen this bug, but I can report that having HWADDR in ifcfg-ethX does
not guarantee that the NICs will be selected in the proper order.
In fact, I have the following in /etc/modprobe.conf on my Thinkpad T41:
alias eth0 e1000
alias eth1 ipw2200
install ipw2200 /sbin/modprobe -q eth0; /sbin/modprobe --ignore-install ipw2200
That *should* force the e1000 to load first no matter what, but even with this,
I've had them load in reverse.
I *never* had this problem with FC4 kernels. The detection order changed from
2.4 kernels to 2.6, but within 2.6, they always loaded consistently (wireless
first, FWIW) unless forced as above, until FC5.
This *is* a bug, and an extremely annoying one in a laptop as DHCP lease files
are tied to interfaces, so if you swap interfaces, you screw up DHCP completely.
Please reconsider the disposition.
Hrm, some refactoring of what was where took place in FC5, but the HWADDR
parameter *should* still be honored. Rumor now has it this may have been fixed
in the updates-testing initscripts package. Please give that version a shot and
see if it doesn't fix the problem. If not, I'll reopen this bug. If it does,
looks like we should push that package to updates.
Did you mean module-init-tools? I've installed those from updates-testing (but
like a good scientist, I'm only going to change one variable at a time...).
Took out the force line in modprobe.conf.
I;ve rebooted twice and it's worked so far, but give me a day or two to try a
few more times before we start jumping for joy.
Nope, I meant the initscripts package, as its what contains the /sbin/ifup and
ifup-eth scripts that are supposed to look at the HWADDR parameter. Could be
something in the updated module-init-tools that helps with stabilizing the load
Ah, OK. But on the laptop, I don't actually start any interfaces at boot. I
use NetworkManager, which only starts interfaces when I log in. I'm not even
sure if it uses ifup when in scanning mode. (It does use ifcfg-ethX to
determine if there is a fixed IP address, though.)
I seem to recall in certain circumstances that if the HWADDRs were wrong, I'd
get an error. That doesn't suggest that HWADDR will force module loading order.
I have both good news and bad news.
Good news: using HWADDR and the updated initscripts RPM my NICs are now getting
their names consistently so far on my Dell desktop.
Bad news (for me, at least): Linux 2.x has ALWAYS found NICs in the exactly same
order without any HWADDR configuration until FC5. For me this changed behavior
is clearly a regression. For instance, I cannot anymore use in-house made
automation scripts that rely being HWADDR independent. My machines do not use
NetworkManager and NIC are identified before HAL starts so this seems like a
udev or a kernel bug. Please consider reassigning the bug to the udev component
if this not kernel's fault. Thanks.
I will confirm that with the new initscripts, the device names are being
assigned consistently. At least, they have been through a half-dozen or so
boots on my part and a handful on the part of a colleague down the hall.
The initscripts changelog lists a "udev helper to rename netowrk devices on
device creation," which sounds like it's the relevant change.
(In reply to comment #10)
> I have both good news and bad news.
> Good news: using HWADDR and the updated initscripts RPM my NICs are now
> getting their names consistently so far on my Dell desktop.
Good to hear.
> Bad news (for me, at least): Linux 2.x has ALWAYS found NICs in the exactly
> same order without any HWADDR configuration until FC5. For me this changed
> behavior is clearly a regression.
There are quite a few systems out there that do not have their NICs found in the
same order, even on much older kernels. Why yours never changed before and does
now, I can't say, but its pretty typical behavior -- consider a system where you
hotplug a interface (eg., a pcmcia card or usb to ethernet adapter), a system
where you move a NIC from one PCI slot to another for some reason, or a system
with a BIOS that allows you to alter the bus scanning order. The HWADDR
parameter is there and configured by default because these scenarios are so common.
> For instance, I cannot anymore use in-house made
> automation scripts that rely being HWADDR independent. My machines do not use
> NetworkManager and NIC are identified before HAL starts so this seems like a
> udev or a kernel bug. Please consider reassigning the bug to the udev
> component if this not kernel's fault. Thanks.
I'll leave this at Dave's discretion. So far as I can see, everything is
operating as generally expected. For some reason, devices in your particular
machine are getting picked up in a different order than before, but relying on
order in which things are discovered to assign a device number and IP address to
them is hazardous at best, in the majority of cases.
(In reply to comment #11)
> I will confirm that with the new initscripts, the device names are being
> assigned consistently. At least, they have been through a half-dozen or so
> boots on my part and a handful on the part of a colleague down the hall.
> The initscripts changelog lists a "udev helper to rename netowrk devices on
> device creation," which sounds like it's the relevant change.
Two positive endorsements there, along with my own from running that initscripts
package on a handful of systems for two weeks now. I'll ping folks here to get
that package bumped from updates-testing to a full-blown released update.
Is there something holding back the release of the updates-testing initscripts?
It's been two weeks since Comment #13 and over a month since the update appeared.
In all that time, I have not seen a problem with NIC reordering while using it.
So what's the status with this? All information needed should be available to
roll out a package containing needed fixes. Thanks.
OK it's been three *months* since the new initscripts appeared in
updates-testing. Is there any reason at all not to push it out to updates?
Apparently the move to kernel-2.6.17 has caused NIC reordering up the wazoo. It
would solve so many people's issues if they had this installed.
For love of all that's Linux, can we please roll it out now?
Ack, this got lost in the shuffle when I moved across the country and I somehow
missed putting myself on the CC list. I've added myself and am currently bugging
people about getting that update moved over to updates-released.
Okay, there were some reasonably big changes to the initscripts in updates-testing:
initscripts-8.31.2 adds a udev helper for renaming devices,
so that devices are renamed to their configured name on
module load, as opposed to when they are brought up.
Since this is adding new code to the boot path, it could use
a good deal of testing; it will be pushed final once I'm
comfortable that there are no regressions.
That's part of the reason for the delay. I'm changing the component for this bug
over to initscripts, we should have some traction on getting this moved shortly.
*** Bug 198037 has been marked as a duplicate of this bug. ***