[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: eth0 - eth1 confusion vs. local network



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


Reply to: