Bug 158564 - Path to ifrename should be /sbin/ifrename, not /usr/sbin/ifrename
Summary: Path to ifrename should be /sbin/ifrename, not /usr/sbin/ifrename
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: hotplug   
(Show other bugs)
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-23 15:59 UTC by Pavel Roskin
Modified: 2014-03-17 02:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-23 16:55:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Pavel Roskin 2005-05-23 15:59:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050512 Fedora/1.0.4-2 Firefox/1.0.4

Description of problem:
/etc/hotplug/net.agent refers to /usr/sbin/ifrename.  However, ifrename is installed under /sbin as part of wireless-tools-28-0.pre4.3

Version-Release number of selected component (if applicable):
hotplug-2004_09_23-6

How reproducible:
Always

Steps to Reproduce:
1. Add "tu* driver tulip" to /etc/ifrename
2. Rename /etc/sysconfig/network-scripts/ifcfg-eth0 to /etc/sysconfig/network-scripts/ifcfg-tu0, change DEVICE in that file accordingly.
3. Reboot the OS.
  

Actual Results:  The interface is down, still called eth0.

Expected Results:  The interface is renamed to tu0 and brought up.

Additional info:

Comment 1 Bill Nottingham 2005-05-23 16:55:32 UTC
You do realize with the DEVICE= line changed and HWADDR set in the config file,
ifrename isn't needed at all?

Fixed in -7.

Comment 2 Pavel Roskin 2005-05-25 15:45:45 UTC
Actually, it would be nice if startup scripts worked the way you described, but
ithey don't.  ifup-eth checks that the device already has a valid MAC address to
rename it.  That would work if e.g. eth0 and eth1 become assigned in a different
order to the same devices.

If I use custom names like tu0, they don't have a MAC address because they don't
exist on startup.  I'll file a separate bug for this issue.



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