Ubuntu Finally Looks To Go With Persistent Network Interface Names

[rdnetto]

It seems like the real issue is that there's no support for defining an alias for a NIC. With block devices, /dev/disk/by-uuid/1234-1234-1234-1234 is just a symlink to /dev/sda1, so you can use whichever is more convenient. (e.g. the UUID in fstab, and sda1 when you're typing commands directly into the terminal). If that feature existed, then it would simply be a matter of defining some udev rules to create appropriate aliases and then you could continue to refer to wlp0s26u1u1 as wlan1, etc.

[Ansla]

The previous way that Ubuntu was handling ifnames was the best solution currently possible. It works just fine on real hardware and regular VMs, only cloud providers had issues with it. But cloud providers use custom images anyway, so why not let them change the default in their image so it works fine for everybody? With this so called "predictable" names I get a random name for the wlan interface every time I connect it, depending on the USB port I use.

[Ardje]

The horrors of udev... I got a lot of problems with my vlan package (actually, I never did had any problems because I wasn't using udev). The udev maintainers thought it was a good idea to base name persistence on MAC address... And each new vlan device had of course the same mac-address.
And the idea to base it on mac-address. I always have the persistent net rules disabled, and have devices numbered according to the pci slot or other bus characteristics.
I even name my usb tty devices according to their usb slot or bus number or any other thing that can identify the device.
Anyway: mac address have always been a bad idea. They can be invalid, or double or random or whatever other reason. And you can see in the rules that only for some high end IBM machines the udev rules are based on physical slot and not some random mac.
It's nice that things are starting to make sense upstream after 9 years or so.

The next thing is the configuration of the interface based on layers... I've yet to see a configuration that talks about configuring a physical interface, then adds protocols to that interface like ipv4 and ipv6 or another interface layer. I know of no distribution that allows reconfiguring your ipv6 without disturbing ipv4, or that allows stoping and starting a dhcp v4 client on an interface without down and upping the interface or a dhcp client that does not down the interface when ipv4 fails.
If I create several layers of virtual devices (maybe on top of a physical device), I want none of those devices to have ipv6 autoconfiguration or ipv4 arp handling, unless I tell it to. As far as I know, only the developers of openwrt are that far that they want to fix that (ifnetd and such, it's not yet fixed, but the idea is there).

[FuturePilot]

I thought this was already the case? I installed 14.10 on a new server I built a while ago and got a p3p1 interface. Unless they're doing something different on the desktop?

[johnc]

These names can become pretty wild, if you have something like a USB wifi/ethernet adapter. I have wlp0s11f1u1 here.

What a cluster-f. As soon as I saw "Fedora" in the sub-headline I knew it would be a cluster-f solution.

[gens]

it's something dell came up with so interface names would match the physical ports
not a bad thing for servers really, i just wish they choose a better naming convention

bdw http://linux.dell.com/files/whitepap...g_in_linux.pdf

[Shiba]

it's an issue, that has been solved ~ 10 years ago, iirc. on some distros (EDIT: including ubuntu), we have (autogenerated) persistent udev rule (details, details.. yea), ifnames tied to mac address and so, in past xx years, the only way I could get an ifname change was NOT to move to another pci/e slot, but to delete that autogenerated udev rule (or modify it)

That's the same thing I was thinking. I have a /etc/udev/rules.d/70-persistent-net.rules that does its jobs wonderfully, so what "persistence" are we talking about?

[gens]

the only case where regular udev persistent name rules don't work is if something opens the device before udev renames it, so really early in the boot process

[jonnor]

I perfectly understant that lot of people would need this feature, no arguing here. it's just the naming schema thats nonsense, imo. and yep, I'll "fix" it myself immediately when it comes to my favourite distro

EDIT: as said, it fixes a nonexistent problem, sane distros fixed the problem long time ago. I see this "fix" (especialy in ubuntu/debian derivatives. cant speak of rhel, long time no use here.) as "for sake of change", nothing more, nothing less. damn. too much EDITs for today

That solution does not work for first-boot or with read-only /etc. Both important cases for both modern server (with VMs, containers) and embedded devices scenarios.

[gens]

there was a competition on reddit

http://www.reddit.com/r/linux/comments/30msiy/your_weirdest_network_interface_name_assignments/