The officially official Devuan Forum!

GNUser

Member

Registered: 2017-03-16

Posts: 570  

/etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

Today I noticed that two of my Devuan ASCII machines are missing /etc/udev/rules.d/70-persistent-net.rules altogether, while a third machine has the file but it is blank. All machines are working fine including internet access (and network interface names are the easy-to-remember old-fashioned ones). eudev is running on all the machines:

bruno@inspiron:~$ sudo service eudev status
[ ok ] udevd is running.

This situation made me realize some gaps in my knowledge:
1. What is the function of this file normally?
2. Why is the file absent/empty? It used to be generated automatically, but not anymore. Is something broken on these machines?

Last edited by GNUser (2018-08-29 18:12:10)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

This situation made me realize some gaps in my knowledge:
1. What is the function of this file normally?
2. Why is the file absent/empty? It used to be generated automatically, but not anymore. Is something broken on these machines?

70-persistent-net.rules was used to make sure that each network interface kept the same name after reboot. Apparently, it still works if you create the file yourself. In ascii, you usually don't need it - eudev reverts to the old names.

The new method names them according to where they are plugged in on the motherboard. Some people believe that being able to predict the interface name is more important than being able to remember it. Longer, more complex names go along with the longer, more complex commands that have been created in recent years.
https://www.freedesktop.org/wiki/Softwa … faceNames/

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

Thank you, fsmithred. Question #1 is completely answered. (I have a deep dislike for the new interface names, by the way. Yuck!)

