On 10/17/2012 03:59 PM, Digimer wrote:
On 10/17/2012 05:44 PM, JD wrote:
On 10/17/2012 02:38 PM, Digimer wrote:
On 10/17/2012 04:01 PM, JD wrote:
On 10/16/2012 05:05 PM, JD wrote:
On 10/16/2012 02:27 AM, Reindl Harald wrote:
Am 16.10.2012 04:58, schrieb JD: > I googled this and came across 2 purported > solutions, neither of which worked. > 1. Uninstall package biosdevname and reboot. > > That did not prevent udevd from renaming eth0 to em1. > > 2. Add the line > biosdevname=0 > to /boot/grub2/grub.cfg > > That did not work either. > Any other way to get around this renaming? find out your MAC-address with "ifconfig -a" make a udev-rule like below (ONE line) for the MAC reboot the machine after that and you are done
[root@rh:~]$ cat /etc/udev/rules.d/70-persistent-net.rules # PCI device 0x8086:0x1502 (e1000e) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="78:ac:c0:b1:76:e4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
I made the change and rebooted.
$ dmesg | grep em1 [ 5.949297] udevd[219]: renamed network interface eth0 to em1 $ ifconfig eth0 eth0: error fetching interface information: Device not found
$ 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 0x168c:0x0023 (ath9k) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="edited-out", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
# PCI device 0x1039:0x0900 (sis900) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="edited-out", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# USB device 0x0bda:0x8187 (usb) (custom name provided by external tool) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="edited-out", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"
So, does anyone have any other suggestion how to prevent udevd from renaming eth0 to em1?
Here is what I wrote down for changing ethernet devices to any arbitrary name you want, including ethX, under Fedora 17 (15+, actually).
https://alteeve.ca/w/Changing_Ethernet_Device_Names_in_EL7_and_Fedora_15%2B
You don't need to mess with biosdevname, juts set/edit 70-persistent-net.rules (details described in the above link).
The author says on that web page:
You can download and run this and it will print a skeleton udev file. If the output looks good, re-run it again and pipe the output to the 70-persistent-net.rules file.
Well, I ran his script. It outputs nothing, and exits with status 0.
That's me. It does an 'ifconfig -a' and, parses the interfaces and spits out entries formatted for udev.d. So if it printed nothing, check to see if 'ifconfig -a' shows any interfaces.
digimer
Briefly.... $ ifconfig -a em1 Link encap:Ethernet HWaddr xx:xx:...etc
lo Link encap:Local Loopback
virbr0 Link encap:Ethernet HWaddr xx:xx:...etc
virbr0-nic Link encap:Ethernet HWaddr xx:xx:...etc
wlan0 Link encap:Ethernet HWaddr xx:xx:...etc
On 10/17/2012 06:24 PM, JD wrote:
Briefly.... $ ifconfig -a em1 Link encap:Ethernet HWaddr xx:xx:...etc
lo Link encap:Local Loopback
virbr0 Link encap:Ethernet HWaddr xx:xx:...etc
virbr0-nic Link encap:Ethernet HWaddr xx:xx:...etc
wlan0 Link encap:Ethernet HWaddr xx:xx:...etc
Ah, I see. On my systems, I get:
=== em1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether f0:de:f1:fc:65:b3 txqueuelen 1000 (Ethernet) ===
So the script says "grab any non-space character up to the colon (foo:). Your now showing a colon, so it fails to match.
Try replacing:
=== if ($line =~ /^(\S+):/) ===
With:
=== if ($line =~ /^(\S+)/) ===
On 10/17/2012 09:18 PM, Digimer wrote:
On 10/17/2012 06:24 PM, JD wrote:
Briefly.... $ ifconfig -a em1 Link encap:Ethernet HWaddr xx:xx:...etc
lo Link encap:Local Loopback
virbr0 Link encap:Ethernet HWaddr xx:xx:...etc
virbr0-nic Link encap:Ethernet HWaddr xx:xx:...etc
wlan0 Link encap:Ethernet HWaddr xx:xx:...etc
Ah, I see. On my systems, I get:
=== em1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether f0:de:f1:fc:65:b3 txqueuelen 1000 (Ethernet) ===
So the script says "grab any non-space character up to the colon (foo:). Your now showing a colon, so it fails to match.
Try replacing:
=== if ($line =~ /^(\S+):/) ===
With:
=== if ($line =~ /^(\S+)/) ===
Strike that, I see that you are also showing the HWADDR on the same line, so the whole regex this is going to miss your output.
Skip the script; The main thing is to take the 'em1 ... HWadd: aa:bb:cc:dd:ee:ff' and put it in 70-persistent-net.rules as (one line);
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"
Then in you 'ifcfg-eth0' file, set 'DEVICE="eth0"' and make sure there is no HWADDR="..." line. Reboot and you should be golden.
On 10/17/2012 07:22 PM, Digimer wrote:
On 10/17/2012 09:18 PM, Digimer wrote:
On 10/17/2012 06:24 PM, JD wrote:
Briefly.... $ ifconfig -a em1 Link encap:Ethernet HWaddr xx:xx:...etc
lo Link encap:Local Loopback
virbr0 Link encap:Ethernet HWaddr xx:xx:...etc
virbr0-nic Link encap:Ethernet HWaddr xx:xx:...etc
wlan0 Link encap:Ethernet HWaddr xx:xx:...etc
Ah, I see. On my systems, I get:
=== em1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether f0:de:f1:fc:65:b3 txqueuelen 1000 (Ethernet) ===
So the script says "grab any non-space character up to the colon (foo:). Your now showing a colon, so it fails to match.
Try replacing:
=== if ($line =~ /^(\S+):/) ===
With:
=== if ($line =~ /^(\S+)/) ===
Strike that, I see that you are also showing the HWADDR on the same line, so the whole regex this is going to miss your output.
Skip the script; The main thing is to take the 'em1 ... HWadd: aa:bb:cc:dd:ee:ff' and put it in 70-persistent-net.rules as (one line);
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"
Then in you 'ifcfg-eth0' file, set 'DEVICE="eth0"' and make sure there is no HWADDR="..." line. Reboot and you should be golden.
I did do just that, as also vehemently stated by many other bloggers I read on other web sites. Unfortunately, IT DOES NOT WORK!! Here is what I have in /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:03:0d:15:2b:9e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0
and I rebooted several times, and yet still:
$ ifconfig eth0 eth0: error fetching interface information: Device not found $ ifconfig em1 em1 Link encap:Ethernet HWaddr 00:....etc BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:19 Base address:0xd800 and
$ dmesg | grep em1 [ 5.982317] udevd[219]: renamed network interface eth0 to em1
I posted the logic in udev source code where it decides to rename. I admit that I do not know the udev code, but there might be a problem in the values of numbers being passed to udev that are incorrect, like the interface's device index being > 0 Where is this info being gleaned from and passed to udev? Also, since the name in the rule file is eth0, how is this part of the conditional strcmp(event->name, udev_device_get_sysname(dev)) != 0 failing? In otherwords, udev_device_get_sysname() is returning a name other than eth0.
Here is that code segment again:
if (udev_device_get_ifindex(dev) > 0 && strcmp(udev_device_get_action(dev), "add") == 0 && event->name != NULL && strcmp(event->name, udev_device_get_sysname(dev)) != 0) { char syspath[UTIL_PATH_SIZE]; char *pos;
err = rename_netif(event);
On Wed, 2012-10-17 at 19:49 -0600, JD wrote:
I did do just that, as also vehemently stated by many other bloggers I read on other web sites. Unfortunately, IT DOES NOT WORK!! Here is what I have in /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:03:0d:15:2b:9e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0
I don't see a closing quote at the very end.
It's a very long time since I looked at hardware rule making, but can you omit some of the clauses, and simplify it down to just matching the MAC? (i.e. Try and omit the DRIVERS or ATTR, sections, et cetera.) I seem to recall advice, along those lines, for setting rules to match other hardware (such as for mounting specific drives at specific places).
On 10/18/2012 02:41 AM, Tim wrote:
On Wed, 2012-10-17 at 19:49 -0600, JD wrote:
I did do just that, as also vehemently stated by many other bloggers I read on other web sites. Unfortunately, IT DOES NOT WORK!! Here is what I have in /etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:03:0d:15:2b:9e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0
I don't see a closing quote at the very end.
It's a very long time since I looked at hardware rule making, but can you omit some of the clauses, and simplify it down to just matching the MAC? (i.e. Try and omit the DRIVERS or ATTR, sections, et cetera.) I seem to recall advice, along those lines, for setting rules to match other hardware (such as for mounting specific drives at specific places).
Hi Tim, I assure you the MAC does match the MAC of the Ethernet chipset. Looking at the quotes:.. All entries have exactly the same quotes around every item right of the == . To wit: # PCI device 0x1039:0x0900 (sis900) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="edited out", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
I think the bug is in udev itself.
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.
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"
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
On 10/20/2012 08:41 PM, Michael H. Warfield wrote:
On Thu, 2012-10-18 at 10:05 -0600, JD wrote:
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
Thank you Michael. Will try it and get back to you.
Cheers,
JD
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!!!
A while back, I ran into a problem trying to rename interface names (details of which I no longer remember). The solution at the time was to create an empty '/etc/udev/rules.d/70-persistent-net.rules', then to make it immutable (chattr -i /etc/udev/rules.d/70-persistent-net.rules), then finally to create '/etc/udev/rules.d/69-persistent-net.rules' with the rules/names I wanted. Maybe this will help you?
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...
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@lists.fedoraproject.org To unsubscribe or change subscription options:
Links: ------ [1] http://ask.fedoraproject.org
On Mon, Oct 22, 2012 at 10:56:08PM +0300, sirdeiu wrote:
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.
When you find completely unreasonable names like p35, it's worth filing a bug so it gets better.
Matthew Miller wrote:
On Mon, Oct 22, 2012 at 10:56:08PM +0300, sirdeiu wrote:
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.
When you find completely unreasonable names like p35, it's worth filing a bug so it gets better.
It is not unreasonable just because it's not useful to you. I think unreasonable is not providing a MAC-to-name option as part of the distro, and not making ethN the default on any system with only a single NIC, but the default names generated do mean something, just something not needed or understood by most users.
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@lists.fedoraproject.org mailto:users@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
On Sat, 2012-10-20 at 22:41 -0400, Michael H. Warfield wrote:
Following his instructions, I ended up with this:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:b9:13:a8:fc", NAME="eth0"
Finding it hard to remember the plot, but is that rule set for matching something the computer was doing? (Rather than telling it to name it eth0, it's asking if it's called eth0.) Because, if your network isn't called eth0, though you want it to be, then trying to match against an eth0 that isn't being used, isn't going to match.
Isn't the behaviour, find this (rule set), then call it (something of your own choosing, named somewhere else in the script/program/config)?
In which case, remove the name and eth0 clause.
On Sun, 2012-10-21 at 15:24 +1030, Tim wrote:
On Sat, 2012-10-20 at 22:41 -0400, Michael H. Warfield wrote:
Following his instructions, I ended up with this:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:b9:13:a8:fc", NAME="eth0"
Finding it hard to remember the plot, but is that rule set for matching something the computer was doing? (Rather than telling it to name it eth0, it's asking if it's called eth0.) Because, if your network isn't called eth0, though you want it to be, then trying to match against an eth0 that isn't being used, isn't going to match.
Isn't the behaviour, find this (rule set), then call it (something of your own choosing, named somewhere else in the script/program/config)?
In which case, remove the name and eth0 clause.
No, this worked for me. If I included the KERNEL= and the other ATTR= clauses, it failed but I'm not sure which clause caused it to fail. JD is saying it's still failing for him.
Now that being said, there's still some notable differences. Most of my machines (some F16 and some F17, some i686 and some x86_64) came up with p2p1 for interface names and his is coming up em1. Obviously something is different. Also, he's reporting a udevd change of the interface name in dmesg, which I'm not seeing even on the machines where it's still changing eth0 to p2p1. So there's something significantly different in his set-up and maybe even versions that's making this difference. I have one machine I have access to that is not mine that is showing em1 as the interface name and it's an F16 i686 system (older Dell tower). It shows BOTH that name and that renaming. If I tinker with it and break the networking, then I have to drive to that location to fix it.
I did just discover that I have a Dell PowerEdge 2850 on hand that shows em1 and em2 as well as p3p1 and p3p2 (em1 is the main network interface). That beast has F17 on it and udevd is reporting the interface changes like JD is seeing:
[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
I can play with the other three interfaces and see what I can accomplish without risking the whole bloody server and a field trip. This stuff has to be coming from somewhere. I'll report back.
-- [tim@localhost ~]$ uname -rsvp Linux 3.6.2-4.fc17.x86_64 #1 SMP Wed Oct 17 02:43:21 UTC 2012 x86_64
All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists.
Regards, Mike
On Sun, Oct 21, 2012 at 13:43:17 -0400, "Michael H. Warfield" mhw@WittsEnd.com wrote:
Now that being said, there's still some notable differences. Most of my machines (some F16 and some F17, some i686 and some x86_64) came up with p2p1 for interface names and his is coming up em1. Obviously something
em1 would be the first embedded nic. Probably its built into the motherboard. p2p1 is a nic attached to the pic bus. I think its the second slot, first port. (Probably the card has only one port, but some have more than one.)
On Sun, 2012-10-21 at 23:02 -0500, Bruno Wolff III wrote:
On Sun, Oct 21, 2012 at 13:43:17 -0400, "Michael H. Warfield" mhw@WittsEnd.com wrote:
Now that being said, there's still some notable differences. Most of my machines (some F16 and some F17, some i686 and some x86_64) came up with p2p1 for interface names and his is coming up em1. Obviously something
em1 would be the first embedded nic. Probably its built into the motherboard. p2p1 is a nic attached to the pic bus. I think its the second slot, first port. (Probably the card has only one port, but some have more than one.)
Ok... And that then makes it even weirder since all my Dell towers (Optiplex GX620 x86_64 machines and Optiplex GX280 i686 machines) are all uniformly coming up p2p1 for the motherboard nic (they don't have any add-on nics). Maybe it's the way they are designed... IAC, my Dell 2U PowerEdge helped me diagnose the problem and chase it into the initramfs and biosdevname.
Thanks!
Regards, Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2012 12:15 AM, Michael H. Warfield wrote:
On Sun, 2012-10-21 at 23:02 -0500, Bruno Wolff III wrote:
On Sun, Oct 21, 2012 at 13:43:17 -0400, "Michael H. Warfield" mhw@WittsEnd.com wrote:
Now that being said, there's still some notable differences. Most of my machines (some F16 and some F17, some i686 and some x86_64) came up with p2p1 for interface names and his is coming up em1. Obviously something
em1 would be the first embedded nic. Probably its built into the motherboard. p2p1 is a nic attached to the pic bus. I think its the second slot, first port. (Probably the card has only one port, but some have more than one.)
Ok... And that then makes it even weirder since all my Dell towers (Optiplex GX620 x86_64 machines and Optiplex GX280 i686 machines) are all uniformly coming up p2p1 for the motherboard nic (they don't have any add-on nics). Maybe it's the way they are designed... IAC, my Dell 2U PowerEdge helped me diagnose the problem and chase it into the initramfs and biosdevname.
Thanks!
Regards, Mike
It's an imperfect science. My onboard NICs also come up as p1p1 and p1p2.
- -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Digimer wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/22/2012 12:15 AM, Michael H. Warfield wrote:
On Sun, 2012-10-21 at 23:02 -0500, Bruno Wolff III wrote:
On Sun, Oct 21, 2012 at 13:43:17 -0400, "Michael H. Warfield" mhw@WittsEnd.com wrote:
Now that being said, there's still some notable differences. Most of my machines (some F16 and some F17, some i686 and some x86_64) came up with p2p1 for interface names and his is coming up em1. Obviously something
em1 would be the first embedded nic. Probably its built into the motherboard. p2p1 is a nic attached to the pic bus. I think its the second slot, first port. (Probably the card has only one port, but some have more than one.)
Ok... And that then makes it even weirder since all my Dell towers (Optiplex GX620 x86_64 machines and Optiplex GX280 i686 machines) are all uniformly coming up p2p1 for the motherboard nic (they don't have any add-on nics). Maybe it's the way they are designed... IAC, my Dell 2U PowerEdge helped me diagnose the problem and chase it into the initramfs and biosdevname.
They may be on an internal PCI bus and look external, I'm not sure how "embedded" a NIC is to be recognized as such.
Thanks!
Regards, Mike
It's an imperfect science. My onboard NICs also come up as p1p1 and p1p2.
Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education?
Michael H. Warfield wrote:
On Sun, 2012-10-21 at 15:24 +1030, Tim wrote:
On Sat, 2012-10-20 at 22:41 -0400, Michael H. Warfield wrote:
Following his instructions, I ended up with this:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:b9:13:a8:fc", NAME="eth0"
Finding it hard to remember the plot, but is that rule set for matching something the computer was doing? (Rather than telling it to name it eth0, it's asking if it's called eth0.) Because, if your network isn't called eth0, though you want it to be, then trying to match against an eth0 that isn't being used, isn't going to match.
Isn't the behaviour, find this (rule set), then call it (something of your own choosing, named somewhere else in the script/program/config)?
In which case, remove the name and eth0 clause.
No, this worked for me. If I included the KERNEL= and the other ATTR= clauses, it failed but I'm not sure which clause caused it to fail. JD is saying it's still failing for him.
Now that being said, there's still some notable differences. Most of my machines (some F16 and some F17, some i686 and some x86_64) came up with p2p1 for interface names and his is coming up em1. Obviously something is different. Also, he's reporting a udevd change of the interface name in dmesg, which I'm not seeing even on the machines where it's still changing eth0 to p2p1. So there's something significantly different in his set-up and maybe even versions that's making this difference. I have one machine I have access to that is not mine that is showing em1 as the interface name and it's an F16 i686 system (older Dell tower). It shows BOTH that name and that renaming. If I tinker with it and break the networking, then I have to drive to that location to fix it.
I did just discover that I have a Dell PowerEdge 2850 on hand that shows em1 and em2 as well as p3p1 and p3p2 (em1 is the main network interface). That beast has F17 on it and udevd is reporting the interface changes like JD is seeing:
As I recall, the emN names are for internal NICs (on the system board) and the p{stuff} ones are for plugin NIC cards. I think it does something totally different and even less obvious for (a) a USB Wifi dongle, or (b) a USB to J45 adapter.
[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
I can play with the other three interfaces and see what I can accomplish without risking the whole bloody server and a field trip. This stuff has to be coming from somewhere. I'll report back.
-- [tim@localhost ~]$ uname -rsvp Linux 3.6.2-4.fc17.x86_64 #1 SMP Wed Oct 17 02:43:21 UTC 2012 x86_64
All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I will only read messages posted to the public lists.
Regards, Mike
Digimer wrote:
On 10/17/2012 09:18 PM, Digimer wrote:
On 10/17/2012 06:24 PM, JD wrote:
Briefly.... $ ifconfig -a em1 Link encap:Ethernet HWaddr xx:xx:...etc
lo Link encap:Local Loopback
virbr0 Link encap:Ethernet HWaddr xx:xx:...etc
virbr0-nic Link encap:Ethernet HWaddr xx:xx:...etc
wlan0 Link encap:Ethernet HWaddr xx:xx:...etc
Ah, I see. On my systems, I get:
=== em1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether f0:de:f1:fc:65:b3 txqueuelen 1000 (Ethernet) ===
So the script says "grab any non-space character up to the colon (foo:). Your now showing a colon, so it fails to match.
Try replacing:
=== if ($line =~ /^(\S+):/) ===
With:
=== if ($line =~ /^(\S+)/) ===
Strike that, I see that you are also showing the HWADDR on the same line, so the whole regex this is going to miss your output.
Skip the script; The main thing is to take the 'em1 ... HWadd: aa:bb:cc:dd:ee:ff' and put it in 70-persistent-net.rules as (one line);
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"
Then in you 'ifcfg-eth0' file, set 'DEVICE="eth0"' and make sure there is no HWADDR="..." line. Reboot and you should be golden.
He's going to have to create an ifcfg file for this device, right? Will the ifup do the right thing for an em hardware interface renamed to eth (don't have em so can't compare)
On 10/23/2012 06:20 PM, Bill Davidsen wrote:
Digimer wrote:
On 10/17/2012 09:18 PM, Digimer wrote:
On 10/17/2012 06:24 PM, JD wrote:
Briefly.... $ ifconfig -a em1 Link encap:Ethernet HWaddr xx:xx:...etc
lo Link encap:Local Loopback
virbr0 Link encap:Ethernet HWaddr xx:xx:...etc
virbr0-nic Link encap:Ethernet HWaddr xx:xx:...etc
wlan0 Link encap:Ethernet HWaddr xx:xx:...etc
Ah, I see. On my systems, I get:
=== em1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether f0:de:f1:fc:65:b3 txqueuelen 1000 (Ethernet) ===
So the script says "grab any non-space character up to the colon (foo:). Your now showing a colon, so it fails to match.
Try replacing:
=== if ($line =~ /^(\S+):/) ===
With:
=== if ($line =~ /^(\S+)/) ===
Strike that, I see that you are also showing the HWADDR on the same line, so the whole regex this is going to miss your output.
Skip the script; The main thing is to take the 'em1 ... HWadd: aa:bb:cc:dd:ee:ff' and put it in 70-persistent-net.rules as (one line);
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"
Then in you 'ifcfg-eth0' file, set 'DEVICE="eth0"' and make sure there is no HWADDR="..." line. Reboot and you should be golden.
He's going to have to create an ifcfg file for this device, right? Will the ifup do the right thing for an em hardware interface renamed to eth (don't have em so can't compare)
Yes, you need a corresponding 'ifcfg-<dev>' file to match the udev.d's NAME="<dev>" value. Do not use the ifcfg-<dev>'s 'HWADDR="..."' though.
On 10/23/2012 6:52 PM, Digimer wrote:
Yes, you need a corresponding 'ifcfg-<dev>' file to match the udev.d's NAME="<dev>" value. Do not use the ifcfg-<dev>'s 'HWADDR="..."' though.
I started using the NAME parameter in Fedora 16. ifcfg-lan: NAME="lan" TYPE=Ethernet ONBOOT="yes" UUID="331f16e6-ee78-40a6-b06d-c906491821ee" HWADDR="00:22:19:20:AF:2D" NM_CONTROLLED="no" . . .
This allows me to just: ifup lan ifdown lan
This helps when you have more than one internet connection or when you have operators that don't really know what eth1 is. ifup Comcast ifup ISP2
Bill PS. Still have to remember what-is-what with ifconfig tough.
-
Andrei Amuraritei -
Bill Davidsen -
Bill Shirley -
Bruno Wolff III -
Digimer -
JD -
Matthew Miller -
Michael H. Warfield -
Reindl Harald -
Tim