You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After a kernel version bump, it appears that enp5s0 became eth0 with no warning. This caused my network configuration to cease to function.
I fixed the problem by booting into the generation immediately before the kernel version bump, and then nixos-rebuild switch to give me the niceties of my current config. Of course, the bug will return when I reboot.
Steps to reproduce
uncertain; it may only affect some NICs; I have not yet grepped the kernel changelog to find out what, exactly, changed, or why.
The linux kernel has always followed the traditional naming scheme: eth0, eth1, wlan0, etc. What's responsible for the so called "predictable" naming scheme (like enp5s0) is systemd, so I'd say this is a bug in either systemd or the way we configure it in NixOS. If would help tracking this down if you could tell us what nixos-version in the last good and first bad generation.
By the way, if you have been setting static routes or addresses, the best way to make the configuration robust is assigning a custom name to the interfaces you need by matching the MAC address, as you suggested. This chapter of the NixOS manual shows how.
this is great; thanks for the clarification; I didn't know systemd altered interface names.
FYI the problem mysteriously disappeared a few generations later; all the same, I will follow that section in the manual to refer more precisely to my devices.
Problem
After a kernel version bump, it appears that enp5s0 became eth0 with no warning. This caused my network configuration to cease to function.
I fixed the problem by booting into the generation immediately before the kernel version bump, and then
nixos-rebuild switch
to give me the niceties of my current config. Of course, the bug will return when I reboot.Steps to reproduce
Additional context
Suggested Fix
networking.interfacesByMac."AA:BB:CC:DD:EE:FF:00" = {
ipv4.addresses = [....]
}
would also need to be able to refer by MAC address in e.g. networking.firewall.interfaces, and everywhere else (networkmanager.unmanaged, etc.)
This would be substantially more stable for config, given how mutable linux kernel ethernet interface naming scheme has become
Metadata
The text was updated successfully, but these errors were encountered: