Network interfaces keep changing names, how do I fix this?


Recommended Posts

Before I say anything else, a little background information.  About 10 hours ago I embarked on what should have been a very simple journey of upgrading my cache drives.  I won't get into details, but I've ran into problems left and right and I finally am booting the server back up and now I'm having network issues.  Please understand that I have been trying my best to get this working, I've been on google looking up everything I can.  I do not just jump right into the forums and ask my questions without attempting to figure things out on my own.  That being said, is the documentation out there to answer my question?  Probably, but I have not been able to find it and it is not for lack of trying.

 

I ran a direct 10 Gbit connection to my unRAID box not too long ago to take advantage of my cache drives, but I also needed this connection to work in tandem with my network for streaming and other networking services (I didn't want unRAID to rely on my main system being up to have internet and network access).  Because of this, I had to unbridge all my network interfaces and this caused some frustrating issues, but I got around them and ended up manually configuring both interfaces in the go script.  This worked well...that is until I realized the names of the interfaces can and will change.  So now eth0, eth1, and eth2 are not the same anymore and the go script no longer works.  I can simply change the name of the interface in the go script, but I would very much like to fix this so that it never happens again.

 

What I really would like to do is either configure interfaces based on their MAC address instead of their interface name, or find a way to make sure the interface names do not change in between reboots and in between anything else that might happen.  I found information on the interwebz that spoke of the file: /etc/udev/rules.d/70-persistent-net.rules and I edited that with vi, however, the comments at the top of the file and one of my google search results (that took me to a post in this forum) gave me little confidence that it would stick.  It seems that this file is generated on each boot with unRAID and so editing it is pointless...unless of course I did something wrong.

 

Either way, I can't imagine this solution should be anything difficult, but I just cannot find the answer I'm looking for anywhere online.  Can someone please point me in the right direction?

 

Thank you very much!

Link to comment

The /etc branch of the filesystem exists only in RAM.  So you have to copy any modifications you make to system files every time you boot. Your flash device (mounted under /boot) is an obvious place to copy them from.

 

If I were to place a file on the flash drive, and use the go script to copy that file, would it be too late in the boot cycle?  I would need to have a custom 70-persistent-net.rules copied but whether or not this works would depend on when the go script is ran.

 

Thanks!

Link to comment

The /etc branch of the filesystem exists only in RAM.  So you have to copy any modifications you make to system files every time you boot. Your flash device (mounted under /boot) is an obvious place to copy them from.

 

If I were to place a file on the flash drive, and use the go script to copy that file, would it be too late in the boot cycle?  I would need to have a custom 70-persistent-net.rules copied but whether or not this works would depend on when the go script is ran.

 

Thanks!

 

I just tried this and it does not work....sigh.

Link to comment

I'm on the verge of crying here.  This is what hopelessness feels like.  When you search all over Google and all you find are articles talking about editing the 70-persistent-net.rules file, but that will not work because unRAID generates this on each boot it seems, or articles saying to use ip link set eth1 name eth0 to rename interfaces without rebooting, but being met with an, "RTNETLINK answers: File exists" message...then Googling that to find more confusion and mess.

 

All I want is consistency with network interfaces and I just don't understand why this is apparently is not possible?  Please, if someone can help...I don't even know where to look anymore to try and solve this.

Link to comment

There is works in progress for support of multiple interfaces. You need to have some patience though.

 

I am glad to hear that at least.  However, unRAID had the correct interface named eth0 not only a few days ago.  Something has caused the interfaces to be renamed and I can't figure out what.  While there is not support for multiple interfaces, there should be a relatively simple work around considering that it's all linux and with some creativity, lots of stuff can be accomplished with it :)

 

The thing about my issue is that I know what the problem is, and how it needs to be fixed.  I need to configure or otherwise manipulate whatever it is that names the interfaces when unRAID boots up so that they will always have the same name across reboots and power downs.  Figuring out how to do this, however, has been far more difficult than I would have imagined.

 

So while I do appreciate the heads up that this will no longer be an issue at some point officially, would you happen to know how I could tell it to rename these interfaces on boot up using a command set or a script or some other method?

 

Thanks!

Link to comment

YEAH!!!!!!!!!!!!!!!!!!!!!!  Figured it out and I am freaking ecstatic!!  :D :D

 