The question remains as to why this file used to be automatically generated on these machines, but not anymore. I did not change any eudev settings. Did using refractasnapshot on the "parent" of the two affected machines have something to do with it? (I can imagine that unless the refracta scripts intervened somehow, transferring a typical autogenerated /etc/udev/rules.d/70-persistent-net.rules from parent to child computer would mess up the interface names--e.g., child computer's wireless card would be named wlan1 instead of the expected wlan0).

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,251  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

It's generated by udevd via /lib/udev/rules.d/75-persistent-net-generator.rules when net.ifnames!=1.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

It's generated by udevd via /lib/udev/rules.d/75-persistent-net-generator.rules when net.ifnames!=1.

Huh. Other than when net.ifnames=1, when else would it not be generated? I have two ascii installs on the same computer; one has 70-persistent-net.rules and the other does not. Interfaces get the old names on both.

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

I'm glad I'm not the only one scratching head over this. I don't care about 70-persistent-net.rules per se--after all, everything works and all machines have the old interface names. But I do want to figure out why the file mysteriously stopped being autogenerated.

Ralph: /lib/udev/rules.d/75-persistent-net-generator.rules exists on all my machines, full of nice-looking code. Neither now nor in the past did any of these machines set the net.ifnames kernel boot parameter.

Last edited by GNUser (2018-08-28 12:53:20)

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

fsmithred: On your ASCII partition that has the file, would you please backup the file, delete it from /etc/udev/rules.d/, reboot, then check if the file is regenerated? I'm guessing it won't be autogenerated (i.e., the file was there because it was autogenerated at some point in the past).

Last edited by GNUser (2018-08-28 13:17:57)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

I moved 70-persistent-net.rules and rebooted. It was not regenerated.

I don't know where that file came from. This system started out in June as a debootstrap install, then added openbox (without dbus). The one that doesn't have that file started out in April as a netinstall with standard system utilities only, then added parts of xfce. Neither were upgrades from jessie, so it can't be a leftover.

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

Thank you very much for that, fsmithred. The 70-persistent-net.rules on my refractasnapshot "parent" partition was definitely not a leftover, either, since that partition was a fresh install.

This is a complete mystery to me at this point.

Last edited by GNUser (2018-08-28 14:10:03)

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,251  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

The generation need not be a mystery. It's indeed that "rules" file 75-persistent-net-generator.rules that comes into play whenever some hotplug event occurs, plus the once off initial scanning of /sys. I suppose you need to learn a bit udev-ish to work it out in detail, but essentially:

IF the hotplug event is due to the (possibly faked) addition of a net device adapter, and the NAME attribute has not been set for it, and the environment does not contain an net.ifnames variable with value 1, and the initial kernel name pattern is one of some few (including eth* and wlan*), and some few more specialized conditions,
THEN make up a name for the device adapter, and run /lib/udev/write_net_rules to generate /etc/udev/rules.d/70-persistent-net.rules.

Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules. It's all at a deplorable level and style of programming, but I'm sure someone is proud of it.

One thing is that the  logic ignores other possibilities of setting NAME before 75-persistent-net-generator.rules. I have a vague memory of various random "solutions" to adapter naming that end up setting NAME early, and thus also disarm the generation of 70-persistent-net.rules, but without them being grounded in their logic. The result is more untouchable udev rules mess, which is good for nothing but clocking consulting time.

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules.

This seems sensible, but the fact is that my 70-persistent-net.rules is absent, so it cannot be responsible for setting NAME for the adapter or for disarming 75-persistent-net-generator.rules. Something is disarming the generator.rules, the question is what that something is.

Last edited by GNUser (2018-08-29 11:11:30)

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

IF the hotplug event is due to the (possibly faked) addition of a net device adapter, and the NAME attribute has not been set for it, and the environment does not contain an net.ifnames variable with value 1, and the initial kernel name pattern is one of some few (including eth* and wlan*), and some few more specialized conditions,
THEN make up a name for the device adapter, and run /lib/udev/write_net_rules to generate /etc/udev/rules.d/70-persistent-net.rules.

FWIW - on the system that had the 70-persistent-net.rules file that I removed, I added a usb wireless interface.

Addition of new device adapter -      check
NAME attribute not set -                  check
No net.ifnames variable -                 check
Kernel name wlan1 -                        check
Specialized conditions -                   ?????

When I plug in the usb wireless dongle, I get a message saying that wlx<hwaddr> was renamed from wlan1.
No 70-persistent-net.rules gets generated. Same if I boot with the dongle plugged in.

So who is renaming wlan1? What are those specialized conditions that were mentioned?

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,251  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

Yes, there is 73-usb-net-by-mac.rules which deals with USB net devices, unless there's a net.ifnames=0 assignment on the boot line. Then there is also 80-net-name-slot.rules being active unless net.ifnames=0, applying some last resort naming that is made available by the (unconditional) net_id invocation of 75-net-description.rules.

Those "specialized conditions" I mentioned are various reasons to avoid renaming, and they don't make renaming happen.

Note that net.ifnames=0, net.ifnames=1 and net.ifnames unassigned provide three different ways of hotplug handling of network device adapter naming, with a nice handful of rules files involved. Then there are also at least 2 other rules files involved in the enabling (or configuration) of network interfaces, and those of course depend on the name assignments, especially if there's a renaming involved.

Don't ask me why

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

I discovered something: After every boot, /run/udev/tmp-rules--70-persistent-net.rules exists (populated with naming rules for eth0 and wlan0 based on their MAC addresses), even though /etc/udev/rules.d/70-persistent-net.rules never gets created. So the naming rules are generated anew on each boot, but exist only in RAM.

Maybe the timing of things at boot is such that eudev is trying to commit the naming rules to filesystem before the filesystem can be written to?

Last edited by GNUser (2018-08-29 14:17:54)

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

I think the issue is that when eudev runs, the filesystem is not yet writable and therefore /lib/udev/write_net_rules writes to temporary files in /run/udev/ (see the choose_rules_file and writeable functions in /lib/udev/rule_generator.functions).

It is the job of /lib/udev/udev-finish to copy temporary rules in /run/udev/ (which don't survive reboot because they exist in RAM) to the root filesystem once filesystem is writable, but nothing seems to ever run this script (I inserted a line in udev-finish that creates a dummy file, but the dummy file never shows up under any circumstances).

So I think I found a bug: Nothing ever triggers /lib/udev/udev-finish, therefore temporary rules in RAM never get transferred to the filesystem, therefore /run/udev/tmp-rules--70-persistent-net.rules gets generated anew at every boot but /etc/udev/rules.d/70-persistent-net.rules never sees the light of day.

Last edited by GNUser (2018-08-29 18:40:59)

GNUser

Member

Registered: 2017-03-16

Posts: 570  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

A solution: In /etc/init.d/eudev, add this as the last line of the start) section (in my file, this line ends up being line 218):     
ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &

That part of /etc/init.d/eudev now looks like this:

# wait for the udevd childs to finish
    log_action_begin_msg "Waiting for /dev to be fully populated"
    if udevadm settle; then
	log_action_end_msg 0
    else
	log_action_end_msg 0 'timeout'
    fi
    ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &
    ;;

    stop)

Last edited by GNUser (2018-08-29 17:54:41)

tormes

Member

Registered: 2019-08-26

Posts: 1  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

Anyone knows if a patch or pull-request was made regarding this solution ?
The source to make that is https://github.com/anto/eudev  or https://git.devuan.org/devuan-packages/eudev ?
Thanks

Last edited by tormes (2019-08-26 15:54:42)

devujan

Member

Registered: 2019-10-26

Posts: 22  

Re: /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED]

It looks like this problem is reoccurring with chimera.
The line

ls /run/udev/tmp-rules* && { sleep 5; /lib/udev/udev-finish; } &

is missing in

/etc/init.d/eudev