How can I prevent udevd from renaming eth0 to em1

Mon Oct 22 20:12:17 UTC 2012

on machines without "biosdevname" installed thsese crap
simply does not exist (or better: should not) and IF it
exists this is a bug!

[root at srv-rhsoft:~]$ stat /lib/udev/rules.d/71-biosdevname.rules
stat: cannot stat `/lib/udev/rules.d/71-biosdevname.rules': No such file or directory

Installed:
  biosdevname.x86_64 0:0.4.1-1.fc17

Complete!
[root at srv-rhsoft:~]$ stat /lib/udev/rules.d/71-biosdevname.rules
  File: `/lib/udev/rules.d/71-biosdevname.rules'
  Size: 958             Blocks: 8          IO Block: 4096   regular file
Device: 901h/2305d      Inode: 1228        Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Removed:
  biosdevname.x86_64 0:0.4.1-1.fc17

[root at srv-rhsoft:~]$ stat /lib/udev/rules.d/71-biosdevname.rules
stat: cannot stat `/lib/udev/rules.d/71-biosdevname.rules': No such file or directory

Am 22.10.2012 21:56, schrieb sirdeiu:
> Hi guys, 
> 
> On another note, I'm now in Fedora 18 Beta TC6 - Just installed from netinstall.iso - KDE desktop. After
> installation, my NIC's were named with p35pX. So I've just edited /lib/udev/rules.d/71-biosdevname.rules and
> uncommented the line GOTO="netdevicename_end", saved and rebooted. And got back my ethX names.
> 
> So simple and working. Also interesting find on your part Michael H. Warfield. Guess we still need to inspect the
> matter further.
> 
> So to the OP, JD, maybe try reinstalling biosdevname back and making the modification in the said rules file. Or
> try what Michael said, regarding recompiling initramfs.
> 
> Have a good day.
> 
>  
> 
> On , Michael H. Warfield wrote:
> 
>> On Sat, 2012-10-20 at 21:01 -0600, JD wrote:
>>> On 10/20/2012 08:41 PM, Michael H. Warfield wrote:
>>>> On Thu, 2012-10-18 at 10:05 -0600, JD wrote:
>>>>> On 10/18/2012 09:16 AM, Tim wrote:
>>>>>> On Thu, 2012-10-18 at 08:11 -0600, JD wrote:
>>>>>>> I assure you the MAC does match the MAC of the Ethernet chipset. Looking at the quotes:..
>>>>>> I meant taking out some other rules which mightn't match, so you *only* trying to match the MAC, not the MAC
>>>>>> *and* this *and* that.
>>>>>>> All entries have exactly the same quotes around every item right of the
>>>>>> Must have just gone missing in the post.
>>>>> Made the change and rebooted. Sorry - it does not deter udev from screwing up! $ dmesg | grep em1 [ 6.033303]
>>>>> udevd[218]: renamed network interface eth0 to em1 $ cat /etc/udev/rules.d/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 0x1039:0x0900 (sis900) SUBSYSTEM=="net",
>>>>> ATTR{address}=="edited out", KERNEL=="eth*", NAME="eth0"
>>>> I had the same problem you did (didn't work removing biosdevname and didn't work adding the suggested
>>>> persistent-net rules) until I went to that posting another contributor made toward a tutorial. Following his
>>>> instructions, I ended up with this: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>>>> ATTR{address}=="00:19:b9:13:a8:fc", NAME="eth0" The earlier (in this thread) suggestion was this:
>>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:b9:13:a8:fc", ATTR{dev_id}=="0x0",
>>>> ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" That did NOT work for me either. The difference drops these three
>>>> stanzas: ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", That seems to have made it work for me. At least
>>>> it's now working for me. I may try and add those stanzas back in one by one to see which one broke it. Since
>>>> you dropped the first two but kept the KERNEL=="eth*" stanza, maybe that's your problem. Regards, Mike
>>> Tried it Mike! No go!
>>> $ dmesg | grep em1 [ 6.040224] udevd[221]: renamed network interface eth0 to em1 I think udev is busted. I do
>>> not care who defends it or lauds it. I think it is a piece of unmentionable stinking matter!!!
>> You've come to a conclusion and it's coloring where you are looking at
>> this point.  I think there's a surprise and a rat in the woodpile here.
>>
>> First off, what version of Fedora are you running?  Is it up to date?
>> What kernel are you running?
>>
>> I took one of my systems (a big Dell 2U PowerEdge 2850 running F17 which
>> had not been updated in months) that had two em? interfaces (em1 and
>> em2) and two p?p? interfaces (p3p1 and p3p2) and stepped through the
>> following process...
>>
>> Ran dmesg | udev and got this...
>>
>> [mhw at toolroom ~]$ dmesg | grep udevd
>> [    1.717298] udevd[152]: starting version 182
>> [    3.314207] udevd[264]: renamed network interface eth1 to em2
>> [    3.350217] udevd[264]: renamed network interface eth1 to p3p1
>> [    3.642203] udevd[264]: renamed network interface eth1 to p3p2
>> [    3.647220] udevd[266]: renamed network interface eth0 to em1
>> [   14.564305] udevd[418]: starting version 182
>>
>> Curious, now that I notice it (you'll understand further below) that
>> udevd gets started twice and the renaming is taking place after the
>> first one starts...
>>
>> Ok...  Next I updated the entire system (it was way out of date) and
>> rebooted (NO OTHER CHANGES)!  Ran that same command...
>>
>> [mhw at toolroom ~]$ dmesg | grep udev
>> [    1.772069] udevd[159]: starting version 182
>> [   12.087460] udevd[368]: starting version 182
>>
>> Still, 2 startup messages...
>>
>> Lovely.  It's no longer posting the rename network interface messages to
>> syslog.  This was with the 3.6.2-4.fc17.x86_64.  Neither the biosdevname
>> or udev packages where updated when I updated the system but the kernel
>> was.  More on that...
>>
>> So, I tried uncommenting in /usr/lib/udev/rules.d/71-biosdevname.rules
>> the line that changes the biosdevname default and rebooted.  No effect.
>> Still em1, em2, p3p1, and p3p2.  No joy.  Hmmm...
>>
>> So, I erased biosdevname and rebooted.  No effect.  Sigh...
>>
>> So I created this /etc/udev/rules.d/70-persistent-net.rules...
>>
>> -- 
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:43:5a:fc:91", NAME="eth0"
>>
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:43:5a:fc:92", NAME="eth1"
>>
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:04:23:ac:c2:14", NAME="eth2"
>>
>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:04:23:ac:c2:15", NAME="eth3"
>> -- 
>>
>> Rebooted.  That worked like a charm!  Added in solely the stanza for
>> 'KERNEL=="eth*",' and rebooted.  That failed!  WTH???
>>
>> Removed that from all 4 rules and added back in the attribute stanzas of
>> 'ATTR{dev_id}=="0x0", ATTR{type}=="1",' and rebooted.  That worked!  I
>> have eth0 through eth3 just fine.
>>
>> dmesg | grep udev gives me just the startup messages still.  ???
>>
>> Now, I rebooted back to an earlier kernel and the interfaces are just
>> fine.  But, look what I get when I run that dmesg command from
>> 3.4.6-2.fc17.x86_64...
>>
>> [mhw at toolroom ~]$ dmesg | grep udevd
>> [    1.722324] udevd[152]: starting version 182
>> [    3.211207] udevd[267]: renamed network interface eth1 to em2
>> [    3.500210] udevd[267]: renamed network interface eth1 to p3p1
>> [    3.791215] udevd[267]: renamed network interface eth1 to p3p2
>> [    3.797205] udevd[270]: renamed network interface eth0 to em1
>> [   12.929898] udevd[419]: starting version 182
>> [   15.412289] udevd[507]: renamed network interface em1 to eth0
>> [   15.530323] udevd[506]: renamed network interface p3p2 to eth3
>> [   15.537301] udevd[508]: renamed network interface em2 to eth1
>> [   15.629208] udevd[505]: renamed network interface p3p1 to eth2
>>
>> Woa!  Something weird going on here!  Looks like udevd got started
>> twice, the first time renaming the interfaces to these other values and
>> the second time renaming them back!  This sounds like something going on
>> in some of the initramfs stuff or earlier in the boot process.  That
>> explains why the KERNEL="eth*" stanza caused it to break.  By the time
>> THAT udevd is getting to it, it's too late.  It's already been renamed
>> by the earlier invocation so it never matches.
>>
>> Interestingly enough, while the 419 process is still running, the 152
>> process is not:
>>
>> [mhw at toolroom ~]$ ps ax | grep udev
>>   419 ?        Ss     0:00 /usr/lib/udev/udevd
>>   582 ?        S      0:00 /usr/lib/udev/udevd
>>   583 ?        S      0:00 /usr/lib/udev/udevd
>>
>> This all occurred BEFORE the active udevd started up!  Now it's
>> configured to revert the changes the first one made.
>>
>> I was going to suggest enabling some debugging in the udev.conf file
>> but, at this point, I don't thing the problem is in the active udevd
>> processes that are running (and you probably have your rules messed up
>> somewhere - I don't know where but I do know that udev can be flaky as a
>> 3 euro note) but really is caused by some rules in some early boot
>> phase.  It's all rule driven.
>>
>> Sure enough.  Unpacked the initramfs package with this command:
>>
>> mkdir initramfs
>> cd initramfs
>> zcat /boot/initramfs-3.4.6-2.fc17.x86_64.img | cpio -icvdlm
>>
>> Next look in usr/lib/udev/rules.d
>>
>> [root at toolroom initramfs]# ls usr/lib/udev/rules.d/
>> 10-dm.rules         50-udev-default.rules        71-biosdevname.rules
>> 11-dm-lvm.rules     60-pcmcia.rules              80-drivers.rules
>> 13-dm-disk.rules    60-persistent-storage.rules  95-dm-notify.rules
>> 40-multipath.rules  64-md-raid.rules             95-udev-late.rules
>>
>> Oh, oh.  Gee...  I wonder what random acts of terrorism will come of
>> that "71-biosdevname.rules" file?
>>
>> That SHOULD be possible to disable by adding the biosdevname=0 parameter
>> to the kernel command like but, off course, grub2 has to make that as
>> difficult as possible and you can't just edit /etc/grub2.cfg.
>>
>> So, having already removed the biodevname package, I rebuilt the
>> initramfs file with this...
>>
>> # cd /boot
>> # mv initramfs-3.4.6-2.fc17.x86_64.img initramfs-3.4.6-2.fc17.x86_64.img-
>> # dracut initramfs-3.4.6-2.fc17.x86_64.img 3.4.6-2.fc17.x86_64
>>
>> Unpacked that one.  Hmmm...  No more 71-biosdevname.rules.  That's a
>> good sign.  Rebooted...
>>
>> [mhw at toolroom ~]$ dmesg | grep udev
>> [    1.726473] udevd[152]: starting version 182
>> [   12.745712] udevd[414]: starting version 182
>>
>> Looking good.  No renaming and renaming back and the interfaces look
>> good.
>>
>> Removed my 70-persistent-net.rules file from /etc/udev/rules.d and
>> rebooted again...
>>
>> Tried it with the 3.6.2-4.fc17.x86_64 kernel.  Rebuild the initramfs
>> file and rebooted (no persistent-net.rules file in place).  Came up
>> perfect with eth0 - eth3.
>>
>> No persistent-net rules and it boots up perfect with the correct
>> interface names and no renames.  Game over (for me at least).
>>
>> Bottom line...  It's biosdevname even though you erased it.  After
>> erasing the biodevname package you must rebuild all your initramfs
>> images!  Try that and see if it helps.
>>> -- users mailing list users at lists.fedoraproject.org <mailto:users at lists.fedoraproject.org> To unsubscribe or
>>> change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines:
>>> http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
> 
>  
> 
>  
> 
> 

-- 

Reindl Harald
the lounge interactive design GmbH
A-1060 Vienna, Hofmühlgasse 17
CTO / CISO / Software-Development
p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40
icq: 154546673, http://www.thelounge.net/

http://www.thelounge.net/signature.asc.what.htm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20121022/f7543ac8/attachment-0001.sig>