RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 979322 - udev keeps adding _X_ to device name
Summary: udev keeps adding _X_ to device name
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev
Version: 6.4
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-28 08:40 UTC by Netbulae
Modified: 2014-09-12 13:57 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-29 14:48:17 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
requested files (17.05 KB, application/x-bzip)
2013-08-08 09:30 UTC, Netbulae 		no flags Details
View All

Description Netbulae 2013-06-28 08:40:56 UTC 
Description of problem:

This is driving me crazy. I have one server that loses it's network on reboot. When checking it appears a _ gets added in front and one _ at the back of the device name. 

Every reboot it just add's more devices with extra _ _ and I cannot get the network up again. Even when I remove all the entries in 70-persistent-net.rules, I still get more.

cat /etc/udev/rules.d/70-persistent-net.rules 

# PCI device 0x8086:0x10d3 (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:b9:20:46", ATTR{type}=="1", KERNEL=="eth*", NAME="___eth0___"

# PCI device 0x8086:0x10d3 (e1000e) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:30:48:b9:20:47", ATTR{type}=="1", KERNEL=="eth*", NAME="___eth1___"


Version-Release number of selected component (if applicable):

udev-147-2.42.el6.x86_64
Comment 2 Harald Hoyer 2013-07-02 09:59:37 UTC 
wow.. never seen this before. There is either a bug in the default scripts or you have a custom helper udev rule, which sets your interface name.

Can you attach all

/etc/udev/rules.d/*.rules
/lib/udev/rules.d/*.rules
/etc/sysconfig/network-scripts/ifcfg-*

files?
Comment 3 Netbulae 2013-08-08 09:30:48 UTC 
Created attachment 784272 [details]
requested files

Sorry it took me a while. I had to visit the datacenter to get it up at all and we have a lot of vacation in the Europe ;-)
Comment 4 Harald Hoyer 2013-08-09 08:23:43 UTC 
you /etc/sysconfig/network-scripts/ifcfg-eth0 contains:

DEVICE="___eth0___" 
HWADDR=00:30:48:B9:20:46

so the interface with the mac 00:30:48:B9:20:46 will get renamed to ___eth0___

Works as expected.

Same for ifcfg-eth1.
Comment 5 Netbulae 2013-08-10 08:44:31 UTC 
Yes that's right, but I didn't name it ___eth0___ ..... 

I previously removed the other entries, but it went like this "eth0", "_eth0_", "__eth0__" everytime a new one get's added and the older one remains.

I removed all the older entries because I thought when I reboot it would start at eth0 again.

When I reboot again it will get renamed ____eth0____, but I will have to go to the datacenter again because the network fails to come up as the ifcfg-eth0 will have the wrong device name.

So there should be some code that does this, when is a rename triggered? 

I don't use NetworkManager for the record.
Comment 6 Harald Hoyer 2013-08-14 15:32:45 UTC 
(In reply to Netbulae from comment #5)
> Yes that's right, but I didn't name it ___eth0___ ..... 
> 
> I previously removed the other entries, but it went like this "eth0",
> "_eth0_", "__eth0__" everytime a new one get's added and the older one
> remains.
> 
> I removed all the older entries because I thought when I reboot it would
> start at eth0 again.
> 
> When I reboot again it will get renamed ____eth0____, but I will have to go
> to the datacenter again because the network fails to come up as the
> ifcfg-eth0 will have the wrong device name.
> 
> So there should be some code that does this, when is a rename triggered? 
> 
> I don't use NetworkManager for the record.

None of the tools I know edit /etc/sysconfig/network-scripts/ifcfg-eth0 and change the DEVICE= line.
Comment 7 Dmitry S. Makovey 2014-09-11 21:39:28 UTC 
I'm seeing the same issue. ifcfg-eth0 script is _not_ modified, however with each boot I get _eth0_ in /etc/udev/rules.d/70-persistent-net.rules 

I have done following:

* remove /etc/udev/rules.d/70-persistent-net.rules
* made sure /etc/sysconfig/network-scripts/ifcfg-eth0 has DEVICE="eth0" and proper MAC address
* added biosdevname=0 to boot params.

rebooted box... still get _eth0_ instead of eth0.

looked at bug #614943 - none of solutions helped. system is an up-to-date RHEL-6.4 VM
Comment 8 Dmitry S. Makovey 2014-09-12 13:54:09 UTC 
tried following as well:

* remove /etc/udev/rules.d/70-persistent-net.rules
* made sure /etc/sysconfig/network-scripts/ifcfg-eth0 has DEVICE="eth0" and proper MAC address
* ip link dev set _eth0_ name eth0
* dracut -f -v
* reboot

...and still was greeted with _eth0_
Comment 9 Dmitry S. Makovey 2014-09-12 13:57:16 UTC 
I think I've found a possible source of problem:

originally I set up machines with kickstart (to note - it excluded NetworkManager) and had erroneous IP listed there. That produces all the issues down the line. When I corrected kickstart and ran install again - issue is gone. (remember machine didn't use NetworkManager in both cases and the only place where NM would kick in - install time)
Note You need to log in before you can comment on or make changes to this bug.