Bug 47529 - PCMCIA ethernet devices ALWAYS ifup'd at boot time
Summary: PCMCIA ethernet devices ALWAYS ifup'd at boot time
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel-pcmcia-cs   
(Show other bugs)
Version: 8.0
Hardware: All Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-07-05 23:24 UTC by Dax Kelson
Modified: 2015-01-04 22:01 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-25 08:06:02 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 Dax Kelson 2001-07-05 23:24:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/8.51 [en] (X12; U; Linux 5.2.12-4 i986)

Description of problem:
With PCI/ISA network cards, you can control if you want the device
activated (via ifup) at boot time.  This was also true with PCMCIA cards
with all Red Hat versions through 7.0.

Now with 7.1, PCMCIA cards are always "ifup'd" at boot time.  This lack of
control, feature removal, and behavior change is annoying on many levels.  

Real world example:
My laptop gets plugged into many different networks.   Those networks may
or may not being using DHCP, those networks are often using the "same"
private RFC1918 address space.  I don't want my ethernet card coming up
automatically and potentially causing the network grief.

How reproducible:

Steps to Reproduce:
1.  Turn on laptop that has PCMCIA ethernet
2.  The card will be "ifup'd" during the boot up process

Additional info:

Previously PCI, ISA, and PCMCIA ethernet devices all respected the value
"ONBOOT" in a /etc/sysconfig/network-scripts/ifcfg-ethX file.  This was a
good thing.   

Now PCMCIA ethernet devices ignore "ONBOOT".

The logical thing to do would be to restore PCMCIA's respect for that
option, because as much as possible ethernet devices should be configured 
and treated the same regardless of how they are attached. 

One other related question remains, and that is what should happen when you
insert the card after the system has booted?  

For the ultimate in control, you could seperate and configure "boot time"
"after boot  you insert card" each independently.  I would argue against
I think both cases should be treated the same.

Comment 1 Arjan van de Ven 2001-07-06 09:06:32 UTC
I agree that if the card is plugged in before booting, it should honor 
the ONBOOT. I will try to figure a way on how to do this, the tricky part
indeed is what to do when someone inserts a card later on. Currently,
it's hard to make a distinction between those events (the on boot case pretends
to be a card insertion)

Comment 2 Matthew Saltzman 2002-05-13 03:37:22 UTC
The confounding of boot and card insertion doesn't seem to me to be such a bad
thing.  If ONBOOT=no, then booting or inserting the card doesn't start the
interface and it has to be started manually.  If ONBOOT=yes, then booting or
inserting the card starts the interface automatically.

This seems less annoying to me (with a laptop that may not be connected to a
network at boot or card insertion) than having no control whatsoever.

Consider the following example:  You have a modem/ethernet combo card.  You
insert it to use the modem.  Under the current regime, the ether interface will
attempt to start even if not connected.

In my case, I have a built-in ethernet and a pc-card wireless.  The wireless
interface always attempts to start on boot, even if the ethernet is connected. 
If I'm near my WAP, then I end up with both interfaces running, when I may
really only want the (faster) ethernet.

Comment 3 Matthew Saltzman 2002-05-13 04:00:20 UTC
BTW, this is still the behavior in 7.3.  Can the version number be updated somehow?

Comment 4 Matthew Saltzman 2002-12-02 00:07:16 UTC
Just saw the update to 7.3.  FYI, it happens in 8.0 too.

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