[rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names!

[Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list]

On Thu, Feb 21, 2013 at 1:38 PM, Red Hat Enterprise Linux 6 (Santiago)
discussion mailing-list <rhelv6-list at redhat.com> wrote:
> Hi,
> Thanks for the response.  I think RHEL 6 has been using these device names
> for a while now.

Ugh, I read your initial post wrong.  Disregard my prior.

I apologize as none of my RHEL6 Servers have it installed.  I must
apologize as I have been working with a lot of whitebox, IBM blade and
other solutions as of late, including KVM and RHEV guest instances
too.  In most cases, I have a single interface (eth0), while the
chassis or hypervisor has bonded ones.  I guess that's my oversight.

However, it would not surprise me if Dell systems have switched,
possibly some pizza-type tier-1 boxes where your end-instance is the
actual, physical NICs out.  This was their idea.  Upstream Fedora has
been using them for some time as well, so I expect it will be a
standard in RHEL7.

Indeed, biosdevname re-educated me.  It's providing those OEM mappings.

> http://en.community.dell.com/techcenter/b/techcenter/archive/2011/05/26/meaningful-names-for-network-devices-in-rhel-6-sp1-on-dell-systems.aspx
> rpm -qi biosdevname shows the package coming from redhat

Red Hat develops a lot of packages with assistance from IHV, including
specifics for their hardware, that are in Red Hat's packages.  Indeed,
biosdevname is the Red Hat solution that allows renaming to the BIOS
devname (OEM name).

> On another system, I have devices named em1 and em2 for example.
> Interestingly, this system also is missing a 70-persistent-net.rules file in
> udev/rules.d!

It can be set in several places.  As with most standards, the /etc/
entries are usually for site-local or post-install changes, while
[/var]/lib or /usr/share tends to be the location for defaults.

I'm now seeing /etc/udev/rules.d/71-biosdevname.rules.

> I better tread carefully with reboots :)
> PS. We are a academic customer and can't open cases for issues like this.
> Unless, it is happening on our satellite or proxy! :)

Duly noted.  My apologies for misreading your initial post.


--
Bryan J Smith - Professional, Technical Annoyance
b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith