Manually trigger creation of /etc/udev/rules.d/70-persistent-net.rules file

Latest response


We are looking to trigger the recreation of the /etc/udev/rules.d/70-persistent-net.rules file under RHEL 6.5 (current patches)

We tried the Red Hat Solution ID# 495013, but it did not work


•You can manually force udev to create the rules file by running the following command:

This command is recommended to trigger the rules file:

# udevadm trigger --subsystem-match=net

Does anyone else know how to trigger the recreation of that file? Sadly the command did not invoke the file... The article mentions nothing of a need to reboot the system, yet this and some of other related rhel 6.5 servers have been rebooted numerous times recently.

Typically, I've seen that file created by default, and is typically automagically created if it is deleted and rebooted. Yet in the case of these servers, it has not been created, even with numerous reboots. We have some servers (rhel 6.5) that apparently have never had that file created.



You'd need to tell us what udev-related RPMs you have installed on your systems. In on of my customer-environments, they use a hardened build that strips out a lot of the dynamic-reconfig functionalities (making implementing udev rules on-the-fly a royal pain).

Hi Tom,

Here is the result of rpm -qa | grep udev:

[root@servername ~]# rpm -qa | grep udev

Appreciate any help, sorry for the delay, hair on fire.

Hey Cecil,

Here's the rpms we have on a rhel 6.5 server that actually does create the 70-persistent-net.rules file (looks like the same rpms):


One of my rhel 6.5 workstations had just one more package to the above list:

Here you go .

udevadm trigger --type=devices --action=change


udevadm control --reload-rules

Let us know how it went.



Thank you Arrey, but when we tried both of the above commands with no success. (The file /etc/udev/rules.d/70-persistent-net.rules was not created).

Let me guess, you removed the file /etc/udev/rules.d/70-persistent-net.rules and you want the udev to recreate it? Not gonna work. You can remove the file and reboot so udev makes a new one. If you want to make changes in the file and have the changes take effect with rebooting? Then use the above commands I provided.


Cecil, can you reboot your system?

Arrey, I looked into an existing /etc/udev/rules.d/70-persistent-net.rules file I had and noticed apparently the file can be invoked without a reboot, I've been trying different things, but have not had it make it properly yet.

# This file was automatically generated by the /lib/udev/write_net_rules 
# program, run by the persistent-net-generator-rules rules file

I got one to write (adjusting a copy of the file) without a reboot, but it did not have the expected MAC address.

Then you can add the MAC address in the file manually.

At least in the copy of the script I created and executed... measure twice cut once :)

Although, if one knew the definitive PCI slot and used that, if the NIC was changed later, it wouldn't care about the MAC address. I suppose the PCI slot is the value "MATCHID" based on line 17 of the unaltered script

One work-around I found...
I made a copy of the /lib/udev/write_net_rules file and added this, ran it and it worked without a reboot.

# line 25, line 26 is next
INTERFACE=eth0 # provided this is your interface
MATCHADDR="d4:AE:52:AB:AC:AD" # add your real mac address, not this fake one of course

However, there has to be some method to make this run as anticipated --without-- altering the file.

Hello Arrey, testing on my VM of a RHEL6 Workstation.

I moved the file to a backup location and rebooted, it was replaced. I deleted it and tried the commands as per your post Tuesday at 4:05 PM but it was not recreated.

Stephen, just an FYI, Cecil is the original posting person for this...

Ah, I see you found that with the later posts...

We did not remove the file. We dicovered the problem on a working server when we were trying to bond 2 NICs and I went to reference the file to make sure we had the proper port on the network switch (to match the MAC address) and the file wasn't there. The system was rebooted several times that day. We overcame the issue at the time and have the server up and running, but after that situation, I went to our other servers and none of them have a /etc/udev/rules.d/70-persistent-net.rules file. That is when I started researching and found the article that didn't recreate the file and when I posted in the initial question.

Update, the /etc/udev/rules.d/70-persistent-net.rules file I created added the wrong interface; I had to adjust the /etc/udev/rules.d/70-persistent-net.rules file to match the interface.

I have read with other Linux distros, that this is supposed to read and create a 70-persisten-net.rules file with the following with does not work on RHEL.

/lib/udev/write_net_rules  all_interfaces

Within the /etc/udev/rules.d/70-persistent-net.rules file, it says that the 70-persisten-net.rules file is (somehow) created by the /lib/udev/write_net_rules program, run by the /lib/udev/rules.d/75-persistent-net-generator-rules rules file.

Hello, that works for me:
[root@rhel6 ~]# rm /etc/udev/rules.d/70-persistent-net.rules
rm: remove regular file `/etc/udev/rules.d/70-persistent-net.rules'? y
[root@rhel6 ~]# ls -la /etc/udev/rules.d/70-persistent-net.rules
ls: cannot access /etc/udev/rules.d/70-persistent-net.rules: No such file or directory
[root@rhel6 ~]# /lib/udev/write_net_rules all_interfaces
[root@rhel6 ~]# ls -la /etc/udev/rules.d/70-persistent-net.rules
-rw-r--r--. 1 root root 368 Nov 3 14:07 /etc/udev/rules.d/70-persistent-net.rules
[root@rhel6 ~]#

Seems it worked on a Workstation VM with one interface, but not on a server VM with three interfaces. But in the latter case, # udevadm trigger --subsystem-match=net did work.

Hello Cecil

If you try:

~]# export INTERFACE=eth0
export MATCHADDR="ip addr show $INTERFACE | grep ether | awk '{print $2}'"

~]# /lib/udev/write_net_rules

~]# less /etc/udev/rules.d/70-persistent-net.rules

Do you see anything in that file?

Hi Stephen, I found that exporting "INTERFACE_NAME" to the current active interface worked.

export INTERFACE_NAME=eth0
echo "this is useful if you happen to know in advance that eth0 above is the active functioning NIC with no other NICs"
  • This seems to work fine for a single interface system,
  • But sadly, (just as you pointed out) if I had a multiple amount of interfaces (such as bonded network interfaces, or just extra NICs leading to another subnet; then it did not work).
  • It would not include other NICS that exist that are not currently in use that could be configured later if the need arose.