Andrei Popescu put forth on 2/8/2010 2:29 PM: > On Mon,08.Feb.10, 01:15:43, Stan Hoeppner wrote: > >>> Perhaps the kernel brings eth1 into existence by first establishing it as >>> eth0, then renaming it to eth1; then bringing the "real" eth0 into >>> existence. >> >> The above can happen when you add NICs to the system. I hate UDEV for this, >> and >> it took me the better part of a day to figure this out a few months ago. >> UDEV >> names the devices based on PCI bus slot number order. If you add a new PCI >> NIC >> into an empty slot with a lower number than that of the NIC already in the >> system, UDEV makes the lowest slot number eth0 and the higher slot number >> eth1. > > I seem to recall such issues in the (quite distant) past. > >> The solution is to change the PCI slot order or create a UDEV static naming >> rule based on MAC address that overrides the slot number ordering. > > This is already done in /etc/udev/rules.d/70-persistent-net.rules (which > is actually generated by another rule).
So, are you saying it didn't happen? Couldn't have happened? Shouldn't have happened? I'm imagining things? Are you kidding? It broke. I fixed it by manually editing the precise file you list above. Maybe it happened because I have ACPI disabled on this old (1998) 440BX MB due to its ACPI implementation being buggy. Maybe it's because I have power management disabled. Maybe it's a BIOS bug. Maybe it happened because both cards use the 8255x chip (though one was an NC3121 with 82558 and the other an actual Intel Pro 100 Server Adapter with an 82559). The cause could have been any number of things. Regardless, it happened. I fixed it manually. It did not properly auto-reconfigure. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
