Bug 59009 - incorrect ordering of network and PCMCIA restart when resume?
incorrect ordering of network and PCMCIA restart when resume?
Product: Red Hat Raw Hide
Classification: Retired
Component: apmd (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2002-01-29 01:54 EST by Fortepianissimo
Modified: 2007-04-18 12:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-29 01:59:55 EST
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 Fortepianissimo 2002-01-29 01:54:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20020117

Description of problem:
In /etc/sysconfig/apm-scripts/apmscript network is after PCMCIA. This causes
net.agent (hotplug) to start network interface if a PCMCIA network card exists,
and the first unused interface (eth0) would be grabbed. If in the normal usage
the PCMCIA network card is configured as interface other than eth0 (e.g., eth1),
this will cause the wrong interface configuration being used.

Also I suspect that this ordering would cause various interface scripts to be
executed more than one time? (e.g. /sbin/ifup-local if one exists)

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

How reproducible:

Steps to Reproduce:
1. set both NET_RESTART and PCMCIARESTART to yes in /etc/sysconfig/apmd.
2. create a user-supplied /sbin/ifup*-local or /sbin/ifdown*-local scripts.
3. have a PCMCIA network card installed as eth1 and inserted.
4. suspend the machine and resume it.

Actual Results:  eth1 is never up.

Expected Results:  eth1 should be up okay (and if other interfaces are up at the
time of suspend they should be up too).

Additional info:
Comment 1 Fortepianissimo 2002-01-29 01:59:50 EST
well step 2 strictly is not required to reproduce the wrong-interface problem.
Comment 2 Bernhard Rosenkraenzer 2002-02-26 12:16:34 EST
 Fixed in 3.0.2-6

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