Bug 22979 - RFE: pcmcia interfaces
Summary: RFE: pcmcia interfaces
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Whiteboard: Florence Beta-3
Depends On:
TreeView+ depends on / blocked
Reported: 2000-12-29 11:22 UTC by Gerald Teschl
Modified: 2014-03-17 02:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-05-18 23:15:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Gerald Teschl 2000-12-29 11:22:47 UTC
Many people are annoyed by the "Bringing up interface eth0: [Failed]"  on
boot for
pcmcia cards (since pcmcia is started after network). For some reasons
(which I
don't really understand) redhat does not want to change this ordering.
Hence I
propose a simple fix for this problem below. With this small patch you just
"PCMCIA=yes" into ifcfg-eth? if it is a PCMCIA device and the network
script will
only bring it up if pcmcia is already started.

--- network.orig        Fri Dec 29 12:08:04 2000
+++ network     Fri Dec 29 12:18:27 2000
@@ -58,10 +58,12 @@
        for i in $interfaces; do
-               if egrep -L "^ONBOOT=\"?[Nn][Oo]\"?" ifcfg-$i >/dev/null
2>&1; then
+               if egrep -q "^ONBOOT=\"?[Nn][Oo]\"?" ifcfg-$i; then
                        # Probe module to preserve interface ordering
                        /sbin/ifconfig $i >/dev/null 2>&1
+                       egrep -q "^PCMCIA=\"?[Yy][Ee][Ss]\"?" ifcfg-$i &&\
+                               [ ! -f /var/lock/subsys/pcmcia ] &&
                        action "Bringing up interface $i: " ./ifup $i boot

Comment 1 Bill Nottingham 2001-01-10 20:39:55 UTC
We can do this, but it won't help much unless the installer writes them.

Comment 2 Matt Wilson 2001-01-10 20:43:46 UTC
There's no real way to know what driver arbitrary eth devices are controlled
by.  The installer only knows that "there is an eth0 device" not that it is
controlled via PCMCIA.

Comment 3 Erik Troan 2001-01-10 22:41:24 UTC
Not actually true -- as long as they use the pcmcia install disks, the loader
keeps track of what's pcmcia and what isn't.

For 7.0, we set ONBOOT=no for PCMCIA devices to work around this though, iirc.
Is that not working?

Comment 4 Glen Foster 2001-01-11 21:15:08 UTC
This defect is considered MUST-FIX for Florence Gold release

Comment 5 Bill Nottingham 2001-01-15 16:49:48 UTC
Reporter: does setting 'ONBOOT=no' also solve your problem? (It won't
break anything; pcmcia-cs ignores ONBOOT...

Comment 6 Gerald Teschl 2001-01-16 13:21:29 UTC
Setting ONBOOT=no would also solve the problem, but I don't think its a clean
In fact, I think inserting a card could be considered "booting" it and hence
should bring the if up with the "boot" option. This way the user could control
whether the
card should be brought up upon insertion.

Comment 7 Bill Nottingham 2001-01-16 16:43:45 UTC
That would have to be done in the pcmcia package.

However, please note that the way the cards are currently configured,
you will *not* get this message.

Comment 8 Bill Nottingham 2001-01-16 18:37:09 UTC
After discussing this with the local pcmcia-cs maintainer, doing it
in this manner (suddenly honoring ONBOOT for pcmcia devices) would
totally break upgrades. So we're going to stick with the current
behavior for now.

Comment 9 Gerald Teschl 2001-01-17 18:09:31 UTC
Yes, I don't get the failed message anymore. But know the card isn't brought up
when the
laptop wakes up from suspend;-(

Comment 10 Gerald Teschl 2001-05-15 08:37:44 UTC
Setting ONBOOT="no" has the effect of breaking apm suspend/resume, since
"service network start" will NOT bring up a pcmcia interface in this case.

See bug #34632.

Comment 11 Arjan van de Ven 2001-05-18 23:15:09 UTC
Which card ?

Comment 12 Bill Nottingham 2001-08-07 07:13:38 UTC
This should be worked around in initscripts-6.12-1, in that the message is no
longer printed (the interface is just skipped...)

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