How can I prevent udevd from renaming eth0 to em1

[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 To unsubscribe or change subscription
options:

 

Links:
------
[1] http://ask.fedoraproject.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20121022/7649a507/attachment.html>