The file /etc/udev/rules.d/70-persistent-net.rules is auto-generated on a Linux system with udev, if it does not exist, during reboot. But I would like to know how to create this rules file (with a command) without rebooting the server.

I was Googling around for a while and found that the rules file is generated by this script:


However, it is impossible to run this script from command line, since (I assume) it wants to be started by udev, with some environment variables set properly. Starting it manually prints error message "missing $INTERFACE". Even if I set env variable INTERFACE=eth0 prior the starting of the script, it still prints error "missing valid match". Not to mention I have two interfaces (eth0 and eth1) and I want the rules file generated for both.

I was also thinking to trigger udev events like this, hoping it will start the script from udev itself, but nothing changes:

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

So, does anybody know how to regenerate the persistent net rules in file /etc/udev/rules.d/70-persistent-net.rules without reboot?

  • What is your distribution? What kind of init system does it use?
    – michas
    Jan 16, 2016 at 13:22
  • 1
    I would say that is irrelevant. I'm using Slackware with eUdev and sysvinit. I was examining the startup scripts in order to find out what is executed which generates the rules file, but found only udevadm trigger, with a comment that this is the command to generate the persistent rules, but somehow this does work only on reboot, no effect if I run it manually.
    – Tomas M
    Jan 16, 2016 at 13:33
  • 1
    It might be relevant since I, on Arch, have neither the 70-persistent-net.rules nor the /lib/udev/write_net_rules script. Therefore, I can't check, but presumably the $INTERFACE variable is set in the script itself. Most probably it is passed as an argument. Can you show us the contents of the script?
    – terdon
    Jan 16, 2016 at 13:37
  • The script simply uses $INTERFACE variable. There are much more variables simply used, never declared. It's because it is called by udev, and udev sets all env variables before it runs the script on boot.
    – Tomas M
    Jan 16, 2016 at 14:23
  • Do you actually need to know how to regenerate it, or could you simply edit the file to reflect the new reality? Jan 16, 2016 at 14:57

3 Answers 3


According to man page --action=change is the default value for udevadm.

   -c, --action=ACTION
       Type of event to be triggered. The default value is change.

Therefore you better try --action=add instead. It should help:

/sbin/udevadm trigger --type=devices --action=add
  • intel_rapl: no valid rapl domains found in package 0
    – Tiina
    May 3, 2018 at 4:52

In Ubuntu Server 16.04LTS the 70-persistent-net.rules doesn't exist.

all I did was run:

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

Then create the file using

sudo vi /etc/systemd/network/10-internet.link

and add the following

Path=pci-0000:(your device mac address)

Name=eth0 (or whatever you want to name it)

:wq to save the file

then reboot and adjust your /etc/network/interfaces file. Then reboot again.

  • 10
    The question is "How to regenerate 70-persistent-net.rules without reboot?"  Your answer contains two reboots.  How is this an answer to the question? Oct 4, 2016 at 1:07

I had the same problem, but I noticed I could still see the interfaces in the ip addr list. I used the following (as root):

# ip addr # to get my mac addresses
# export INTERFACE=eth0; export MATCHADDR="xx:xx:xx:xx:xx:xx"; /lib/udev/write_net_rules
# replace the 00's with the real mac addr

Repeat for each interface. This was used to "recover" my file. (Note: one invocation will list all interfaces + add rename for matching one, so I recommend you peek the output file after one invocation)

There are definitely differences between OS's and current UDEV implementations and support scripts. To note, I was using CentOS 6.8 when I did this successfully.

Credit - I mostly referenced this site. There is a comment a few threads down that talk about modifying the script, but I preferred to use environment variables as it was cleaner: https://access.redhat.com/discussions/1240213

  • Crap - wait. I'm sorry, that was the command that did not work. I need to update the answer with the step I did
    – gravy21
    May 18, 2017 at 15:41
  • Ok, I've updated to how I actually fixed mine. Hope it works if it applies to your situation.
    – gravy21
    May 18, 2017 at 15:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .