Bug 132925 - initscripts use old ifconfig instead of iproute2
Summary: initscripts use old ifconfig instead of iproute2
Status: CLOSED DUPLICATE of bug 65114
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 14
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL: http://www.redhat.com/archives/fedora...
Whiteboard: bzcl34nup
: 82171 (view as bug list)
Depends On:
Blocks: FC6Target 171491
TreeView+ depends on / blocked
Reported: 2004-09-19 20:37 UTC by Robert Scheck
Modified: 2014-03-17 02:48 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-10-27 16:07:51 UTC
Type: ---

Attachments (Terms of Use)

Description Robert Scheck 2004-09-19 20:37:16 UTC
Description of problem:
I think (hope), that my bug report isn't a duplicate (but I didn't
find a bug report when I searched for it):

> While I agree that ip is superior, I think lots of people still 
> use ifconfig for basic network configuration. Removing it will 
> confuse some users and break many scripts:
>         grep ifconfig /etc/sysconfig/network-scripts/* 

Hey, file a bug on that, please. :)

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

Actual results:
initscripts base on and use the old ifconfig instead of iproute2.

Expected results:
initscripts should use ip of iproute2.

Comment 1 Robert Scheck 2005-05-20 17:24:02 UTC
Bill, we are moving this bug around from FC3 to FC4 and from FC4 to FC5 - can
we get rid of this bug _really_ before FC5 or can I already move it to FC10? ;-)

Comment 2 Bill Nottingham 2005-05-20 18:06:02 UTC
Ha, point taken. The key is to actually get to it *early* in the cycle, instead
of always remembering it late in the cycle.

Comment 3 Cole 2005-06-14 18:00:23 UTC
Although some may like to use ifconfig, I believe that the option to use
iproute2 should be present in intiscripts, especially when bonding and ipchains
come into play.

Comment 4 Bill Nottingham 2005-09-30 21:58:20 UTC
*** Bug 82171 has been marked as a duplicate of this bug. ***

Comment 5 Robert Scheck 2006-05-31 21:05:02 UTC
Ping - Bill?

Comment 6 Bug Zapper 2008-04-03 15:39:45 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 7 Robert Scheck 2008-04-03 15:47:46 UTC
Hum? Since when is Rawhide no longer maintained? The problem still exists in 

Comment 8 Tom "spot" Callaway 2008-04-03 17:55:20 UTC
Looking at the cases where ifconfig shows up:

1. in sysconfig/network-scripts/network-functions (in check_device_down() ):

The ifconfig call is conditionalized so that it is only used for virtual devices
(aka, where the device name contains a :). I wonder if this is a failure of ip
to detect those devices correctly.

2. in sysconfig/network-scripts/network-functions-ipv6:

There is a function (ipv6_exec_ifconfig()) which calls ifconfig, but I can't see
anything that calls it.

3. in sysconfig/network-scripts/ifup-iucv

This diff takes care of most of it, but ip doesn't understand netmask in the
same way that ifconfig does:

@@ -27,7 +27,8 @@ fi
 echo "$PEERID" > /sys/bus/iucv/drivers/netiucv/connection 2>/dev/null
-ifconfig ${DEVICE} ${IPADDR} ${opts} pointopoint ${GATEWAY} netmask ${NETMASK}
+ip link set ${DEVICE} up ${opts}
+ip addr add dev ${DEVICE} ${IPADDR}/${NETMASK} peer ${GATEWAY}
 if [ "${NETWORK}" != "" ] ; then
 	route add -host ${GATEWAY} metric 1 ${DEVICE}

We'd also need to change NETMASK in /etc/sysconfig/network-devices/ifconfig.eth* :
from to 32
 ..   to 24
 ..     to 16
 ..       to 8

This is a rather significant, and backwards incompatible change. We could
probably parse the NETMASK field first, but I'll leave that to others to determine.

Also, all of the route command calls probably need to be replaced with "ip
route" calls. There are quite a few of them.

sysconfig/network-scripts/ifup-plip, sysconfig/network-scripts/ifup-ctc,
sysconfig/network-scripts/ifup-ippp and sysconfig/network-scripts/ifup-plusb all
need (basically) the same set of changes.

4. in sysconfig/network-scripts/ifup-aliases

The first time it shows up... well, I can't tell you what ifconfig is doing there.
The second and third time it appears, its dropping a virtual/child interface
(aka, a device with a : in its name).
The fourth time is setting netmask, see above comments.
The fifth time also sets netmask, same as above.
The sixth is the same as the second and third appearances.

Comment 9 Denis Ovsienko 2008-04-03 18:25:50 UTC
Tom, the so called "virtual devices" are just IP addresses in the common so
called  "IP networks" terminology. But that's not important anyway. If you feel
uncomfortable closing one more initscripts bug as INVALID or WONTFIX, let
William Nottingham do this in a couple of years. initscripts are such a holy
cow, that you can't fix them for the sole purpose of technological excellence,
there must be a serious business or political reason in addition.

Have fun :-)

/etc/net author and happy user

Comment 10 Tom "spot" Callaway 2008-04-03 18:36:10 UTC
Take a deep breath man. Bill is a rather busy guy, and its easy for small stuff
to fall off his radar.

If you've got the necessary skills to do the conversion, I would highly
encourage you to generate a patch and attach it to the bug, as that will speed
things along significantly.

Comment 11 Denis Ovsienko 2008-04-03 19:25:52 UTC
To my best knowledge, it's not the case. #195365 review request had been blocked
for one year by #195353 change request and the latter used to be refused on- and

My main point is still the same: fixing the network part of initscripts is
following a dead end. Introducing an alternative system is not only possible,
it's been demanded for many years. But are you in a position to accept these

Comment 12 Tom "spot" Callaway 2008-04-03 19:31:56 UTC
If patches come in, I will take them forward. I won't commit them over Bill's
objections, but I suspect that he doesn't oppose this, just doesn't have the
time to look into these changes at the moment.

Comment 13 Tom "spot" Callaway 2008-04-03 19:40:32 UTC
To be clear, I'm not considering completely overhauling the existing network
scripts, simply looking for patches to replace ifconfig with ip.

Comment 14 Denis Ovsienko 2008-04-03 19:57:32 UTC
Ok, I see. I'm not the one to fix initscripts, excuse me.

Comment 15 Bug Zapper 2008-05-14 01:57:15 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 16 Bug Zapper 2009-06-09 09:07:07 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:

Comment 17 Christopher Beland 2010-02-25 19:33:57 UTC
"ifconfig" references are still present in initscripts-9.02.1-1.i686 (Fedora 12).

Comment 18 Tom "spot" Callaway 2010-02-25 21:00:09 UTC
Wow, life on this golden oldie. 

Lemme be clear: This one isn't going to change until someone gives a patch to replace the ifconfig invocations with ip.

Accordingly, I'm lifting F13Target.

Comment 19 Bug Zapper 2010-04-27 11:35:44 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 20 Robert Scheck 2010-04-27 11:44:18 UTC
The problem still exists in Rawhide.

Comment 21 Bug Zapper 2010-07-30 10:25:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 22 Jirka Klimes 2010-10-27 08:40:09 UTC
(In reply to comment #18)
> Wow, life on this golden oldie. 
> Lemme be clear: This one isn't going to change until someone gives a patch to
> replace the ifconfig invocations with ip.
> Accordingly, I'm lifting F13Target.

There is a patch to replace ifconfig with ip in ifup-aliases - bug 65114 (wow, so old bug).
Could somebody review that and apply?

Comment 23 Tom "spot" Callaway 2010-10-27 13:17:44 UTC
I wonder if that patch is relevant in a systemd world...

Comment 24 Bill Nottingham 2010-10-27 16:07:51 UTC

*** This bug has been marked as a duplicate of bug 65114 ***

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