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@xxxxxxxxxxxxxxxxxxxxxxx
> 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
>
--
Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@xxxxxxxxxxxx
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx 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
