Bug 56395 - ifup / ifdown / network reload doesn't work
ifup / ifdown / network reload doesn't work
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-16 13:57 EST by Jonathan Bibeau
Modified: 2014-03-16 22:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-05 15:57:22 EDT
Type: ---
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 Jonathan Bibeau 2001-11-16 13:57:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i686)

Description of problem:
On a default RedHat Linux 7.2 install I have 3 ethernet cards. I wished to
switch eth0 from using the 3c59x card in the machine to using the 8139too.
I changed the modules.conf to reflect this, but a network reload didn't
switch the cards. Doing an lsmod reveiled that the kernel still had the
3c59x module loaded and was using it specificaly for that interface. I had
to reboot the server to get the module to change. I also changed the
interface IP's using linuxconf and it created the following ifcfg-eth0 file
in the /etc/sysconfig/network-scripts:

DEVICE="eth0"
BOOTPROTO="none"
IPADDR="10.0.1.26"
NETMASK="255.255.254.0"
ONBOOT="yes"
IPXNETNUM_802_2=""
IPXPRIMARY_802_2="no"
IPXACTIVE_802_2="no"
IPXNETNUM_802_3=""
IPXPRIMARY_802_3="no"
IPXACTIVE_802_3="no"
IPXNETNUM_ETHERII=""
IPXPRIMARY_ETHERII="no"
IPXACTIVE_ETHERII="no"
IPXNETNUM_SNAP=""
IPXPRIMARY_SNAP="no"
IPXACTIVE_SNAP="no"

Again I changed the IP address of this interface to 10.0.0.45 and a network
reload didn't work. I also tried to run an ifdown eth0; ifup eth0, but that
too wouldn't change the IP address. I ended up having to reboot the
computer again to get it to change the IP...

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


How reproducible:
Always

Steps to Reproduce:
1. Get machine totally running fine
2. Change 1 ethernet card's IP address in cfg file, or change the kernel
module for that ethernet card to point to another ethernet card in your
system
3. Run a network reload or an ifdown eth0; ifup eth0

	

Additional info:

No output error. Scripts simply didn't change the IPs. I could manually
change it if I ran the ifconfig eth0 10.0.0.45 netmask 255.255.254.0
command.
Comment 1 Jonathan Bibeau 2001-11-19 09:27:15 EST
Found the new version on rawhide for initscripts-6.40.2-1.i386.rpm and that
fixed the IP change, but it still doesn't work correctly if I change NICs. When
I move from the 8139too to the 3c59x it doesn't seem to handle that correctly. I
still need to reboot.
Comment 2 Andrew Bartlett 2002-01-26 03:36:57 EST
This issue here is that eth? -> card mapping isn't done by the various scripts,
or even /etc/modules.conf, but by the kernel itself.

What happens is:  sombody asks for eth0.  Kernel tells modprobe to load eth0,
and the associated modules inits.  During that initialisation, it grabs its
name.  If it finds two cards, it can allocate two names.  

Then the next card's driver loads, and the next card is named in sequence.  

The problem is that once a driver 'owns' a name, it doesn't give it up until you
remove the module from the kernel - often over a reboot.

One partial solution is that the scripts should attempt to rmmod all unused
modules during the network reload, but you still can get weird behaviour...
Comment 3 Bill Nottingham 2005-04-05 15:57:22 EDT
Closing bugs on older, no longer supported, releases. Apologies for any lack of
response.

This is not something we're specifically going to handle in the initscript at
this point; note that if you use HWADDR in the config files in current code, it
will attempt to rename the devices to match what you want.

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