Rainer Weikusat <rweikusat@???> wrote:

>> If you just use the default kernel naming scheme then you open
>> yourself to the problem that udev was designed to solve - that of
>> random device names.
>
> If you'll neither believe me nor the code wrt causes these 'random
> device names', may I try some kind of authority?
>

>     7.4.3.7. Device naming order changes randomly after rebooting

>

>     This is due to the fact that Udev, by design, handles uevents
>     and loads modules in parallel, and thus in an unpredictable
>     order.

And ?
Udev, at least on the Debian systems I'm used to, creates rules such that the interfaces will only be randomly named the first time they are encountered. After that, the naming is recorded so that each interface will have a completely stable name thereafter.

OK, I may be misunderstanding some of the internals, in particular "what" is responsible for the random module loading order - but I certainly recall it being a problem before udev came along. And after udev, I have somewhere where I can fix the names of things.

BTW - this is also an issue for video capture devices (TV tuners etc) as well as NICs. Comes up from time to time on the MythTV mailing list.


Rainer Weikusat <rweikusat@???> wrote:

>>    Udev solved the problem of the stability of device names: once one
>> interface has been named eth0, the same interface will remain eth0 - 
>> without interference from the admin.

>
> Unless the admin transfers the installation to another system. Assuming
> that everything used to work fine with eth0 - eth3, all hell will
> break lose because the sole four interfaces are now called eth4 - eth7.

But the point is, the admin can then, with one simple edit, return those to being eth0-3. That's just one step in transferring a system - along with partitioning disks, formatting filesystems, changing fstab if it's using ugly UUIDs, installing the bootloader, ...
Not only that, but you can decide which interface you want to have which name.

> The idea is already conceptually rotten as MAC addresses are usually
> programmable and may even be randomly generated.

True, MAC addresses are rubbish as an identifier - but they are there and for the sort of systems I'm used to, reasonably stable. Virtualisation changes that of course, but I set fixed MAC addresses for my guests for other reasons anyway. YMMV
IMO, using MAC address is the worst option, apart from all the others.

Now, if you as the admin decide to change your mAC address, then you can (at the same time) change the rule mapping interfaces. If anyone else is changing MAC addresses in your NICs then you have something of a problem ;-)

As an aside, when developing IPv6, the IETF group working on it agreed that MAC addresses are terrible - and excluded them from the packets. They've since been forced to add a new option to carry the MAC address simply because so many people have workflows reliant on them - and DUIDs (DHCP Unique ID) simply don't work in the real world, they are less stable than MAC addresses in many situations. Until hardware manufacturers assign DUIDs at manufacture time, and provide somewhere to store it, and all OSs use that storage, and ... then that won't change. I switch OSs, change HD, re-install OSs, boot off CD/DVD/USB stick/etc far far far more often than I ever change NICs.

>> But it does not solve the problem which Rainer adresses: to match the
>> device name with the visual labelling, ie the need for a predictable
>> matching between interface name and what is written on the box, so
>> that instructions to the user make sense.
>
> That's something I specifically don't care about. Any mapping is good
> provided it's possible to write software such that it doesn't have to
> care about the hardware it's going to run on and that it's stable.
>
> There's no way to predict external wiring from the bus geometry, only
> the hardware manufacturer knows about that.

Indeed. But when creating a system, at some point you will have to configure "stuff" such that it uses the port on the back that you want it to use. You can accept what the system gives you, and go and find every reference to it in your config and alter that - or you can do as I prefer and do that mapping exactly once and in exactly one place, giving each interface a name you decide on (even if that is eth0, eth1, ...).
And unless the new hardware is identical, something's going to change anyway - different chipset(s), different internal bus locations, different physical locations on back panel, physical labelling, ...