Arch Linux

This used to be done by the initscripts, but it is not anymore (as it is not supported by upstream). Do you get back the behavior you want if you move /etc/udev/rules.d/75-persistent-net-generator-rules.conf.optional to /etc/udev/rules.d/75-persistent-net-generator-rules.conf?

"Do you get back the behavior you want if you move /etc/udev/rules.d/75-persistent-net-generator-rules.conf.optional to /etc/udev/rules.d/75-persistent-net-generator-rules.conf?"

I thought this was a standard procedure to generate 70-persistent-net.rules after reboot. I did that and no file was generated upon boot up that is.

If I remove modules from kernel and reinsert them manually 70-persistent-net.rules is generated and gets bigger after each module insertion.
rmmod e100 ; modprobe e100
rmmod e1000 ; modprobe e1000
rmmod r8169 ; modprobe r8169

commands above generate 70-persistent-net.rules file which used to be generated automatically in the boot process.

Thanks for the reply.

This is what happens:
When a new net device appears, udev tries to write the persistent rule file to /etc/udev/rules.d. However, if this is not writable (e.g. during boot), it will fall back to placing a temporary rules file in /run/udev/. This will make sure that your devices will be consistently named if you unplug/plug rmmod/modprobe them, but it will not be preserved on reboot.

Earlier we copied the rules from /run/udev to /etc/udev when the latter was remounted rw. Upstream changed the location of the temporary files so this broke. They also say that we should not be relying on the layout of /run/udev, so probably there is a better way to do this than to copy the files. I will look into what others are doing and try to ask the udev devs what they suggest.

If anyone knows a good solution please shout :-)

sometimes I miss static /dev directory :D those were the days...

Thanks for response tomegun! Hopefully udev people have some suggestions.

@tiny: you can still keep your static stuff in /lib/udev/devices if you really want to ;-)

I got a response from Kay. Apparently this rule generation is on its way out, but there is no proper replacement in place yet.

A workaround is to run "udevadm trigger --subsystem-match=net --action=add", or to copy the rule files from /run to /etc manually.

I think will have to add back the copying magic to initscripts for the next release (but be warned that it will probably be removed for good soon).

If you want to know the future plans for udev, have a look at Kay's reply: <http://marc.info/?l=linux-hotplug&m=130469470817499&w=2>.

I committed this fix: <https://github.com/teg/initscripts-arch/commit/2f2f2516eb1dd9e97f38564e6177f6630bc84b40>. Could you let me know if it does not work?

Yes, unfortunately it does not work.
I can attach files and list directories for additional debugging if bug is reopened.
I waited for monday since I needed server running and didn't have physical access to it in case it doesn't come up after reboot.

]# ps -fe | grep udev
root 505 1 0 08:34 ? 00:00:00 /sbin/udevd --daemon
root 623 505 0 08:34 ? 00:00:00 /sbin/udevd --daemon
root 624 505 0 08:34 ? 00:00:00 /sbin/udevd --daemon
root 1098 1055 0 09:54 pts/0 00:00:00 grep udev


[root@websrv rules.d]# ls -l
total 8
-rw-r--r-- 1 root root 462 Apr 9 23:28 75-cd-aliases-generator.rules.optional
-rw-r--r-- 1 root root 3981 May 5 12:58 75-persistent-net-generator.rules

ifconfig ; ifconfig -a
http://paste.pocoo.org/show/385687/

I'm reconfirming this bug. I _reinstalled_ a fresh new setup from network install over PXE.
Tested default setup without success. Patched rc.conf, no joy.

70-persistent-net.rules still not generated.


[root@websrv rules.d]# ls -l
total 8
-rw-r--r-- 1 root root 462 May 4 09:02 75-cd-aliases-generator.rules.optional
-rw-r--r-- 1 root root 3981 May 4 09:02 75-persistent-net-generator.rules
[root@websrv rules.d]#


Attaching some files.

everything.log has a 13:43:20 field with successful dhcpcd client request. This was after manual startup with "/etc/rc.d/network ifup eth1"

Thanks. Very sorry, there was a typo in my patch. A new one is on its way...

Does the attached rc.sysinit fix it for you?

Wow, lots of changes and line shufling :)
Looks like it did the trick though.


[root@websrv rules.d]# ls -l
total 12
-rw-r--r-- 1 root root 998 May 9 15:15 70-persistent-net.rules
-rw-r--r-- 1 root root 462 May 4 09:02 75-cd-aliases-generator.rules.optional
-rw-r--r-- 1 root root 3981 May 4 09:02 75-persistent-net-generator.rules

[root@websrv rules.d]# cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x8086:0x1050 (e100)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:20:31:51:ca", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x8086:0x1019 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:13:20:31:51:c9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x10ec:0x8169 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:40:f4:ba:df:82", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x10ec:0x8169 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:40:f4:ba:df:6a", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

Btw,

at what point at boot time system checks if there's a
75-persistent-net-generator.rules
and not
75-persistent-net-generator.rules.optional

file in /etc/udev/rules.d/ ?

I'm reading Arch boot process wiki and can't find related information.

Thanks for fixing this! Will this go into official release now?

This post explain pretty much everything.

http://marc.info/?l=linux-hotplug&m=130469470817499&w=2

Thanks again.

Great! This is from the official git, so it will be in the next release (hopefully this week, just waiting for some patches). The reason for all the shuffling is that I just sent you the newest version of rc.sysinit, so it contains a lot of unrelated changes, the fix for your issue was just a simple typo ;-)

How this works:

When a new device appears udev will look for a matching rule. It will read 70-* before 75-*, so if you already have a rule for your device a new one is not created. Udev will only read files that end in .config, so it ignores .config.optional.

The 75-* rules will create the 70-* rules, so that the names of your devices stay persistent. However, if udev cannot write to /etc/udev/rules.d (e.g. during early boot), it will have to write the rule files to /run/udev instead (as it is always writable).

This is the only point where initscripts needs to do anything. We have to copy the temporary rules to the persistent location to make sure they are not lost on shutdown.

It should be noted that the rule generation logic will go away in a future udev release, but hopefully a better replacement will be in place first. The idea will be that nothing happens automatically, but that you have to manually indicate which network device should get what name. Just pointing this out in case you are relying on these rules, so you'll be prepared ;-)