Bug 125916 - modprobe does not seem to pay much attention to aliases
modprobe does not seem to pay much attention to aliases
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Depends On:
  Show dependency treegraph
Reported: 2004-06-13 20:15 EDT by Michal Jaegermann
Modified: 2015-01-04 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-16 01:12:57 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 Michal Jaegermann 2004-06-13 20:15:35 EDT
Description of problem:

I have a machine with two network cards where one is using sk98lin
driver and another one e100.  The following aliases are defined
in /etc/modprobe.conf (in /etc/modules.conf for FC1 installation)

alias eth0 sk98lin
alias eth1 e100

If I will put in /etc/sysconfig/network-scripts/ifcfg-eth0
in /etc/sysconfig/network-scripts/ifcfg-eth1 then this works
as expected in FC1.  That means that an interface with e100 driver
goes up and is configured as eth1.

On FC2 installation this is not the case.  I see in dmesg:
e100: Intel(R) PRO/100 Network Driver, 3.0.18
e100: Copyright(c) 1999-2004 Intel Corporation
divert: allocating divert_blk for eth0
e100: eth0: e100_probe: addr 0xfde00000, irq 19, MAC addr
sk98lin: Network Device Driver v6.23
(C)Copyright 1999-2004 Marvell(R).
divert: allocating divert_blk for eth1
eth1: 3Com Gigabit LOM (3C940)
      PrefPort:A  RlmtMode:Check Link State
Module sk98lin cannot be unloaded due to unsafe usage in
divert: freeing divert_blk for eth0
and I am screwed. sk98lin cannot be unloaded so straightening up
interfaces requires reboot.  That detail that eth0 and eth1
were defined as above is not taken into a consideration; and,
clearly, I do not want network interfaces to "wander" if I will
switch what happens to be active, or not, while booting.

Adding correct values of HWADDR in ifcfg-{eth0,eth1} does not change
that picture. The modules are loaded as above and the only effect
is that ifdown will now ignore interfaces as MACs are wrong.

The following line in /etc/modprobe.conf

install e100 /sbin/modprobe sk98lin && /sbin/modprobe -i e100

allows to work around the problem in this particular situation
although the following one

install eth1 /sbin/modprobe eth0 && /sbin/modprobe -i eth1

alas does not have any effect although one would hope that it will
be equivalent (and more general) with aliases defined as above.

On the top of that it does not look that there exists a good way to
provide "private" interface names using nameif, and skirt the issue
that way, without writing your own startup scripts to be executed
early enough.  There is in /sbin/ifup not documented

if [ -x /sbin/ifup-pre-local ]; then
    /sbin/ifup-pre-local ${CONFIG} $2

but this comes way after 'need_config ${CONFIG}' which calls
'get_hwaddr'.  This will load modules before we had a chance
to call nameif, presumably in ifup-pre-local, and we do not need
to bother with that anymore.  One can add modifications to
/sbin/ifup but this is not healthy for a long term maitenance.
Comment 1 Bill Nottingham 2004-06-29 00:05:52 EDT
Module sk98lin cannot be unloaded due to unsafe usage in

is the real source of the problem. Assigning to the kernel.
Comment 2 Michal Jaegermann 2004-06-29 11:24:25 EDT
Hm, if modprobe.conf would have corresponding 'install ...' lines
added automagically, say, then the problem would not have arise
in the first place does not matter what kernel does with modules.

And what about working hooks in initscripts and/or 'ifup' which
would allow to use 'nameif' without writing your own startup
additions?  Possibly simpler option: another "service" which runs
before 'network' if '/etc/mactab' is present.
Comment 3 Dave Jones 2005-04-16 01:12:57 EDT
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat.  The Fedora legacy project will be producing further kernel
updates for security problems only.

If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.

Thank you.

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