Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 96994 - second ip address won't start at boot unless the first does
second ip address won't start at boot unless the first does
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-06-08 00:33 EDT by Joseph Shraibman
Modified: 2014-03-16 22:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-30 15:01:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joseph Shraibman 2003-06-08 00:33:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529

Description of problem:
I configured two different ip addresses for my machine.  The problem is that
eth0:1 won't start at boot.  It will start from redhat-config-network itself.

Maybe this component should be initscripts and not redhat-config-network?

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

How reproducible:
Comment 1 Harald Hoyer 2003-06-10 11:21:02 EDT
Please try:
Comment 2 Joseph Shraibman 2003-06-10 13:30:36 EDT
That didn't work. What I do a network start after saving the config with that
rechat-config-network this happens:
Bringing up interface home-internal:  Missing config file
[root@jks-laptop ~]# ls /etc/sysconfig/networking/profiles/homedsl/
hosts  ifcfg-home-external  ifcfg-home-internal  network  resolv.conf

... and after I rebooted and the network didn't come up, I tried to start
redhat-config-network to activate the network again, it caused a kernel panic!
Comment 3 Harald Hoyer 2003-06-11 03:21:19 EDT
$ ls /etc/sysconfig/network-scripts
Comment 4 Joseph Shraibman 2003-06-11 10:48:40 EDT
[root@jks-laptop /home/jks]# ls /etc/sysconfig/network-scripts
ifcfg-eth0      ifdown-isdn   ifup-ippp   ifup-routes
ifcfg-eth0:1    ifdown-post   ifup-ipv6   ifup-sit
ifcfg-lo        ifdown-ppp    ifup-ipx    ifup-sl
ifdown          ifdown-sit    ifup-isdn   ifup-wireless
ifdown-aliases  ifdown-sl     ifup-plip   init.ipv6-global
ifdown-cipcb    ifup          ifup-plusb  network-functions
ifdown-ippp     ifup-aliases  ifup-post   network-functions-ipv6
ifdown-ipv6     ifup-cipcb    ifup-ppp
Comment 5 Harald Hoyer 2003-06-11 11:00:37 EDT
Please try:
Comment 6 Joseph Shraibman 2003-06-11 11:07:11 EDT
Are you sure this won't cause a kernel panic?
Comment 7 Joseph Shraibman 2003-06-11 11:38:37 EDT
When I ran it I got this message:
Changed the following Nicknames due to the initscripts:
home-external -> home_externalhome-internal -> home_internal

You need a newline in there or something.

/etc/rc.d/init.d/network start seems to work, but stop only brings down the lo
interface.  I'll try actually rebooting the machine now.
Comment 8 Harald Hoyer 2003-06-11 12:08:23 EDT
applications don't cause kernel panics... bad kernel modules do...
Comment 9 Joseph Shraibman 2003-09-15 19:02:13 EDT
OK that worked at the time (guess I forgot to update, sorry) but I since
upgraded my redhat-config-network to 1.2.15-1 and its broken again
Comment 10 Harald Hoyer 2003-09-16 06:37:05 EDT
huh? what is borken?
Comment 11 Joseph Shraibman 2003-09-16 09:08:42 EDT
/etc/rc.d/init.d/network start does not bring up any eth0 interfaces.  It is
supposed to bring up eth0:1.  After I installed the rpm from comment #5 it
worked, but then a while ago I upgraded redhat-config-network to the current
errata version.  Yesterday I changed my config to bring up both eth0 and eth0:1,
then changed it back to bring up only eth0:1, and I'm back to my original problem.
Comment 12 Harald Hoyer 2003-09-16 09:20:29 EDT
hmmm... sounds like an initscripts issue... but can you please attach your current
Comment 13 Joseph Shraibman 2003-09-16 09:25:45 EDT
/etc/sysconfig/network-scripts]$ cat ifcfg-eth0\:1
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.

There is no ifcfg-eth0
Comment 14 Harald Hoyer 2003-09-16 09:41:35 EDT
Did you deactive the checkbox in the list? Hmm... you shouldn't do that! Another
consistency check for r-c-n.
Please activate the checkbox and edit eth0. Then _de_select "Activate device
when computer starts".
Edit eth0:1 and make sure: "Activate device when computer starts" is active
Comment 15 Joseph Shraibman 2003-09-16 09:47:09 EDT
I thought I was supposed to uncheck the checkbox.

Anyway I did what you said and it still doesn't work.


/etc/sysconfig/network-scripts]$ cat ifcfg-eth0
/etc/sysconfig/network-scripts]$ cat ifcfg-eth0:1
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
Comment 16 Harald Hoyer 2003-09-16 09:59:43 EDT
hmm... then the initscripts cannot cope with eth0:1 active and eth0 not?
reassigning to the initscripts... Bill?
Comment 17 Joseph Shraibman 2003-09-16 10:07:30 EDT
Well like I said you had this fixed at one point, but then I upgraded my
redhat-config-network and broke it.
Comment 18 Bill Nottingham 2003-09-16 11:50:03 EDT
Hm, yes, ifcfg-eth0:1 won't be brought up on boot if ifcfg-eth0 isn't brought up
at all. For aliases, if you have one you want to be brought up at all times,
make it the primary address for now.
Comment 19 Joseph Shraibman 2003-10-01 17:16:04 EDT
Now I have the opposite problem.  Both are coming up, when I only want one to. 
The other one has ONBOOT=no but it still starts up
Comment 20 Bill Nottingham 2003-10-01 18:04:30 EDT
For aliases, set ONPARENT={yes,no}. Aliases don't support ONBOOT at the moment.
Comment 21 Joseph Shraibman 2003-10-02 00:02:35 EDT
Shouldn't redhat-config-network take care of that?  Should I file a seperate bug
for that?
Comment 22 Bill Nottingham 2003-10-02 00:05:29 EDT
ONBOOT may be added for aliases in a future release, so maybe not.

Of course, in future-future releases, the specific alias device framework will
probably be deprecated in favor of just adding more IP addresses to devices. But
that's not going to happen in the next month or two. :)
Comment 23 Bill Nottingham 2005-09-30 15:01:14 EDT
Closing bugs on older, no longer supported, releases. Apologies for any lack of

Realistically, I don't see any issues left here:

- aliases don't operate fully independent of the parent (parent must be up for
any alias to run)
- ONPARENT=(yes|no) is the defined means of changing this.

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