Bug 187878

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:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0F:EA:35:3E:6A
ONBOOT=yes

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
whatever reason.

*** 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
order though.

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.
 (Just speculating...)

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.

Thanks

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?

Thanks!

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. ***