How can I prevent udevd from renaming eth0 to em1

[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?

[Reindl Harald]

Am 16.10.2012 04:58, schrieb JD:
> I googled this and came across 2 purported
> solutions, neither of which worked.
> Uninstall package biosdevname and reboot.
>
> That did not prevent udevd from renaming eth0 to em1.
> 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"

[Bill Shirley]

On 10/16/2012 4: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.
> > Uninstall package biosdevname and reboot.
> >
> > That did not prevent udevd from renaming eth0 to em1.
> > 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 can confirm that this is the way to go.  It works.

I tried the new names on three servers and didn't like it.  On one 
server my first ethernet device is em1; on another it is p14p1.   I find 
myself having to use ifconfig just to find out what name to use when I 
need to take a tcpdump.  (humor intended :-)  Then I have other 
interfaces like: p16p1 & p16p2 (dual card), and p17p1. What if I move a 
card to a different slot?  Will my configuration suddenly fail?

On all the other boxen, eth0 is the LAN and eth1 is the interwebz. 
Nothing much to remember for that.

Bill
PS.  See how cool I am?  I said boxen and interwebz.  :-)

[Joe Zeff]

On 10/16/2012 11:13 AM, Bill Shirley wrote:
> PS.  See how cool I am?  I said boxen and interwebz.  :-)

Well, you were right up to the point where you pointed it out.  Sorry, 
but you're still just a PFY.

[Matthew Miller]

On Tue, Oct 16, 2012 at 02:13:21PM -0400, Bill Shirley wrote:
> I tried the new names on three servers and didn't like it.  On one

On the other side: at my last job, we had a number of servers with multiple
network cards, with a mix of Broadcom and Intel. It was very frustrating to
get systems configured consistently, because it was hard to match the wiring
to the system config -- and often mostly-identical machines came up
differently due to whatever slight variations. We backported biosdevname
from Fedora into CentOS and solved our problem.

[Bill Shirley]

On 10/16/2012 2:16 PM, Joe Zeff wrote:
> On 10/16/2012 11:13 AM, Bill Shirley wrote:
> > PS.  See how cool I am?  I said boxen and interwebz.  :-)
>
> Well, you were right up to the point where you pointed it out. Sorry, 
> but you're still just a PFY.

But..., but..., I use da cloud and program Web 2.0!  Not to mention the 
senergy.

Bill

[Tom Horsley]

On Tue, 16 Oct 2012 14:18:54 -0400
Matthew Miller wrote:
> We backported biosdevname
> from Fedora into CentOS and solved our problem.

Just don't backport any biosdevname updates or the
"immutable" names will change :-).

[JD]

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.
> > Uninstall package biosdevname and reboot.
> >
> > That did not prevent udevd from renaming eth0 to em1.
> > 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"

[JD]

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.
> > > Uninstall package biosdevname and reboot.
> > >
> > > That did not prevent udevd from renaming eth0 to em1.
> > > 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?

[Bruno Wolff III]

On Wed, Oct 17, 2012 at 14:01:25 -0600,
   JD  wrote:
> So, does anyone have any other suggestion how to
> prevent udevd from renaming eth0 to em1?

Do you have 71-biosdevname.rules in either /etc/udev/rules.d or 
/usr/lib/udev/rules.d ? I expect that would run after the persistant 
name rule and reset things.

I actually have the opposite issue in that I want to use the biosdevname 
names, since eth0 and eth1 have been getting assigned randomnly for a 
while now on one of my machines and the renaming ability of the network 
initscripts seems to have gone away.

[Digimer]

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.
> > > > Uninstall package biosdevname and reboot.
> > > >
> > > > That did not prevent udevd from renaming eth0 to em1.
> > > > 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).

[JD]

On 10/17/2012 02:15 PM, Bruno Wolff III wrote:
> On Wed, Oct 17, 2012 at 14:01:25 -0600,
>   JD  wrote:
> > So, does anyone have any other suggestion how to
> > prevent udevd from renaming eth0 to em1?
>
> Do you have 71-biosdevname.rules in either /etc/udev/rules.d or 
> /usr/lib/udev/rules.d ? I expect that would run after the persistant 
> name rule and reset things.
>
> I actually have the opposite issue in that I want to use the 
> biosdevname names, since eth0 and eth1 have been getting assigned 
> randomnly for a while now on one of my machines and the renaming 
> ability of the network initscripts seems to have gone away.

Hi Bruno,
Actually, one of the fedoraproject bloggers said that the renaming is 
being done
by the biosdevname package. So I uninstalled it and rebooted, to  no avail.
So as of now, I have neither the biosdevname package, nor it's corresponding
rules files.

Then some other blogger suggested adding the line
biosdevname=0
into /boot/grub2/grub.cfg
which I did and rebooted, to  no avail. That was followed by
another OP's suggestion to make an entry into
/etc/udev/rules.d/70-persistent-net.rules like
# 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"

which I did, and rebooted to no avail.

So, the only recourse I  have left is to try and download the source code of
udevd to see where and why it is renaming eth0 to em1.

[JD]

On 10/17/2012 02:15 PM, Bruno Wolff III wrote:
> On Wed, Oct 17, 2012 at 14:01:25 -0600,
>   JD  wrote:
> > So, does anyone have any other suggestion how to
> > prevent udevd from renaming eth0 to em1?
>
> Do you have 71-biosdevname.rules in either /etc/udev/rules.d or 
> /usr/lib/udev/rules.d ? I expect that would run after the persistant 
> name rule and reset things.
>
> I actually have the opposite issue in that I want to use the 
> biosdevname names, since eth0 and eth1 have been getting assigned 
> randomnly for a while now on one of my machines and the renaming 
> ability of the network initscripts seems to have gone away.

Searching:
# strings /sbin/udevd | grep renamed
renamed netif to '%s'
<30>udevd[%u]: renamed network interface %s to %s

# strings /sbin/udevadm | grep renamed
renamed netif to '%s'
<30>udevd[%u]: renamed network interface %s to %s

Wonderful, so both programs say it was udevd that did it!!

I will look inside udevd source to see why it makes such a decision.

[JD]

On 10/17/2012 02:15 PM, Bruno Wolff III wrote:
> On Wed, Oct 17, 2012 at 14:01:25 -0600,
>   JD  wrote:
> > So, does anyone have any other suggestion how to
> > prevent udevd from renaming eth0 to em1?
>
> Do you have 71-biosdevname.rules in either /etc/udev/rules.d or 
> /usr/lib/udev/rules.d ? I expect that would run after the persistant 
> name rule and reset things.
>
> I actually have the opposite issue in that I want to use the 
> biosdevname names, since eth0 and eth1 have been getting assigned 
> randomnly for a while now on one of my machines and the renaming 
> ability of the network initscripts seems to have gone away.

OK, so in the udev source package, in file
udev/udev-event.c

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);

However, as I am unfamiliar with this package's  internal logic and data 
structures,
it is still unclear why it finds the  interface index > 0
or the action set to add, nor is it clear why the values being tested 
have these values that cause the renaming.
For example, I have only one wired ethernet interface, so why would it's 
index be greater than 0?

I hope a developer with knowledge of the networking subsystem is able to 
help here.

[JD]

On 10/23/2012 04:10 PM, Bill Davidsen wrote:
> JD wrote:
> > On 10/17/2012 02:15 PM, Bruno Wolff III wrote:
> > > On Wed, Oct 17, 2012 at 14:01:25 -0600,
> > >   JD  wrote:
> > > > So, does anyone have any other suggestion how to
> > > > prevent udevd from renaming eth0 to em1?
> > >
> > > Do you have 71-biosdevname.rules in either /etc/udev/rules.d or
> > > /usr/lib/udev/rules.d ? I expect that would run after the persistant 
> > > name rule
> > > and reset things.
> > >
> > > I actually have the opposite issue in that I want to use the 
> > > biosdevname
> > > names, since eth0 and eth1 have been getting assigned randomnly for 
> > > a while
> > > now on one of my machines and the renaming ability of the network 
> > > initscripts
> > > seems to have gone away.
> >
> > Hi Bruno,
> > Actually, one of the fedoraproject bloggers said that the renaming is 
> > being done
> > by the biosdevname package. So I uninstalled it and rebooted, to  no 
> > avail.
> > So as of now, I have neither the biosdevname package, nor it's 
> > corresponding
> > rules files.
> >
> > Then some other blogger suggested adding the line
> > biosdevname=0
> > into /boot/grub2/grub.cfg
> > which I did and rebooted, to  no avail. That was followed by
> > another OP's suggestion to make an entry into
> > /etc/udev/rules.d/70-persistent-net.rules like
> > # 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"
> >
> > which I did, and rebooted to no avail.
> >
> > So, the only recourse I  have left is to try and download the source 
> > code of
> > udevd to see where and why it is renaming eth0 to em1.
>
> What release are you running? I don't match this to fc16, fc17, or 
> rhel6. You must have a pretty old release, because you mentioned old 
> style output from ifconfig, no colon after the device name.

Bill I am still on FC16.
I tried to use the F17 DVD to UPGRADE to f17, and it (In mean anaconda) 
crashed.
So, I am waiting for F18 perhaps migh be more robust.

[JD]

On 10/28/2012 04:08 PM, Reindl Harald wrote:
> Am 21.10.2012 10:57, schrieb JD:
> > > What release are you running? I don't match this to fc16, fc17, or rhel6. You must have a pretty old release,
> > > because you mentioned old style output from ifconfig, no colon after the device name.
> >
> > Bill I am still on FC16.
> > I tried to use the F17 DVD to UPGRADE to f17, and it (In mean anaconda) crashed.
> > So, I am waiting for F18 perhaps migh be more robust
>
> http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedo...
>
> done on more than 25 machines (physical and vmware)
> the last few weeks without any problem
>
> many of them are installed 2008 with F9 and did all the upgrades
> F9->F10->F11->F12->F13->F14->F15->F16->F17 with yum
>
> preupgrade/anaconda did only make torubles the 3 times i tried

As you know, doing upgrade is also a slow process.
It crashed on me in 2 tries and I abandoned it.
The sha256sum of the iso (before burning, and after burning,
copying the dvd back to HD), and running the sha256 sum came
up exactly as placed in the CHECKSUMS file. Running the Anaconda
media check also passed. So, it was not caused by any media
integrity problem,
But....
We diverge here to a totally different thread, which has already been
hashed and rehashed.

Cheers,

JD

[Bill Davidsen]

JD wrote:
> On 10/17/2012 02:15 PM, Bruno Wolff III wrote:
> > On Wed, Oct 17, 2012 at 14:01:25 -0600,
> >   JD  wrote:
> > > So, does anyone have any other suggestion how to
> > > prevent udevd from renaming eth0 to em1?
> >
> > Do you have 71-biosdevname.rules in either /etc/udev/rules.d or
> > /usr/lib/udev/rules.d ? I expect that would run after the persistant name rule
> > and reset things.
> >
> > I actually have the opposite issue in that I want to use the biosdevname
> > names, since eth0 and eth1 have been getting assigned randomnly for a while
> > now on one of my machines and the renaming ability of the network initscripts
> > seems to have gone away.
>
> Hi Bruno,
> Actually, one of the fedoraproject bloggers said that the renaming is being done
> by the biosdevname package. So I uninstalled it and rebooted, to  no avail.
> So as of now, I have neither the biosdevname package, nor it's corresponding
> rules files.
>
> Then some other blogger suggested adding the line
> biosdevname=0
> into /boot/grub2/grub.cfg
> which I did and rebooted, to  no avail. That was followed by
> another OP's suggestion to make an entry into
> /etc/udev/rules.d/70-persistent-net.rules like
> # 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"
>
> which I did, and rebooted to no avail.
>
> So, the only recourse I  have left is to try and download the source code of
> udevd to see where and why it is renaming eth0 to em1.

What release are you running? I don't match this to fc16, fc17, or rhel6. You 
must have a pretty old release, because you mentioned old style output from 
ifconfig, no colon after the device name.

[Reindl Harald]

Am 21.10.2012 10:57, schrieb JD:
> > What release are you running? I don't match this to fc16, fc17, or rhel6. You must have a pretty old release,
> > because you mentioned old style output from ifconfig, no colon after the device name.
>
> Bill I am still on FC16.
> I tried to use the F17 DVD to UPGRADE to f17, and it (In mean anaconda) crashed.
> So, I am waiting for F18 perhaps migh be more robust

http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedo...

done on more than 25 machines (physical and vmware)
the last few weeks without any problem

many of them are installed 2008 with F9 and did all the upgrades
F9->F10->F11->F12->F13->F14->F15->F16->F17 with yum

preupgrade/anaconda did only make torubles the 3 times i tried