That's a new one.

[azonenberg@ioc.exchange]

@domi (I'm very much old school on a bunch of things, I still configure stuff in /etc/network/interfaces and add new wifi networks to my laptop by editing /etc/wpa_supplicant/wpa_supplicant.conf in nano)

[domi@donotsta.re]

@azonenberg@ioc.exchange i do mind it, because it's yet another distro changing something for no reason and fragmenting a good feature

guess it's fine if you use/administer one box, or boxen on one distro. but I touch at least three distros in prod, sometimes more for local fucking around, and it's exhausting to go round and remember about all the stupid papercuts that maintainers implemented for their own amusement. this is certainly not making it any better

[domi@donotsta.re]

@azonenberg@ioc.exchange I stopped using /etc/network/interfaces because there are at least 2 incompatible implementations in current use, and neither has really good docs for itself...

wpa_supplicant.conf is fine tho, I do that too. (albeit through wpa_gui most of the time)

[azonenberg@ioc.exchange]

@domi What i mean is, I dislike backend refactoring a lot less than I dislike breakage.

When they changed network device enumeration every release several times in a row? THAT bothered me.

Little things like changing package names between releases or moving a config file, if the migration is done properly, generally don't cost me any time.

[domi@donotsta.re]

@azonenberg@ioc.exchange oh, also: all my non-dayjob boxes run with net.ifnames=0, which returns the previous "non-predictable" device names, a move which has likely elongated my life by a good year or two

[azonenberg@ioc.exchange]

@domi I don't mind predictable names if they are actually predictable since I tend to have a LOT of nics.

But if it's enp3s0 and then I update and it's suddenly eno1, then next release it's enp6s0, and I add a new SSD and it's enp5s0 now? That's not good.

[domi@donotsta.re]

@azonenberg@ioc.exchange i would take predictable names if they'd resolve to en<MAC> by default

[toast@donotsta.re]

@domi @azonenberg I should write this udev rule :^) (actually can you? I'm not sure udev is mac-aware)

[azonenberg@ioc.exchange]

@domi That would be awesome, since it would also (unlike the current "predictable" ones) be stable if you moved the nic between slots, something I have to do sometimes

[domi@donotsta.re]

@toast @azonenberg@ioc.exchange probably not, but I bet you can do some hacks to extract a MAC anyways

[toast@donotsta.re]

@domi @azonenberg hmm, you might be able to? cursory reading of udev(7) suggests ATTR{} is a thin layer over sysfs, and in sysfs you have device/address which contains the MAC…

[toast@donotsta.re]

@domi @azonenberg@ioc.exchange hello from enx5847[censored]
I was going to go into the deep end but turns out the same script used for "predictable inames" actually exports this information too, but never uses it in the default script
looks like so to get this working:

ACTION!="add", GOTO="net_name_slot_end"
SUBSYSTEM!="net", GOTO="net_name_slot_end"
NAME!="", GOTO="net_name_slot_end"

IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="net_name_slot_end"

NAME=="", ENV{ID_NET_NAME_MAC}!="", NAME="$env{ID_NET_NAME_MAC}"

LABEL="net_name_slot_end"

save as /etc/udev/rules.d/80-net-name-slot.rules
the line starting with NAME=="" is the only important one realistically
it does look like $attr{address} should also match but then you have to add the en/wl/etc prefix yourself (which could probably be done using KERNEL==… I might poke at that after my meeting)

[emily@fedi.uni.horse]

@domi @toast @azonenberg it is! I do this in my laptop's udev config:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="84:ba:59:38:80:77", NAME="eth-onboard"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="34:99:71:00:0f:63", NAME="eth-dock"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="a0:d3:65:a8:1f:ba", NAME="wlan0"

[cmm11@fosstodon.org]

@azonenberg Fwiw it was mentioned in the release notes - https://www.debian.org/releases/trixie/release-notes/issues.en.html#etc-sysctl-conf-is-no-longer-honored

[azonenberg@ioc.exchange]

@cmm11 failing to move the existing sysctl.conf to the new location is still a bug imo