Bug 816577

Summary:	Problem with renaming devices
Product:	[Fedora] Fedora	Reporter:	Bruno Wolff III <bruno>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	bruno, iarlyy, initscripts-maint-list, jonathan, lnykryn, notting, plautrba, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-03-28 14:23:25 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:

Description Bruno Wolff III 2012-04-26 12:47:23 UTC

Description of problem:
Due to what I suspect is a change to dracut, my network devices appear to have had their names swapped during the boot process. My ifcfg-eth0 and ifcfg-eth1 files have hardware addresses specified so the network service (NOT NetworkManager) is supposed to rename the devices to match. It looks like an attempt was made to do this as one device was named rename2 and the other eth1. Though eth1 still needed to be renamed. When I tried to finish this manually I noticed that the eth1 link was up and that ip link set dev eth1 name eth0 failed because of this. I needed to set the link down before I could rename it.

Version-Release number of selected component (if applicable):
initscripts-9.37-1.fc18.i686

How reproducible:
I am not sure.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Bruno Wolff III 2012-08-21 14:51:37 UTC

Now the behavior I am seeing is that the network service fails and that both eth0 and eth1 are left in a down state if their hardware addresses don't match what's in the ifcfg-eth* files. This happens on very roughly half the boots now.
I can manually swap the inferface names and start the network service and then things work normally.

Comment 2 Lukáš Nykrýn 2013-03-28 13:55:29 UTC

Is this still an issue? We made some changes in network naming in f18+.

Comment 3 Bruno Wolff III 2013-03-28 14:09:28 UTC

The machine I was using that had two NICs was switched over to biosdev naming and so I'd be less likely to see the problem. But in any case, I haven't had a problem with this in a long time.

Comment 4 Lukáš Nykrýn 2013-03-28 14:23:25 UTC

Thanks for quick answer. I will close this as fixed in current release, but if anyone has still some similar issues, feel free to reopen this bug.