Bug 63861 - ethernet aliases dont work after upgrading to skipjack-beta2
ethernet aliases dont work after upgrading to skipjack-beta2
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
9
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-19 13:50 EDT by Mike Bird
Modified: 2014-03-16 22:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-29 15:51:35 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 Mike Bird 2002-04-19 13:50:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-31 i686)

Description of problem:
After upgrading from 7.2 to skipjack-beta2, ethernet aliases dont work.  The
code seems to have been removed from /etc/init.d/network

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


How reproducible:
Didn't try


Additional info:

/etc/sysconfig/network-scripts/ifcfg-eth0:0 contains just two lines

IPADDR="209.17.70.5"
NETMASK=""

On boot or on "service network --full-restart", this address does not come up. 
Comparing /etc/init.d/network between the two versions, the support for aliases
seems to have been removed.
Comment 1 Milan Kerslager 2002-04-21 11:56:23 EDT
Confirmed for beta4.

Seems to be a BUG.
Comment 2 Bill Nottingham 2002-04-21 15:21:24 EDT
Support for *linuxconf* was removed... these sorts of configurations appear to
have relied on linuxconf behavior.

Add 'DEVICE=eth0:0' to the file and it should work fine.
Comment 3 Mike Bird 2002-04-21 16:43:44 EDT
This upgrade knocks long-established servers offline.  Modulo ownership of
airline stocks, I think most people would consider it a bug.

Perhaps the upgrade should run a script which checks for configurations it can
no longer handle and either rewrite them to a supported form and issue or
warning or (minimal) just issue a warning and explanation.

Better still, the package should continue to support this format so that the
many admins still running linuxconf don't fall into this trap when making future
changes.

<rant>RedHat should stop deprecating valuable tools such as lilo and linuxconf,
until the replacements can do the job (e.g. handling RAID).  linuxconf has had
some problems but it's still way better than redhat-config-*, and doesn't
require X-windows, Gnome, Glade, Python2 etc to be installed on light-weight
servers.   We're also looking at webmin for some situations.</rant>
Comment 4 Bill Nottingham 2002-04-21 20:23:03 EDT
linuxconf has been marked deprecated since 7.1.

FWIW, lilo is still in the beta and is supported in the installer. I'm not sure
what you're talking about there.
Comment 5 Mike Bird 2002-04-21 20:41:40 EDT
The problem is still not fixed.  A server upgrade is going to result in a broken
network configuration after reboot.  In some cases this will require an airline
ticket to fix.  Are you assuming that everyone runs redhat-config-network before
upgrading, even if they have no changes to make?

I'm not going to get into a status changing contest with you.  Hopefully RedHat
QA will step in.  If not, there are plenty of distributions that are not trying
to sabotage their customers.
Comment 6 Bill Nottingham 2002-04-21 21:08:11 EDT
I don't see where redhat-config-network comes into this.

The problem is that this has been a configuration not on the main support path
for   just slightly over a year now. It is most certainly *not* a bug that
linuxconf support was removed. It may be possible to fix this particular case,
but there are  almost certainly going to be cases that relied on the internal
behavior of linuxconf, and therefore can't be fixed.
Comment 7 Bill Nottingham 2005-09-29 15:51:35 EDT
Closing bugs on older, no longer supported, releases. Apologies for any lack of
response.

If this persists on a current release, such as Fedora Core 4, please open a new bug.

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