Bug 11941

after reboot, when your ifconfig command shows only the lo (loopback) device
running, try 

% ifup eth0

that may bring up your networking successfully ... (see bug 10507 for more
details) ... we are working to fix that problem in a future release ... please
let me know if this helps ...

thanks for your report!

*** This bug has been marked as a duplicate of 10507 ***

Hi borgan,

in my opinion 11941 is not yet resolved, since it is *not* a duplicate of 10507.

As I understand it 10507 is about laptops with a PCMCIA slot, where the system 
tries to start the PCMCIA NIC too early. This is a cosmetic bug; the system 
comes up with network connectivity eventually. Checking my laptops I actually 
saw this behaviour in one of them.

This report (11941) describes a situation where the newly installed system 
definitely fails to start the NIC after an otherwise successful network 
installation. It is probably a rather infrequently occurring situation, since 
the hardware setup is a bit unusual.

Please see the original description for details. Especially note that although 
this machine does have a PCMCIA slot I did *not* use it during the network 
installation, and do not intend to use it further on either. What I actually use 
is the ISA NIC in the permanently attached docking unit.

I have now repeated the installation, in order to have a virgin system for 
locating the problem.

Some further observations:

Action: type `ifconfig'
Response: Only the lo device reported

Action: type `ifup eth0'
Response: "Delaying eth0 initialization"

Action: re-type `ifconfig'
Response: Only the lo device reported

Action: Run linuxconf in console mode,
  specify 3c509 as kernel module in
  Config->Networking->Clienttasks->BasicHostInfo

Action: re-type `ifconfig'
Response: eth0 device reported now

Action: try to ping a nearby host
Response: Successful ping response now

I tried to pinpoint what the linuxconf operation really does by tarring the 
/etc/sysconfig directory before and after the linuxconf session. The only file 
affected in that file tree seems to be 
/etc/sysconfig/network-scripts/ifcfg-eth0. It grows from 5 to 17 lines, the 
added lines dealing with IPX as far as I can see.

Another change, probably effected by linuxconf, is that `lsmod' reports the 
3c509 module afterwards (I didn't think of checking this before doing 
`linuxconf').

I will keep this system in its almost virgin state for a while in case you would 
like me to check out something more.

--Rabbe Fogelholm, Sollentuna, Sweden

ok, Rabbe, let's try to track this down further ... :)

could you attach your original after-install
/etc/sysconfig/network-scripts/ifcfg-eth0 ...?  (and you may also try attaching
a trace of the failed ifup call ie '% sh -x ifup eth0 2>&1 | tee log.txt')

Created attachment 800 [details]
original after-install /etc/sysconfig/network-scripts/ifcfg-eth0

Created attachment 801 [details]
Trace of failed ifup call `sh -x ifup eth0'

a quick look at the differences between the ifup eth0 commands (working vs
non-working) shows the ifconfig eth0 command fails in the non-working version: 

WORKING OUTPUT						NON-WORKING OUTPUT DIFF
+ OTHERSCRIPT=/etc/sysconfig/network-scripts/ifup-eth         (                 
+ [ -x /etc/sysconfig/network-scripts/ifup-eth ]              (                 
+ /sbin/ifconfig eth0                                         (                 
+ grep -s not found                                           (                 
+ [ 1 = 0 ]                                                   | + [ 0 = 0 ]     
+ [  = yes -a no = no -a  !=  -a -x /sbin/ifenslave ]         | + echo Delaying
eth0 initialization.                                                            
+ [ -n  ]                                                     | Delaying eth0
initialization.     
+ [ -n true ]                                                 | + exit 1        
+ PUMPARGS=                                                   <                 
+ [ -n  ]                                                     <     

The next step will be to verify the card manager & kernel are on the same page
...

Hi Brock,

sorry to have taken this long to answer. Anyway, my Dell
P133 laptop (the one that exhibits the #11941 problem) has
had a nice long rest, and here is how it behaves when I boot
it up:

[root@upl1489 /root]# /etc/rc.d/init.d/pcmcia status
cardmgr (pid 437) is running...
[root@upl1489 /root]# ifconfig eth0 up ; echo $?
eth0: unknown interface: No such device
255
[root@upl1489 /root]# cardctl status
Socket 0:
  no card
Socket 1:
  no card
[root@upl1489 /root]# cardctl ident
Socket 0:
  no product info available
Socket 0:
  no product info available

This is all quite reasonable, since there is no PCMCIA card
in the machine (the FTP-based install was done through the
NIC in the docking station, which does not use the PCMCIA
slots).


> Date: Thu, 29 Jun 2000 11:07:11 -0400 (EDT)
> From: Brock Organ <borgan>
> To: Rabbe Fogelholm <eubrafo>
> Subject: Re: #11941
> In-Reply-To: <3971E085>
> 
> Rabbe,
> 
> The 'sh -x ifup eth0' log you attached is exactly what I get in test when
> I didn't have the card in the pcmcia slot ... so I am wondering if your
> card manager is properly recognizing your devices ...
> 
> Using the below sequence of commands just after boot, do you get similar
> responses ...?
> 
> [root@test /root]# /etc/rc.d/init.d/pcmcia status
> cardmgr (pid 381) is running...
> [root@test /root]# ifconfig eth0 up ; echo $?
> 0
> [root@test /root]# cardctl status
> Socket 0:
> 5V 16-bit PC Card
> function 0: [ready], [bat dead], [bat low]
> Socket 1:
> no card
> [root@test /root]# cardctl ident Socket 0:
> product info: "Xircom", "CreditCard Ethernet 10/100 + Modem 56",
> "CEM56", "1.00"
> manfid: 0x0105, 0x110a
> function: 2 (serial)
> Socket 1:
> no product info available

Rabbe,

Thanks for your update ... my apologies, I did not realize that you were using
the NIC in your docking station, I just assumed you only had a PCMCIA NIC ... :( 

There are known issues with using the NIC in a docking station, (since it
appears as a regular PCI card even though it isn't!), so in general you may
experience difficulties with the docking station NIC for various
plug/unplug/hotplug scenarios ... 

We will defer this to a future release ...

Fair enough .. my particular combination of laptop and docking station is not
likely to be used a lot anyway, and there is a simple workaround that I can use.
Bye for now & keep up the good work.

Sounds like a kudzu/distribution issue.

Kudzu gets this right on the laptop docks I can test, except for hotdock which
obviously it cant deal with.

Closing based on previous comments.