Running UDEV rule to change interface names

Product support
1

I am attempting to rename the network interfaces on a device using udev rules. I know that this can be done by modifying the config.json but we would like for it to be done at runtime.

I have created a rule /etc/udev/rules.d/70-persistent-net.rules:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="enp6s0", NAME="enp3s0"

If I try to run the udev rules using udevadm control --reload-rules && udevadm trigger the rule errors out because the resource is being busy. In order to fix this, I can take the interface down using ip link set down enp6s0 and then running the udevadm command works and the interface is renamed.

The issue comes with that this rule is not persistent and should take affect on every reboot but does not seem to work. I am looking for any help or suggestions on how to get this to work.

1 Like
2

Hi,

The issue comes with that this rule is not persistent and should take affect on every reboot but does not seem to work

Could it be you´re suffering from the same issue described here?
The main solution there was to change ACTION=="add" to ACTION=="add|change"

3

This unfortunately did not work either.

4

Hello @jcv could you please confirm what device are you using? On the other hand, what balenaOS version are you using?

6

This discussion continued in our Paid Support queue, so I wanted to share the final outcome publicly for others’ benefit.

Setting up udev rules in the config.json remains the best solution to-date: GitHub - balena-os/meta-balena: A collection of Yocto layers used to build balenaOS images

Our thought process is best described by one of the balena engineers in his own words:

I unfortunately don’t see much of a clean way to achieve your goal using udev rules from a container. As far as I understand, what is happening is:

  1. The rule doesn’t trigger at boot time because the “add” event is triggered earlier in the startup process, before the container has a chance to run.
  2. I did a quick search and I don’t think network interfaces generate “change” events, so this wouldn’t help either.
  3. Running udevadm trigger effectively replay the events and give the rules another change to trigger, but (as you noticed) the rule will fail if the network interface is already up.

I imagine it would be technically possible to run some script on the container that would circumvent each of these obstacles, but in my opinion such solution would be quite convoluted and brittle (because we’d be essentially going against the way these things were meant to be used).

I hope the exchange is able to help others as well. :slight_smile:

1 Like