so how does one rename the interfaces with unRAID when everything outside the /boot directory is apparently wiped clean in between boots?  It took me several days, lots of hours but I pieced together how to make this work and I'm putting it here so that hopefully anyone else that has this issue will find the solution in a nice tidy little package and save them hours of frustration.

 

  • The first thing you'll need to do is create a copy of the "/etc/udev/rules.d/70-persistent-net.rules" file in a place that will stick around everytime unRAID reboots.  I created a directory under /boot called CustomConfigFiles.  Open this copy and configure it so that the network interface that you wish to use for unraid is named eth0 and any others named eth1, eth2, etc. etc.  The most important one is eth0 as unRAID uses that interface and will not use any other (as best as I can tell anyway)  You'll need to figure out which MAC address is the one for the interface you wish to use as your primary network interface.  There's several ways to get the MAC address, but the method I used was the command, "ethtool -p eth0" to get the interface's lights on the back of the server to flash.  My methodology for this was as follows: use ifconfig to see a list of eth* devices and their addresses.  use "ethtool -p eth0" to see which one flashes.  When I find which card is flashing on the back of the server, I use Control + c to stop the command and take note of it's MAC address.  I did this for each interface to find the MAC address of the two different interfaces I needed to use, and then using vi (if you're not familiar with vi, I know I wasn't, google how to use vi in linux and you'll find plenty of documentation) I opened and configured my newly copied, "/boot/CustomConfigFiles/70-persistent-net.rules" file so that the correct interface had the name eth0.  Check out http://eriberto.pro.br/blog/?p=1145 for more information on this (the information on this page is also used in a later step below)
     
  • Next I edited the go config file at "/boot/config/go" to copy the correctly configured "70-persistent-net.rules" file to overwrite the generated file at "/etc/udev/rules.d/70-persistent-net.rules" using the following command: yes | cp -rf /boot/customconfigfiles/70-persistent-net.rules /etc/udev/rules.d/
    That will copy and overwrite, without prompt, the generated config file that is not correct.
     
  • The next line pauses the go script to make sure it had time to finish copying the file.  I used 10 seconds, but that's probably a bit excessive.  Use this command to pause the go script for 10 seconds: sleep 10s
     
  • Next two lines will remove and reload the kernel modules for the network interfaces.  See http://eriberto.pro.br/blog/?p=1145 for instructions on this that are clearer than what I could type out.  My next two lines looked as follows, but yours will be different:
     
    modprobe -r ixgbe e1000e
    modprobe -a ixgbe e1000e
     
  • and then finally I configured my network interfaces.  I'm not using DHCP here, because I couldn't figure out how, but I have the IP reserved in my DHCP server so there should be no issue.  After you reload the kernel modules for the interfaces you need renamed (no idea of that terminology is correct, I'm just going on what that webpage said), you'll need to bring the now correctly named interfaces up.  My config files look as follows.
     
    ifconfig eth0 up
    ifconfig eth0 192.168.1.25 netmask 255.255.255.0
    route add default gw 192.168.1.1
    echo nameserver 8.8.8.8 > /etc/resolv.conf
    echo nameserver 8.8.4.4 >> /etc/resolv.conf
    ifconfig eth1 up
    ifconfig eth1 192.168.5.2 netmask 255.255.255.0
     

 

Obviously, plug in your own numbers there.  eth1 is my 10 Gbit network card, but if you're just trying to rename a single interface so that it stays eth0 across boots, you won't have anything past specifying the name servers to mess with.

 

 

Now I play the waiting game where I see if any other issues arise from this solution, and cross my fingers that they don't :)

Link to comment

Well done, you have a working solution. :)

 

To make life - for the time being - a bit easier, I have created the script network-rules which can be used to automate things.

 

First extract the script from the attached zip file and copy it to your flash drive in the folder /config.

 

Next include the execution of the script in your go file, place the following lines before the start of emhttp:

[color=blue]# Port (re-)assignment
/boot/config/network-rules[/color]
[color=gray]# start webGUI
/usr/local/sbin/emhttp &
[/color]

After a system reboot the file network-rules.cfg is created on your flash drive in the folder /config. This file holds the current interface assignments and can be edited with any editor (e.g. notepad).

An example of its content may look like below, the number of entries depend on the number of ethernet interfaces present in your system:

# PCI device 0x8086:0x153b (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="bc:5f:f4:f7:92:c0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", [color=red]NAME="eth1"[/color]

# PCI device 0x8086:0x1539 (igb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="bc:5f:f4:f7:92:bb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", [color=red]NAME="eth0"[/color]

If you want to reverse the assignment of the interfaces then edit the file network-rules.cfg and change the NAME= part to the desired interface name. After saving the file reboot your system using the GUI.

 

Don't forget that it might be necessary to move cables when interfaces have changed (unRAID always uses eth0 for its communication).

 

network-rules.zip

Link to comment

For wider usability, can you specify the range of unRAID versions that can take advantage of this?  For example, can v5 or earlier versions use it?

 

The script relies on udev, which is part of the eudev package. As far as I can remember this package is installed in all 6.x versions of unRAID. I am not sure about unRAID 5.x versions.

 

Personally I have been testing this on unRAID version 6.2.0-beta, but it should be save to use on 6.1 as well.

 

Remember this is only a temporary measure, plans exist for native support in 6.2.

Link to comment

Well done, you have a working solution. :)

 

To make life - for the time being - a bit easier, I have created the script network-rules which can be used to automate things.

 

First extract the script from the attached zip file and copy it to your flash drive in the folder /config.

 

Next include the execution of the script in your go file, place the following lines before the start of emhttp:

[color=blue]# Port (re-)assignment
/boot/config/network-rules[/color]
[color=gray]# start webGUI
/usr/local/sbin/emhttp &
[/color]

After a system reboot the file network-rules.cfg is created on your flash drive in the folder /config. This file holds the current interface assignments and can be edited with any editor (e.g. notepad).

An example of its content may look like below, the number of entries depend on the number of ethernet interfaces present in your system:

# PCI device 0x8086:0x153b (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="bc:5f:f4:f7:92:c0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", [color=red]NAME="eth1"[/color]

# PCI device 0x8086:0x1539 (igb)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="bc:5f:f4:f7:92:bb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", [color=red]NAME="eth0"[/color]

If you want to reverse the assignment of the interfaces then edit the file network-rules.cfg and change the NAME= part to the desired interface name. After saving the file reboot your system using the GUI.

 

Don't forget that it might be necessary to move cables when interfaces have changed (unRAID always uses eth0 for its communication).

 

Thank you!  :)

 

Your script looks awesome :D    That'll be a lot easier and better than doing it manually!  I just have a question real quick.  You mentioned the execution of your script happening before the start of the webgui, but I put all my lines after that.  Should I move all my lines of commands before the webgui loads?  It seems to be working, but I'm not experienced enough to know what kind of issues it could cause.

 

Thanks!  And thanks again for making that script! :D

Link to comment

I just have a question real quick.  You mentioned the execution of your script happening before the start of the webgui, but I put all my lines after that.  Should I move all my lines of commands before the webgui loads?

 

Strictly speaking the position of the script in the go file isn't critical. It is just good practise to have the network ready before the service (emhttp) is started.

 

When using the script, there is no need to include individual commands. I am a little puzzled why you want to do that.

 

Link to comment

I just have a question real quick.  You mentioned the execution of your script happening before the start of the webgui, but I put all my lines after that.  Should I move all my lines of commands before the webgui loads?

 

Strictly speaking the position of the script in the go file isn't critical. It is just good practise to have the network ready before the service (emhttp) is started.

 

I got ya, that makes sense.  I'll move my lines before that.  Speaking of which...

 

When using the script, there is no need to include individual commands. I am a little puzzled why you want to do that.

 

I don't understand what you mean...don't those commands have to be executed in that order?  I don't see any other way for it to work (I mean, the correct file has to be copied, then the interfaces need to be unloaded and reloaded for the new names to be applied).  Do you mean to say that I should instead have those commands in their own file, and call on that?  Or something else?  I'm not very experienced with scripts :|

Link to comment
  • 3 weeks later...
  • 2 weeks later...
  • 2 years later...

Argh - I've just spent ages going through the options landing here, implemented it, wondering why the rules file was there already (thought maybe I put it there) then reading the last message is it's now native.  Could someone should put this last comment about it now being native in the first post?

  • Upvote 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.