Bug 979322
Summary: | udev keeps adding _X_ to device name | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Netbulae <info> | ||||
Component: | udev | Assignee: | Harald Hoyer <harald> | ||||
Status: | CLOSED CANTFIX | QA Contact: | qe-baseos-daemons | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.4 | CC: | dmitry, udev-maint-list | ||||
Target Milestone: | rc | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-08-29 14:48:17 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Netbulae
2013-06-28 08:40:56 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? 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 ;-)
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. 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. (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. 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 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_ 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) |