Back

@train now the only unpredictable part, if using Linux, is the network device name

@stefano @train They are. https://systemd.io/PREDICTABLE_INTERFACE_NAMES/

People got mad about this, though.

@breizh @train no, they aren't
Interfaces names renamed from (for example) enp2s0 to enx78e7d1ea46da just after a reboot - making the server inaccessible. It's happened on Proxmox and other distributions, without performing any update...

@stefano @train Never had this kind of thing, but I believe it can happen.

Then you can use udev rules to make the interface names static (for example based on the MAC address).

@breizh @train True. However, I still don't agree with this approach that many distributions use today: in my opinion, the kernel detects and names the interfaces. Why should systemd handle it, and why do I need to specify it in udev to prevent changes? When it was eth0, it remained eth0. In the BSDs, once detected and identified, they will never change.
I understand that on servers with 500 network cards, having the MAC addresses might be useful, but in my opinion, those are the exceptional cases, not the typical server with four network interfaces.

@stefano @train eth0/eth1 can be swaped the exact same way sda/sdb can. I’ve seen this before the predictable names (even now, enpXsY can be the alias for eth0 one time, and eth1 the next time…).

If you have only one interface, it’s always eth0 like the first SATA disk is always sda, but when you have more than one…

The real question is why we have uuid, by-id, by-path… for disks, and we still don’t have the same for network interfaces? SystemD try to mitigate the issue (and it does work better than before in most of the cases for me, but seems likes sometimes it changes anyway, from what you’re saying, so it’s still not perfect).