Bug 557771 - 70-persistent-net.rules are not created
70-persistent-net.rules are not created
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
: 543483 552762 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2010-01-22 09:45 EST by Michal Schmidt
Modified: 2010-03-12 02:48 EST (History)
6 users (show)

See Also:
Fixed In Version: 145-15.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-02-11 23:46:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
fix inverted logic in udev-post (573 bytes, patch)
2010-01-22 09:45 EST, Michal Schmidt
no flags Details | Diff
fix permission check in udev-post (767 bytes, patch)
2010-01-23 09:49 EST, Michal Schmidt
no flags Details | Diff
dmesg (35.58 KB, text/plain)
2010-01-31 17:27 EST, Martin Naď
no flags Details

  None (edit)
Description Michal Schmidt 2010-01-22 09:45:59 EST
Created attachment 386163 [details]
fix inverted logic in udev-post

Description of problem:
udev is supposed to ensure stable names of network interfaces. For this reason udev usually generates /etc/udev/rules.d/70-persistent-net.rules automatically where mapping from MAC addresses to interface names is defined. However this does not work always. This file is not created after boot.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. rm /etc/udev/rules.d/70-persistent-net.rules
2. Reboot.
Actual results:
70-persistent-net.rules does not exist. So after next reboot we may get different interface names.

Expected results:
70-persistent-net.rules should have been created from scratch by udev after reboot.

Additional info:
70-persistent-net.rules _is_ written if I rmmod a network driver and modprobe it back. So the rule generator itself works and it's only writing of the rules right after boot which is failing.

I found that /etc/init.d/udev-post is supposed to write the rules. I have it enabled:
$ chkconfig --list udev-post
udev-post      	0:off	1:on	2:on	3:on	4:on	5:on	6:off

There seems to be a bug in udev-post which makes its start action effectively a NOP. Patch attached.
Comment 1 Martin Naď 2010-01-22 09:52:14 EST
*** Bug 543483 has been marked as a duplicate of this bug. ***
Comment 2 Harald Hoyer 2010-01-22 09:56:14 EST
does it work, if you change it to:

[ -w /var/lock/subsys ] && exit 4

Comment 3 Michal Schmidt 2010-01-22 10:41:33 EST

no, this does not work. "[ -w /var/lock/subsys ]" will be always true (root can write to this directory), so it would always exit. I actually tested it.

What's the reason to have a test there?
Is it to make sure the start action is executed only once? My patch does that.

Or is it just to make sure the caller is privileged enough? Then you want:
[ -w /var/lock/subsys ] || exit 4
But if the caller were not privileged, the actions would fail anyway, so testing for it explicitly is somewhat pointless.
Comment 4 Harald Hoyer 2010-01-22 11:43:42 EST
doh, of course I meant:

[ -w /var/lock/subsys ] || exit 4

The point is the correct exit code.
Comment 5 Michal Schmidt 2010-01-23 09:49:53 EST
Created attachment 386335 [details]
fix permission check in udev-post

OK, so let's replace both checks (in start and stop) with it.
Comment 6 Harald Hoyer 2010-01-26 05:54:16 EST
*** Bug 552762 has been marked as a duplicate of this bug. ***
Comment 7 Michal Schmidt 2010-01-26 07:17:21 EST
udev-145-15.fc12 works fine. Thanks for applying the fix.
Looking forward to a Bodhi update.
Comment 8 Fedora Update System 2010-01-26 07:57:40 EST
udev-145-15.fc12 has been submitted as an update for Fedora 12.
Comment 9 Steve Tyler 2010-01-26 11:00:40 EST
Confirming that udev-145-15.fc12 fixes Bug 552762.

After a fresh install of F12, 70-persistent-net.rules existed, but 70-persistent-cd.rules did not. 

After installing udev-145-15.fc12 and rebooting, the boot.log showed two lines beginning "udev creating ..." (sorry boot.log got overwritten on the next boot).
70-persistent-cd.rules was created and 70-persistent-net.rules was recreated.

rm /etc/udev/rules.d/70-persistent-cd.rules


No messages.

Why messages the first time and not subsequently? (BTW, I have graphical boot disabled.)

More importantly, testing of a fresh install of F12 evidently missed the problem reported in Bug 552762. Missing symlinks for the optical drive break xine and the eject command.
Comment 10 Fedora Update System 2010-01-27 19:55:42 EST
udev-145-15.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1138
Comment 11 Martin Naď 2010-01-31 17:27:26 EST
Created attachment 387899 [details]

udev: renamed network interface eth0 to eth1                                           
udev: renamed network interface _rename to eth0

bash-4.0$ rpm -q udev
Comment 12 Martin Naď 2010-01-31 17:31:08 EST
sorry , udev is ok ,but this message scare me
> udev: renamed network interface eth0 to eth1                                    
> udev: renamed network interface _rename to eth0
Comment 13 Martin Naď 2010-01-31 17:39:15 EST
# 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 0x10ec:0x8139 (8139too) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:e0:7d:8a:01:6c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10de:0x0269 (forcedeth) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:58:18:cb:d2", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
Comment 14 Fedora Update System 2010-02-11 23:46:05 EST
udev-145-15.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Gavin Davenport 2010-03-11 17:54:13 EST
This issue has just blown up my firewall (4 interfaces).

I can probably reproduce it if required, I think I might have a hardware fault also though.

Coldboot (from power on) - host exhibits mac addresses as follows:
eth0 00:30:18:AC:C8:D5
eth1 00:30:18:AC:C8:D6
eth2 00:30:18:AC:C8:D7
eth3 00:30:18:A6:11:E0

When reset (after init 6) it shows:

This upsets udev-145-15.fc12 immensely, which takes a long time to run and leaves a device as _rename and doesn't enable the driver properly (so it doesn't notice link state changes or see any traffic). If you rmmod and modprobe the driver it works (but that's not acceptable).
Kernels tried:
kernel- (I think this works, but I'm not sure)

I had to force downgrade to udev-145-12.fc12 to get it to start the driver properly after establishing an understanding of where I want the interfaces.

I can produce logs or configs if it would help.
Comment 16 Michal Schmidt 2010-03-12 02:48:32 EST
This looks like a different issue. I suspect a hw or driver problem. Please file a new bug and attach the outputs of lspci -vvnn and dmesg. Put me in CC, I am curious :-)

Note You need to log in before you can comment on or make changes to this bug.