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.
*** Bug 543483 has been marked as a duplicate of this bug. ***
does it work, if you change it to: [ -w /var/lock/subsys ] && exit 4 ?
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.
doh, of course I meant: [ -w /var/lock/subsys ] || exit 4 The point is the correct exit code.
Created attachment 386335 [details] fix permission check in udev-post OK, so let's replace both checks (in start and stop) with it.
*** Bug 552762 has been marked as a duplicate of this bug. ***
udev-145-15.fc12 works fine. Thanks for applying the fix. Looking forward to a Bodhi update.
udev-145-15.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/udev-145-15.fc12
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.
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
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
sorry , udev is ok ,but this message scare me > udev: renamed network interface eth0 to eth1 > udev: renamed network interface _rename to eth0
# 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"
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.
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.
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 :-)