Bug 557771

Summary: 70-persistent-net.rules are not created
Product: [Fedora] Fedora Reporter: Michal Schmidt <mschmidt>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: chrise, gavdav, harald, jonathan, martin.nad89, stephent98
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 145-15.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-02-11 23:46:36 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
fix inverted logic in udev-post
none
fix permission check in udev-post
none
dmesg none

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):
udev-145-14.fc12.x86_64

How reproducible:
always

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
Harald,

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.
http://admin.fedoraproject.org/updates/udev-145-15.fc12
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

reboot

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]
dmesg

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

bash-4.0$ rpm -q udev
udev-145-15.fc12.x86_64
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:
00:00:00:00:C8:D5
00:00:00:00:C8:D6
00:00:00:00:C8:D7
00:30:18:A6:11:E0

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-2.6.32.9-67.fc12.i686
kernel-2.6.32.9-70.fc12.i686 (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
Gavin,
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 :-)