|Summary:||network script starts BEFORE pcmcia by default|
|Product:||[Retired] Red Hat Linux||Reporter:||steph|
|Component:||kernel-pcmcia-cs||Assignee:||Arjan van de Ven <arjanv>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Version:||7.1||CC:||cunha17, jalar, pekkas|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 18:48:01 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description steph 2001-06-11 22:36:28 UTC
From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686) Description of problem: The /etc/init.d/network script is named S10network in /etc/rc#.d (where # is 2-5), which means it will start after the S20pcmcia script. This isn't very helpful for pcmcia network cards. How reproducible: Always Steps to Reproduce: 1. Install RH 7.1 on laptop with pcmcia network card 2. Boot Actual Results: 3. notice that network card initialization fails because pcmcia has not started yet Expected Results: the network script should be linked to with S24network (or any number higher than S20 for pcmcia) so that the network initialization on boot does not fail Additional info:
Comment 1 Jeff Johnson 2001-06-15 20:31:29 UTC
intimed has been removed from Red Hat 7.x. Try using xntpd or ntpd, it does a far better job keeping time accurate, and is started at S26, not S10 in Red Hat 7.x
Comment 2 steph 2001-06-15 21:11:25 UTC
I chose the component initmed because I didn't see anything applicable - and I figured someone there would be better able to chose the appropriate component. I've just taken a bit more time looking, and found a component for initscripts. I've changed the component to initscipts, as the bug is valid. Please read the bug report - this has nothing to do with time or NTP. This is a misconfiguration of the startup scripts by default with RH 7.1. I apologize if chosing the wrong component has caused some confusion, but just reading the bug report should be enough to show that perhaps you should change the component instead of closing as won't fix.
Comment 3 Bill Nottingham 2001-06-18 02:23:14 UTC
the network script is *not* moving (it needs to be at that location). assigning to kernel-pcmcia-cs. Note that pcmcia interfaces will be brought up anyway on boot with the current setup.
Comment 4 Arjan van de Ven 2001-06-18 08:01:43 UTC
What networkcard (pcmcia wise) do you have ? This works for me
Comment 5 steph 2001-06-18 16:24:46 UTC
I'm using a Xircom RealPort II on a Sony VAIO PCG-F450. Modem works, network card works - when I change the init order to allow pcmcia to start before network. If this is not done, and left as default, I receive a FAILED message on boot for starting network, then pcmcia is started, then I have to manually restart network script from command line. I may be wrong, but I thought this was because pcmcia is S20 and network is S10 on default install. If changing the order of the network script isn't an option, perhaps changing the order of the pcmcia should be looked at. If this is incorrect, please let me know.
Comment 6 Curtis Doty 2001-06-24 02:03:42 UTC
I had same symptom on micron notebook with pcmcia network card and modem. Dunno why this is a new bug, but it looks like--when booting directly to runlevel 5-- redhat loads kudzu before network before pcmcia. Here's the hack that worked for me. Basically, load pcmcia (S20->S04) before kudzu (S05) and network (S10). --- pcmcia-3.1.24-2 Sun Mar 11 13:25:42 2001 +++ pcmcia Sat Jun 23 18:17:23 2001 @@ -7,7 +7,7 @@ # Tags for Red Hat init configuration tools # -# chkconfig: 2345 20 96 +# chkconfig: 2345 04 96 # processname: cardmgr # pidfile: /var/run/cardmgr.pid # config: /etc/pcmcia/config On this notebook, NIC is 3Com 3CXFE575BT (3c59x) and modem is MHz XJ5560. Good news is--even though this notebook used to run mandrake 7.2 happily--it choked and died under mandrake 8.0, and with above hack (and manual sb config), runs beautifully under redhat 7.1. ../C
Comment 7 Arjan van de Ven 2001-06-25 06:38:55 UTC
I'll start a discussion with the maintainers of the other scripts to see what's best to be done about this.
Comment 8 Pekka Savola 2001-08-16 13:28:36 UTC
if you set ONBOOT=no, then you don't see the failed message. The network is still brought up at boot when you run when init.d/pcmcia is started. As a smaller feature change, I'd suggest moving pcmcia right after network or syslog (for logging). Why? Because there are several network services starting between them, like: portmap, nfslock, netfs, ntpd, ypbind, autofs, nscd, identd And starting these may fail completely/generate dns lookup timeouts if network isn't set up yet.
Comment 9 Bill Nottingham 2001-08-16 15:03:31 UTC
Acutally, in the current initscripts, you shouldn't see the message anyway. But if we move the pcmcia initscript as you suggest, what if you want to run the pcmcia daemon off your NFS mounted filesystem? :)
Comment 10 Pekka Savola 2001-08-16 15:52:32 UTC
Which pcmcia daemon? Kernel-pcmcia-cs which -- I hope -- has about all the stuff needed for setting up pcmcia cards (and after that, network), it storing the binaries in /sbin/. Only man pages in /usr, so I can't see which would prevent this? (.. good old NFS or NFS /usr ro and friends are always giving the headache eh :-)
Comment 12 Jean-Charles Preaux 2003-07-25 11:15:14 UTC
on my GNU/Linux RedHat 9.0 laptop, i rename S24pcmcia on S09pcmcia in the following directories : /etc/rc.d/rc2.d /etc/rc.d/rc3.d /etc/rc.d/rc4.d /etc/rc.d/rc5.d and everything is good at the reboot :)
Comment 13 Bill Nottingham 2004-03-12 19:14:55 UTC
*** Bug 118134 has been marked as a duplicate of this bug. ***
Comment 14 Cristiano Duarte 2004-03-14 20:40:22 UTC
The problem I'm experiencing is that the pcmcia init script doesn't wait for DHCP configuration. It waits in the background, so other services that depend on the IP address fail, because there is no IP configured yet. Maybe the script should run in the foreground until the DHCP configuration. The other solution I got is the same as Jean-Charles Preaux, change the pcmcia script sequence to 09 instead of 24.
Comment 15 Brian Kendig 2004-05-30 00:36:04 UTC
This problem exists in Fedora Core 2 as well. The workaround provided above by Jean-Charles Preaux fixes the problem.
Comment 16 Bill Nottingham 2004-09-08 07:00:41 UTC
*** This bug has been marked as a duplicate of 125250 ***
Comment 17 Red Hat Bugzilla 2006-02-21 18:48:01 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.