Bug 11941 - Network installation succeeds, yet no network connectivity after reboot
Network installation succeeds, yet no network connectivity after reboot
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: distribution (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-07 04:45 EDT by Rabbe Fogelholm
Modified: 2014-03-16 22:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-01 15:40:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
original after-install /etc/sysconfig/network-scripts/ifcfg-eth0 (41 bytes, text/plain)
2000-06-28 10:56 EDT, Rabbe Fogelholm
no flags Details
Trace of failed ifup call `sh -x ifup eth0' (1.02 KB, text/plain)
2000-06-28 11:00 EDT, Rabbe Fogelholm
no flags Details

  None (edit)
Description Rabbe Fogelholm 2000-06-07 04:45:22 EDT
Hi RedHat,

I have always been impressed by the smoothness of the RedHat
installation procedure for Linux. However, yesterday I had
problems with the installation of RedHat 6.2 onto a particular
machine. I will describe it here in hopes that you can find
a way to solve it in future releases of RedHat.

Some background information: The machine is a Dell Latitude
XPi P133 with 40 MB RAM and 2 GB of disk available for Linux.
This machine is a laptop with 2 PCMCIA slots. There is also
an optional docking station that contains an Ethernet NIC that
plugs into the ISA bus of the laptop.

I chose to go for the docked configuration, as I wanted to 
make use of the NIC in the docking station.

There is no CD-ROM reader in the machine, so I attempted a
network installation starting from a bootnet.img diskette. 
Workstations on my network are assumed to use DHCP, so I 
specified that in the initial dialogue. Furthermore I directed 
the installation to fetch the software from a nearby anon-FTP 
server.

The installation was a breeze once started, and completed in 
an hour or so. After rebooting there was a problem, though.

DESCRIPTION OF THE PROBLEM: Having rebooted after the completed
installation I had no IP connectivity. Checking with `ipconfig' 
I found that there was no eth0 interface listed.

After some help from a local guru we concluded that the 
installation had set up almost all the necessary configuration 
information. When looking at the parameters as they are 
presented in `linuxconf' everything was set for DHCP usage, 
including things like nameserver IP addresses collected by DHCP 
in the installation phase. We then found that if we added a 
kernel module specification (3c509, which is the closest match 
to the NIC in the docking station) in Linuxconf and rebooted, 
the IP networking came up cleanly.

Conclusion: The installation procedure should insert the 
required kernel module for the NIC, since this information is 
figured out automatically early on during the installation.

Just speculating, as I have never encountered this problem 
before it seems to me that this is indeed usually done. Perhaps 
the fact that this machine has both a conventional NIC (in the 
docking station) and a PCMCIA bay confuses the installer.

--Rabbe Fogelholm, Sollentuna, Sweden
Comment 1 Brock Organ 2000-06-09 22:58:19 EDT
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 ***
Comment 2 Rabbe Fogelholm 2000-06-15 04:09:29 EDT
Hi borgan@redhat.com,

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
Comment 3 Brock Organ 2000-06-23 13:34:26 EDT
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')
Comment 4 Rabbe Fogelholm 2000-06-28 10:56:36 EDT
Created attachment 800 [details]
original after-install /etc/sysconfig/network-scripts/ifcfg-eth0
Comment 5 Rabbe Fogelholm 2000-06-28 11:00:35 EDT
Created attachment 801 [details]
Trace of failed ifup call `sh -x ifup eth0'
Comment 6 Brock Organ 2000-06-28 17:05:49 EDT
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
...
Comment 7 Rabbe Fogelholm 2000-08-07 07:49:28 EDT
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@redhat.com>
> To: Rabbe Fogelholm <eubrafo@operamail.com>
> Subject: Re: #11941
> In-Reply-To: <3971E085@operamail.com>
> 
> 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
Comment 8 Brock Organ 2000-08-31 16:43:22 EDT
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 ...
Comment 9 Rabbe Fogelholm 2000-08-31 18:05:02 EDT
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.
Comment 10 Michael Fulbright 2001-09-14 12:42:22 EDT
Sounds like a kudzu/distribution issue.
Comment 11 Alan Cox 2002-12-14 18:54:12 EST
Kudzu gets this right on the laptop docks I can test, except for hotdock which
obviously it cant deal with.
Comment 12 Bill Nottingham 2005-03-01 15:40:28 EST
Closing based on previous comments.

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