Bug 816577 - Problem with renaming devices
Problem with renaming devices
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-26 08:47 EDT by Bruno Wolff III
Modified: 2014-03-16 23:30 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-28 10:23:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2012-04-26 08:47:23 EDT
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 10:51:37 EDT
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 09:55:29 EDT
Is this still an issue? We made some changes in network naming in f18+.
Comment 3 Bruno Wolff III 2013-03-28 10:09:28 EDT
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 10:23:25 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.