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
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.