Update to 8.2 changes the names of the network interface

[ffeal]

Hi guys,

I have 2 Miniserver MS-01 with 4 ports, 2 ethernet and 2 fiber.

After doing the new update (no-enterprise) 8.2 it seems that the kernel change the names of the fiber interfaces, (before the name was enp2s0f0, and after the update enp2s0f0np0).

After changing the name of the interfaces on the /etc/network/interfaces file and do an ifreload -a all it seems ok.

 

[BobhWasatch]

Yes. We know. Dozens of posts about it.

 

[darkpixel]

Yeah...the horrible part about it is (on ~40% of the systems I manage) it boots to the login prompt....but if you type in 'root' and hit enter, it hangs for 30-60 seconds then quickly flashes some error message before immediately clearing the screen and returning you to the login prompt. Not sure why signing in on the console is dependent on the network interface coming up properly...*grumble*probably a systemd thing.

Have to connect via IPMI, reboot, set the kernel to boot with init=/bin/bash, mount the root filesystem rw, ifconfig -a to find the new crappy systemd interface name, edit /etc/network/interfaces to reflect the new name, sync, reboot -f.

I hate systemd.

 

[ulf.kosack]

Yes, same here. SFP-Interfaces renamed from enp16s0f0 to enp16s0f0p0 and enp16s1f1 to enp16s0f1np1. Renaming in /etc/network/interfaces works.

Vm's on the the second cluster node where not affected.

After ifup -a all connectivity was rebuild and the sync works again.

I have to read the release notes BEFORE the update :-(

 

[darkpixel]

Funny:

> Starting with v197 systemd/udev will automatically assign --->predictable<--, stable network interface names for all local Ethernet, WLAN and WWAN interfaces.

From Proxmox:
> Upgrading kernels always carries the risk of network interface names changing, which can lead to invalid network configurations after a reboot. In this case, you must either update the network configuration to reflect the name changes, or pin the network interface to its name beforehand.

Out of ~75 identical (hardware) hypervisors about 40% of them are offline right now....because SystemD is one of the most terrible things to happen to Linux.

We also upgraded 30 FreeBSD-based hypervisors. Every single one came back online with zero issues.

I find it funny that "eth0" or "eth3" wasn't predictable enough.
I mean...sure...toss a new NIC in a hypervisor and the ordering might get screwed up...but then again, in 15 years I've never had anyone randomly decided to add a NIC to ~100 Linux boxes magically in the middle of a reboot.

 

[Astraea]

After reading the issues with network interfaces changing on the upgrade to 8.2 I went through the 7 nodes I upgraded yesterday and used the instructions HERE to override the device names to eth# and each name is associated to the interface's MAC address which is a consistent value. It also helps when and if I were to add an interface into those system as they would be named something other than eth#. In all it probably took me about 3 minutes a machine to get that modified before doing the update and had no issues during or after the updates to those 7 nodes. I still have 7 more to go but that will be a next week task for me.

 

[kyesil]

Hi ;
Why auto replace interface names during upgrade. I am shoked. Connection lost our remote dedicated server. There is no warning about this. It does not make sense.

 

[Neobin]

There is no warning about this.

There is, but people do not RTFM...:

Known Issues & Breaking Changes
Kernel: Change in Network Interface Names
Upgrading kernels always carries the risk of network interface names changing, which can lead to invalid network configurations after a reboot. In this case, you must either update the network configuration to reflect the name changes, or pin the network interface to its name beforehand.
See the reference documentation on how to pin the interface names based on MAC Addresses.

https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.2

 

[kyesil]

but people do not RTFM...:

They know "people do not RTFM". They should put update time warning on ui.

I upgraded same machine 5 to 6 , 6 to 7, 7 to 8 there is no crash. 8.1 to 8.2 boom!

 

[BobhWasatch]

There's a warning for certain misconfigurations that says something like "this will wreck your system, please create <file> and try again if you really mean it". Once a month or so somebody does exactly that and wrecks their system. "How could this happen" they cry. "There should be better warnings" they say.

I'm pretty confident you would have ignored any warnings. At least the first time, and probably the second too. And if the warning was dire enough and had big red flashing banners so that you didn't ignore it there would be a thousand posts here asking about it. At some point people just need to pay a little attention to what they are doing.

 

[Kingneutron]

Filed an Enhancement request for a TUI utility to help fix this at the login console:

https://bugzilla.proxmox.com/show_bug.cgi?id=5442

 

[Kingneutron]

FYI I also posted a script to hopefully fix this at the PVE TTY login console, HTH

https://github.com/kneutron/ansitest/blob/master/proxmox/proxmox-fix-vmbr0-nic.sh

Please test, feedback is welcome (worked OK for me and at least 1 other person that reported back)

 

[kyesil]

There's a warning for certain misconfigurations that says something like "this will wreck your system, please create <file> and try again if you really mean it". Once a month or so somebody does exactly that and wrecks their system. "How could this happen" they cry. "There should be better warnings" they say.

I'm pretty confident you would have ignored any warnings. At least the first time, and probably the second too. And if the warning was dire enough and had big red flashing banners so that you didn't ignore it there would be a thousand posts here asking about it. At some point people just need to pay a little attention to what they are doing.

We are the users, and our experience is reality. If users are experiencing issue, there is an issue. This issue could have been smoothly addressed with a fix from the previous update that would isolate the interface name.

I haven't seen a strong warning this situation. "You may experience connection loss due to a interface name change after the update. Please follow these steps."....


I review all updates to see what has changed. While reviewing changes, I often thank the developers; it's almost like a ritual for me. I didn't understand from the notes that I needed to take action. Even after the issue arose, I didn't understand. I had to read in the forums what to do.

There's something wrong here.

Users may sometimes cry. But Proxmox should count the tears of its users. This is the spirit of open-source. It's easy to say it's user fault.