[SOLVED] Webui unreachable after adding nvme drive

[badatgames]

I just went through this issue and thought I should share. This seems more like a motherboard issue than a proxmox/networking one but I'm pretty inexperienced w/ linux.

TL/DR: adding second nvme drive to server caused the network interface names to change by +1 each making the webui unreachable - fix by changing the names in /etc/network/interfaces and restarting the network service.

Bug:
I have 2 nvme drives that were purchased at different times. One already in operation w/ the system and the other to be installed. When the second nvme drive was installed the webui would be unreachable. Did not matter in which order the nvme drives were placed, it would still mess up.

Fix:
Viewed my network interfaces:
$ nano /etc/network/interfaces

took note that the two interface names were enp39s0 and enp45s0 and the vmbro0 was pointing to enp45s0
then ran these two commands to view interface status:
$ ip -br -c link show
$ ip -br -c addr show

When these were ran, it showed the interface names as enp40s0 and enp46s0.
I then went back to /etc/network/interfaces and modified the file w/ the new info; so enp39s0 and enp45s0 and the vmbro0 pointing to enp45s0 --> enp40s0 and enp46s0 and the vmbro0 pointing to enp46s0 now

I then flushed the ip info on all interfaces and then restarted the networking service:
$ ip addr flush enp40s0
$ ip addr flush enp46s0
$ ip addr flush vmbr0
$ systemctl restart networking

This let me to be able to reach the webui once again.

This happened on my asrock x570 creator, I'm assuming some funky chipset stuff is going on as I'm fairly certain the first nvme slot goes to the cpu and the second goes to chipset.

Anywho hope this helps someone out.

Edit: spelling

 

[Stoiko Ivanov]

Thanks for sharing your experience and the solution you found! This will certainly help others who also run into this issue!

The issue (sadly) happens quite often - some mainboards do change the pci-device enumeration, which then causes the described interaction with predicatble network interface names:
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Please mark the thread as 'SOLVED' for better visibility.

 

[alphaprox]

Apologies if you're not meant to resurrect older threads.
Just wanted to jump in and say thank you as this solved my issue when adding a new PCIe card into my system.
Using Asus X570-PRO Mobo with Ryzen 5950x

 

[Kashmeed]

Thanks this was very helpful and appreciated.

Mobo: GA-7PESH2

 

[leesteken]

Mobo: GA-7PESH2

It's all the motherboards, every time a PCI(e) device (with a PCI ID that comes before the network controller) is added or remove .

 

[yetisbey]

I just went through this issue and thought I should share. This seems more like a motherboard issue than a proxmox/networking one but I'm pretty inexperienced w/ linux.

TL/DR: adding second nvme drive to server caused the network interface names to change by +1 each making the webui unreachable - fix by changing the names in /etc/network/interfaces and restarting the network service.

Bug:
I have 2 nvme drives that were purchased at different times. One already in operation w/ the system and the other to be installed. When the second nvme drive was installed the webui would be unreachable. Did not matter in which order the nvme drives were placed, it would still mess up.

Fix:
Viewed my network interfaces:
$ nano /etc/network/interfaces

took note that the two interface names were enp39s0 and enp45s0 and the vmbro0 was pointing to enp45s0
then ran these two commands to view interface status:
$ ip -br -c link show
$ ip -br -c addr show

When these were ran, it showed the interface names as enp40s0 and enp46s0.
I then went back to /etc/network/interfaces and modified the file w/ the new info; so enp39s0 and enp45s0 and the vmbro0 pointing to enp45s0 --> enp40s0 and enp46s0 and the vmbro0 pointing to enp46s0 now

I then flushed the ip info on all interfaces and then restarted the networking service:
$ ip addr flush enp40s0
$ ip addr flush enp46s0
$ ip addr flush vmbr0
$ systemctl restart networking

This let me to be able to reach the webui once again.

This happened on my asrock x570 creator, I'm assuming some funky chipset stuff is going on as I'm fairly certain the first nvme slot goes to the cpu and the second goes to chipset.

Anywho hope this helps someone out.

Edit: spelling

You are a life savior. Thank you for your post!

 

[Zwa1234]

Thanks a bunch!

 

[sastromo]

Add this problem by adding a nvme drive to the server .
Now its fixed, thanks to you!

 

[r3vela710n]

@badatgames
Sir... you are a genius.
Thank you so very much, it solved my issue.

But what a bug that is. Surely one of the departments in the community should take a look at this and implement a fix.
As a temporary solution, a script that updates the interfaces accordingly works.

 

[Dunuin]

@badatgames
Sir... you are a genius.
Thank you so very much, it solved my issue.

But what a bug that is. Surely one of the departments in the community should take a look at this and implement a fix.
As a temporary solution, a script that updates the interfaces accordingly works.

Its not a bug. Thats how Linuxes "predictable interface names" works. Its all well documented and even ways to give a NIC a static name so there would be no need to fix any configs after adding/removing PCIe devices: https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES

 

[r3vela710n]

Its not a bug. Thats how Linuxes "predictable interface names" works. Its all well documented and even ways to give a NIC a static name so there would be no need to fix any configs after adding/removing PCIe devices: https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES

Thank you for the link, interesting reading.

Still, considering user experience. I hope the implementation is changed in the future. It really isn't obvious to many of us what the issue is after removing an nvme stick. It would be nice if they take a page out of Apple's or Windows playbook and make it automatic, or at least prompt the user to look into the network settings. The obscure (less than obvious) link between removing a drive and the network isn't what comes to mind initially.

In any case, now I know...

A big THANK YOU, to all of you who are active in the community, for taking the time to develop and document solutions.