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@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@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@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@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@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@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(a)lists.fedoraproject.org To
unsubscribe or change subscription
options:
Links:
------
[1]
http://ask.fedoraproject.org