Re: Ethernet interface numbering in etch
On Mon, Mar 26, 2007 at 11:11:04AM -0500, John Goerzen wrote:
> * dmesg output still mentions hardware using eth0, even if you can't
> talk to it at eth0 but must instead use eth5. dmesg doesn't
> mention this fact, making it difficult to track down problems.
It's nothing new, this is the case ever since interface renaming was
implemented.
> * If I replace a NIC in a box, and the box is running etch in a default
> configuration, it will no longer bring up the network on boot because
> the device name changed. If the box is using NFS, NIS, or LDAP,
> people may even have trouble logging in to it.
If you replace a NIC you surely check that it is working before you
leave the machine room, don't you?
> * If a hard disk is moved from one box to another, the network won't
> come up on boot.
And if you're using the HOMEHOST feature of md RAID, RAID arrays won't
be auto-started -- intentionally. So this is not specific for
networking.
> * If a tool like systemimager is being used to image machines,
> the imaged systems won't work because eth0 is not being brought up.
I don't know systemimager but it seems it needs a hook script that runs
after cloning a system and resets the udev configuration. File a bug.
> I'm posting here because there was a discussion in IRC about what the
> right way is, and it seems like a more general question.
>
> I think that the right thing to do is to assign the persistent names to
> network devices that still exist in the system, but to do nothing with
> any other network devices. That will allow systems to still boot and
> come up properly in the face of network hardware changes.
There is no "right way" because different usage scenarios require
different behavior. Whichever behavior you choose will be good for
some people but bad for others. Now the good news is that udev is very
flexible and _you_ can select which behavior you want by editing the
udev configuration.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Reply to: