[SLE] Upgrading Kernel 2.2.13(i) -> 2.2.14(i)
Hi everyone, I've got an odd problem on my fileserver machine when I try to take it from a perfectly working self-rolled 2.2.13 kernel (with international patches in place), to 2.2.14 (with international patches in place). The problem is that on startup of the new 2.2.14 kernel, I get the system complaining that it can't load module "eth0", and the machine is thus unable to connect to my network. eth0 is a 3COM 3c59x, and loads as a module. Here's the steps I took: First, I made a place for the new source tree, extracted it, and cd /usr/src rm linux tar -xvf /pub/install/linuxsource/linux-2.2.14.tar mv linux linux-2.2.14 ln -s linux-2.2.14 linux Then, I copied in my .config file from my 2.2.13 source tree, and compiled the kernel: cd /usr/src/linux cp /usr/src/linux-2.2.13/.config . make dep make clean make bzImage So far, no problems... copy files, set up new lilo section to reference the new kernel, etc... cd /boot mkdir pentium-2.2.14-smp-scsi cd pentium-2.2.14-smp-scsi cp /usr/src/linux/arch/i386/boot/bzImage ./vmlinuz cp /usr/src/linux/System.map . cd .. cp /usr/src/linux/System.map . Then restart the system (shutdown -r now), and select the new 2.2.14 kernel (section 'test')... Once in, go back and compile the modules: cd /usr/src/linux make modules make modules_install depmod -aq Once again, restart... hutdown -r now And again, select the new 2.2.14 kernel to load when the lilo prompt comes up. And here's where I run into the problems. During boot, at the point where the system is attempting to get its address from the DHCP server running on another machine, I start seeing this error in the log: modprobe: modprobe can't locate module eth0 modprobe: modprobe can't locate module eth0 SIOCSIFADDR: No such device modprobe: modprobe can't locate module eth0 eth0: unknown interface: No such device modprobe: modprobe can't locate module eth0 eth0: unknown interface: No such device etc...etc... If I go back and reboot to 2.2.13, everything's fine. Anyone have any ideas what I'm doing wrong? I'm really confused by this. Argentium -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
On Thu, 23 Mar 2000, Argentium G. Tiger wrote:
The problem is that on startup of the new 2.2.14 kernel, I get the system complaining that it can't load module "eth0", and the machine is thus unable to connect to my network. eth0 is a 3COM 3c59x, and loads as a module.
What I did for 2.2.14 was to compile my eth0 driver as a module (tulip.o in my case) and then have a line in /etc/modules.conf that read: alias eth0 tulip That seemed to work fine. Very best, Buddy Coffey Advanced Electromagnetics -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
Chances are he has this alias if the configuration worked with 2.2.13.
Tiger: Do you have an alias for eth0 in /etc/conf.modules? Check by doing a
"grep -w eth0 /etc/conf.modules" (or modules.conf, whichever you have).
----- Original Message -----
From: "Buddy Coffey"
The problem is that on startup of the new 2.2.14 kernel, I get the system complaining that it can't load module "eth0", and the machine is thus unable to connect to my network. eth0 is a 3COM 3c59x, and loads as a module.
What I did for 2.2.14 was to compile my eth0 driver as a module (tulip.o in my case) and then have a line in /etc/modules.conf that read: alias eth0 tulip That seemed to work fine. Very best, Buddy Coffey Advanced Electromagnetics -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/ -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
On Fri, 24 Mar 2000, Argentium G. Tiger wrote:
Hi everyone, I've got an odd problem on my fileserver machine when I try to take it from a perfectly working self-rolled 2.2.13 kernel (with international patches in place), to 2.2.14 (with international patches in place).
The problem is that on startup of the new 2.2.14 kernel, I get the system complaining that it can't load module "eth0", and the machine is thus unable to connect to my network. eth0 is a 3COM 3c59x, and loads as a module. <snip>
My guess is the driver for the 3c509 is not SMP capable. I had this problem with the 3c905 in my workstation. Go to http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html and get the latest driver and check to see that is what you are compiling. (/usr/src/linux(or whatever)/drivers/net) This may be the problem. -- Bob F EMail FBob@wt.net A Truly Wise Man Never Plays Leapfrog With A Unicorn... -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
After you set up the section for the new kernel in lilo.conf and copied the
kernel, etc, did you run lilo?
Are we sure that the 3COM module is being built and put into the correct
home? Should be in /lib/modules/2.2.14/net; is it there?
I don't see anything funky with the steps you took although copying the
.config from 2.2.13 makes me nervous and the whole bzimage thing. If your
using LILO why not make zlilo? :P You wouldn't have to manually copy all
that crap around (image && System.map, etc) if you changed INSTALL_PATH in
the top level kernel makefile; anything to avoid possible human error is
good:
#
# INSTALL_PATH specifies where to place the updated kernel and system map
# images. Uncomment if you want to place them anywhere other than root.
INSTALL_PATH=/boot
(of course you must make any necessary changes to lilo.conf _before_ you do
make zlilo because the last step in a zlilo make is running lilo)
***
I'm curious to see what script is calling modeprobe and how it's calling it.
If modeprobe can't find a mod, the mod wasn't built or modprobe is being
told to look in the wrong place. Make sure the mod is actually where it
should be (/lib/modules/2.2.14/net/) and that modprobe is looking for it in
that place.
***
----- Original Message -----
From: "Argentium G. Tiger"
Problem solved. I did more research based on some excellent clues provided by Buddy Coffey, Keith Warno, and BobF. My thanks to you all. :-) Here's what seems to have gone wrong... my /etc/modules.conf was set up like so: alias eth0 3c90x This would work for 2.2.13, because there was a /lib/modules/2.2.13/net/3c90x.o file in existence. When I compiled for 2.2.14, the same .config file as I used for 2.2.13 generated "3c59x.o". Under the very latest Yast 1.03 (I updated it today from an FTP mirror) I can select under System Administration Integrate Hardware into System Configure Networking device either: "3c59x/3c90x" or "3c90x/3c980 B/C series" The former will configure "alias eth0 3c59x" in /etc/conf.modules, while the latter will configure "alias eth0 3c90x". I double-checked my card... It's a 3C905B... The correct setting is the 3c59x/3c90x setting (alias eth0 3c59x). Under 'make menuconfig', I have selected: Network device support ---> Ethernet (10 or 100Mbit) ---> [*] 3Com cards <M> 3c590/3c900 series (592/595/597) "Vortex/Boomerang" support This seems to correspond to the .config file's line: "CONFIG_VORTEX=m" In amongst all these options, I suspect that I had compiled the 3c90x.o driver at some point in the past when I was messing with many different types of 3Com cards. By this point (switching to 2.2.14), I had only the one card in the system. To sum all that up: Probably operator headspacing on my part. It's working beautifully again. Thanks again for the help folks! I'm going to bed... Argentium -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
Good job :>
When it comes to something as mission-critical and heavily used as an
ethernet card, yer best bet is probably to build the driver into the kernel,
unless you'll be poppin cards in and out on a frequent basis!
In any case, stay away from copying .config files between kernel versions.
=) As you can see it can create a headache!
Heh, now imagine you had to do all of this remotely. We have a box in VA,
roughly 3.5 hours from here, with that same dang 3COM 3c509b card in it.
The box was running a stock bloated 2.2.12 kernel and there was a need to
rebuild the thing just to remove some unnecessary crap (and to upgrade to
2.2.14); the build was done module-less. Using modules in this instance
would have been a Bad Thing to do, wouldn't ya say? :]
Ciao,
kw
/*
** Keith Warno
** Developer & Sys Admin
** http://www.HaggleWare.com/
*/
----- Original Message -----
From: "Argentium G. Tiger"
Good job :>
Thanks. :-)
When it comes to something as mission-critical and heavily used as an ethernet card, yer best bet is probably to build the driver into the kernel, unless you'll be poppin cards in and out on a frequent basis!
I left it modular, it seems to be working fine. I do see the wisdom in going monolithic for something like this (see below).
In any case, stay away from copying .config files between kernel versions. =) As you can see it can create a headache!
No kidding... I'm wondering if the "make oldconfig" I read about in the Kernel HOW-TO would allow for a more smooth creation of a new .config using settings in the old... Something to try out for the next kernel I guess... I also was under the impression that if a .config file didn't have an option, it would be added by a new kernel source-tree when I did a "make config" or "make menuconfig". Anyone know whether this is the case?
Heh, now imagine you had to do all of this remotely.
I got a taste of what that was like with this upgrade. I was lucky though, the box I was remotely upgrading was sitting in a closet a few feet away, not in a different state. It gave me a whole new appreciation for the perils of remote admin.
We have a box in VA, roughly 3.5 hours from here, with that same dang 3COM 3c509b card in it.
Er... Mine's a 3c905b... I hate 3com's numbering scheme - it lends itself to digit transposition problems.
The box was running a stock bloated 2.2.12 kernel and there was a need to rebuild the thing just to remove some unnecessary crap (and to upgrade to 2.2.14); the build was done module-less. Using modules in this instance would have been a Bad Thing to do, wouldn't ya say? :]
Agreed, though I'm others could make a case for the "modules are good" camp. My problem was pretty much confusion because "3c90x" appeared in two separate selections of networking hardware under YaST. The next things I want to look at are YP/NIS/NFS login authentication and file shares from the file server, and then SSH/SCP to replace telnet and ftp. More fun. :-) Take care, Argentium -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
% cat /proc/pci
[snip]
Bus 0, device 11, function 0:
Ethernet controller: 3Com 3C905B 100bTX (rev 48).
Medium devsel. IRQ 10. Master Capable. Latency=32. Min Gnt=10.Max
Lat=10.
I/O at 0xb000 [0xb001].
Non-prefetchable 32 bit memory at 0xe1800000 [0xe1800000].
[/snip]
Oh yeah. 3c905b. 'tis same card; Early morn' hours eh? Typo or three will
slip through :) An example of the "digit transposition problems" induced in
part by 3com's wacky numbering sceheme; all other parts induced by lack of
caffeine and/or sleep :P
Hmmm, can't say much for YP/NIS/et al but I'm pretty sure there's a bit o'
PAMming invovled. Yay fun! SSH should be a breeze relative to fighting
kernel tricks. Dunno if yer planning on running OpenSSH but I've personally
have seen poor perfomance from it.
Grab ssh from ftp.ssh.com , the "new master site for SSH Secure Shell
distribution" (used to be @ ftp.cs.hut.fi)
Ciao & good luck
kw
----- Original Message -----
From: "Argentium G. Tiger"
Good job :>
Thanks. :-)
When it comes to something as mission-critical and heavily used as an ethernet card, yer best bet is probably to build the driver into the kernel, unless you'll be poppin cards in and out on a frequent basis!
I left it modular, it seems to be working fine. I do see the wisdom in going monolithic for something like this (see below).
In any case, stay away from copying .config files between kernel versions. =) As you can see it can create a headache!
No kidding... I'm wondering if the "make oldconfig" I read about in the Kernel HOW-TO would allow for a more smooth creation of a new .config using settings in the old... Something to try out for the next kernel I guess... I also was under the impression that if a .config file didn't have an option, it would be added by a new kernel source-tree when I did a "make config" or "make menuconfig". Anyone know whether this is the case?
Heh, now imagine you had to do all of this remotely.
I got a taste of what that was like with this upgrade. I was lucky though, the box I was remotely upgrading was sitting in a closet a few feet away, not in a different state. It gave me a whole new appreciation for the perils of remote admin.
We have a box in VA, roughly 3.5 hours from here, with that same dang 3COM 3c509b card in it.
Er... Mine's a 3c905b... I hate 3com's numbering scheme - it lends itself to digit transposition problems.
The box was running a stock bloated 2.2.12 kernel and there was a need to rebuild the thing just to remove some unnecessary crap (and to upgrade to 2.2.14); the build was done module-less. Using modules in this instance would have been a Bad Thing to do, wouldn't ya say? :]
Agreed, though I'm others could make a case for the "modules are good" camp. My problem was pretty much confusion because "3c90x" appeared in two separate selections of networking hardware under YaST. The next things I want to look at are YP/NIS/NFS login authentication and file shares from the file server, and then SSH/SCP to replace telnet and ftp. More fun. :-) Take care, Argentium -- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/Support/Doku/FAQ/
participants (4)
-
agtiger＠coolnet.net -
bcoffey＠gemacs.com -
FBob＠wt.net -
keith＠HaggleWare.com