on machines without "biosdevname" installed thsese crap
simply does not exist (or better: should not) and IF it
exists this is a bug!
[root@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@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@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@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 <mailto: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
>
>
>
>
>
>
--
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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- 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
