Red Hat Bugzilla – Bug 63861
ethernet aliases dont work after upgrading to skipjack-beta2
Last modified: 2014-03-16 22:27:06 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):
/etc/sysconfig/network-scripts/ifcfg-eth0:0 contains just two lines
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.
Confirmed for beta4.
Seems to be a BUG.
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.
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
<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>
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.
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.
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.
Closing bugs on older, no longer supported, releases. Apologies for any lack of
If this persists on a current release, such as Fedora Core 4, please open a new bug.