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

Re: new problem - networking is strange

**************************Miles Fidelman wrote:
H.S. wrote:
Is udev giving your interface a new name (ethx instead of, say eth0)?
how would I check that, and why would it just start doing that?

You could just list the devices:
$> /sbin/ifconfig -a

and ensure you have the correctly named eth device(s). And perhaps
verify their mac addresses.

Why does it change? I am not sure, but I have had to face this kind of
problem in the past a few times, usually following a kernel upgrade or
udev upgrade or by chaning the network hardware.

well it sure seems like the interface is now coming up with the name eth3 - when I change the line in /etc/network/interfaces to read eth3, all comes up - but this is sure weird

I haven't really done anything to change things.


UDEV is behaving correctly.

Each NIC is unique and UDEV assigns a unique name to each one. Since UDEV has already assigned the name eth0 to the original NIC it will not assign it to another NIC even if the original NIC has been removed. This way UDEV will never assign the same name to more that one (1) NIC. You can change this manually by modifying the UDEV config files. Please see the UDEV manual pages for details.

As far as UDEV is concerned the original NIC, eth0, is offline and therefore does not make it available.

Since the HD had been moved from one machine to another, UDEV reacts in a way that the original hardware is offline and that new hardware has been added to the same machine. Hence the new NIC is given a different name.

Although it can be done it is not a good idea to just move the OS HD from one machine to another. Especially when dealing with servers. Doing this will cause issues like this one and may give other unpredictable results.

The best way to move from one machine to another is to install a new copy of the OS on the new machine with all the same packages that were on the old machine and then migrate the configuration from the old machine to the new one and test the new machine. Once satisfactory test results are returned migrate the data from the old machine to the new one and test again.


Reply to: