Update to 8.2 changes the names of the network interface

F

ffeal

New Member
Nov 8, 2023
1
1
3
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.
 

Attachments

  • Screenshot 2024-04-24 at 17-10-18 pve - Proxmox Virtual Environment.png
    Screenshot 2024-04-24 at 17-10-18 pve - Proxmox Virtual Environment.png
    88.3 KB · Views: 202
  • Screenshot 2024-04-24 at 17-10-50 pve - Proxmox Virtual Environment.png
    Screenshot 2024-04-24 at 17-10-50 pve - Proxmox Virtual Environment.png
    64.1 KB · Views: 180
  • Like
Reactions: vesalius
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.
 
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 :-(
 
Last edited:
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. ;)
 
  • Like
Reactions: Cha0s, IsThisThingOn, Kingneutron and 2 others
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.
 
  • Like
Reactions: KarolTheGuy, blackpaw and kesawi
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.
 
kyesil said:
There is no warning about this.
Click to expand...

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.
Click to expand...
https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.2
 
  • Like
Reactions: vertigomike and dMopp
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.
 
  • Like
Reactions: Neobin, KarolTheGuy, darkpixel and 1 other person
BobhWasatch said:
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.
Click to expand...

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.
 
  • Like
Reactions: anda42, cmolb, blackpaw and 1 other person
Hello to all,
Unfortunately after pining NICs to their names regarding its mac addresses system runs not as stable as expected ...
If systems are rebooted i.e. every half hour or every hour host respects /etc/systemd/network/nic1.link .. nic4.link files , but If I do this test next morning we can be pretty sure that prox-host will NOT respect this files and the only way to solve this is login through IPMI and reboot it manually which "solves" this problem.
I'm using Supermicro X9DRE-TF motherboard with 2 onboard 10g nics and one external 2port 10g sfp nics
The weirdest thing would be that when it does not respect *.link files 1st onboard ethernet gets eno1 name and the other one gets eth0 name (?)

What I'm doing wrong and how I make it more stable ?

Thank you very much in advance

BR
Tonči
 
Last edited:
tonci said:
Hello to all,
Unfortunately after pining NICs to their names regarding its mac addresses system runs not as stable as expected ...
If systems are rebooted i.e. every half hour or every hour host respects /etc/systemd/network/nic1.link .. nic4.link files , but If I do this test next morning we can be pretty sure that prox-host will NOT respect this files and the only way to solve this is login through IPMI and reboot it manually which "solves" this problem.
I'm using Supermicro X9DRE-TF motherboard with 2 onboard 10g nics and one external 2port 10g sfp nics
The weirdest thing would be that when it does not respect *.link files 1st onboard ethernet gets eno1 name and the other one gets eth0 name (?)

What I'm doing wrong and how I make it more stable ?

Thank you very much in advance

BR
Tonči
Click to expand...

If those are the exact file-names, you might be missing the priority-number in front, which might be the issue here.
So not nic1.link but 10-nic1.link
Note, haven't fully tested it, but all tutorials and instructions I found use it (and for me on a supermicro system too it works without hickups like that)

Also, as it says in the documentation [1] it is recommended to make sure that the names chosen can't conflict in the future, so NOT using eno or eth among other names.
What I have done is is use the naming scheme endXpY, where X is the device-number and Y the port-number, so for the on-board (device 0) I would have end0p0 and end0p1, the first external device would have end1p0 and end1p1

[1] https://pve.proxmox.com/wiki/Network_Configuration
 
Last edited:
sw-omit said:
If those are the exact file-names, you might be missing the priority-number in front, which might be the issue here.
So not nic1.link but 10-nic1.link
Note, haven't fully tested it, but all tutorials and instructions I found use it (and for me on a supermicro system too it works without hickups like that)

Also, as it says in the documentation [1] it is recommended to make sure that the names chosen can't conflict in the future, so NOT using eno or eth among other names.
What I have done is is use the naming scheme endXpY, where X is the device-number and Y the port-number, so for the on-board (device 0) I would have end0p0 and end0p1, the first external device would have end1p0 and end1p1

[1] https://pve.proxmox.com/wiki/Network_Configuration
Click to expand...
Hello, .. thank you very much ... "eno" must not be used but "en"X must be used ... I changed it and it seems to be working good so far
BR
 
I have a similar problem. The NIC died and a replacement was added. On reboot, the system timesout on the network and forces reboot. I use grub to boot to single mode which works and modified /etc/network/interfaces to update the NIC name and the vmbr0. However, on reboot, it still stalls and reboots.

Is there any other place I need to change the network config?
 
maxprox said:
Not as far as I know. There is no other place, it wouldn't make sense anyway
Have you checked the names of the NICs?
Were the files
Code: 
ls -alh /etc/systemd/network/
created correctly?
(I'm only talking about the script in my post above)
Click to expand...
I made a mistake and didn't change the NIC name in all parts of the file (missed one).
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back