From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; de-DE; rv:0.9.2) Gecko/20010726 Netscape6/6.1 Description of problem: the scripts in /etc/rc.d/rc#.d start the program as follows: K03rhnsd K74ntpd S10network S25netfs S60lpd S95atd K20nfs K96irda S12syslog S26apmd S80sendmail S99local K20rwhod S05kudzu S13portmap S28autofs S85gpm K46radvd S08ipchains S14nfslock S45pcmcia S90crond K50snmpd S08iptables S17keytable S56rawdevices S90xfs K65identd S09isdn S20random S56xinetd S95anacron This means, that NIC in pcmcia will be started as #45. The problem is, that many script before 45 need a working network: S12syslog (@ notation) S25netfs (NFS filesystems) S28autofs (maps from NIS or LDAP) .. maybe more? So I would suggest, that you move S45pcmcia to S11pcmcia, right _after_ S10network. So you still "delay" eth initialisation in case of pcmcia, but the network will be running for all subsequent services. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot with pcmcia NIC 2. use autofs with LDAP or NIS maps Actual Results: autofs says "No mountpoints defined" Expected Results: autofs should use mount points defined in LDAP (which it cannot, because the network is not yet activated). Additional info: This bug has caused many similar bug reports in bugzilla where users of several other components (e.g. autofs) complain about various problem with their component. These are often results of the late network initialisation with pcmcia.
This is really not a bug. Nothing in the boot sequence should depend on PCMCIA devices being configured first, as there is no reason to expect a PCMCIA device to even be present at boot time. Moving the script doesn't even solve the problem. Because cards are only powered up once the PCMCIA initialization script runs, it may take several seconds for cards to be initialized and identified, the correct drivers loaded, network interfaces to autonegotiate link speed, etc. So running other scripts that assume a working network will give unpredictable results. -- Dave Hinds
First of all, this bug report is quite old and corresponds to RH 7.2. At least in 8.0 they fixed the thing by moving PCMCIA to #24 which solves all the mentioned problems (except "@" in syslog). But Dave is also right, the cardmgr, and drivers need some time, so that is is not guaranteed, that you get a working pcmcia network when ending /etc/init.d/pcmcia. I solved this problem by inserting a "sleep" at the end of /etc/init.d/pcmcia to give the system some time to initialize. Dave, you say, that nothing in the boot sequence should depend on pcmcia. Well, how do you suggest to initialize a system with a NIC in pcmcia? What would you change? Till