Traduisez - Übersetzen - Traduzca - Traduza - Tradurre - Translate

Re: Kernel compile problems with RH 5.1

csd@netbox.com
Tue, 16 Jun 1998 07:59:04 -0700 (PDT)

Your problem is that the kernel keeps the modules in a directory which is
unique to each version number, but the moment you did a make modules_install
with your new kernel image, you overwrote the modules that were installed with
the vanilla kernel from redhat (/lib/modules/<kernel-version-number> is were
the modules are installed for any version number). If you want to back off into
the vanilla version, you'll have to reinstall the kernel-modules rpm. Note that
you can't have 2 sets of modules for 2 images with the version number (this is
the default behaviour, do a "man depmod" if you want to change this).
That answers why your original 2.0.34 stopped working after installing the new
set of modules. Why your newly compiled 2.0.34 didn't work I can only guess. I
would think that since there are 2 separate rpms for the kernel, one for the
image and one for the source tree, they don't necessarily have the same default
configuration. You might want to check the SRPM for the kernel image and take a
look at the .config file in there, which is where linux keeps all of the
configuration for the kernel compilation (possibly copying that into your
/usr/linux directory and then tweaking the configuration from there). But this
is only a guess, I haven't used kernel source RPMs.
I have no idea why your 2.0.32 stopped working properly, its modules are in a
separate directory altogether (try running "depmod -a" after booting into it).
You might even want to try to run "depmod -a" with your new kernel image, I
don't know what RedHat has been doing with their rc files lately, but if it
isn't in there already you really need to run it after rebooting into a new
kernel (this command recreates the module dependency information for kernel
auto-loads).

CSD

> I've just upgraded a system from RedHat 5.0 to 5.1 so I could read the
> FAT32 fs in a Win95 partition. In case anyone doesn't know, RH 5.1 uses
> kernel 2.0.34-6. The out-of-the-box kernel seemed to work fine. I
> could mount both vfat and fat32 partitions and view the files therein,
> and the networking was working just fine -- So I continued on with my
> (re)configurations. xcdroast is used on this system for burning cds, so
> I had to recompile the kernel to use SCSI host adapter emulation for the
> ATAPI cdroms. This is where the trouble started.
>
> I cd'd to /usr/src/linux and did a make xconfig, and chose the scsi
> emulation and generic scsi support, as well as tweaking a couple of
> minor things (CPU to Pentium, get rid of other unneeded things like
> busmice, non IDE or SCSI cdroms, etc.) I saved, exited, and did a make
> dep; make clean, then a make zImage. Everything progressed without
> errors.
>
> I copied the new zImage over to /boot, renamed it, edited my lilo.conf,
> and re-ran lilo. So I now have a choice of 3 kernels to boot from: the
> box 2.0.34, the 2.0.34-scsi emulation, and the old 2.0.32 with scsi
> emulation from when the system was 5.0.
>
> When I rebooted with the 2.0.34-scsi kernel, the SCSI/ATAPI devices were
> detected properly, but some other problems developed. First, it
> wouldn't mount the Win95 partitions or my cdroms. I got the errors:
> mount: fs type vfat not supported by kernel
> mount: fs type iso9660 not supported by kernel
>
> Almost as bad, the networking is not working. I can't ping anything,
> either behind or outside of my firewall - even though the Tulip card is
> detected at boot. So it looks like the kernel wasn't loading in any of
> the modules.
>
> I thought I might have made a mistake during the make xconfig, so I went
> through it again, this time compiling in support for both the vfat and
> iso9660 filesystems into the kernel, making sure loadable module support
> was enabled and then I copied over and replaced the appropriate kernel.
> After reboot, the same problems continued - couldn't mount vfat or iso
> fses and no networking. So it looked like the kernel still wasn't
> loading in the modules.
>
> Confused, I looked at the RH 5.0 manual (of which I have a copy) and
> looked into its kernel building instructions. It said there that I
> should build any modules I configured with make modules
> - I wasn't sure if I had configured any modules, but I figured the worst
> it would do is make a default set, so I did that. It also said I should
> install the new modules (even if I didn't build any) with
> make modules_install.
> I did this as well.
>
> This time the new kernel would not boot at all - I hadn't done anything
> to this kernel, since the module instructions in the RH manual instruct
> to do the make modules and make modules_install after the kernel image
> is made. I booted the old kernel - and now both vfat or iso filesystems
> cannot be mounted, and give the same 'not supported' error. I also
> booted my orignal kernel with SCSI emulation that I used with the system
> when it was RH 5.0. It gives the same errors, and networking is down as
> well.
>
> I think this problem is due to my extreme ignorance on kernel matters,
> and my failure to build a proper kernel and module set. The funny thing
> is - the first time I rebuilt the kernel for scsi emulation, I did not
> have these sorts of problems - once I was able to get the kernel
> compiled. If anyone can give me some help on these difficulties, I
> would appreciate it.
>
> Emailed replies would be especially appreciated.
> --
> Your faithful narrator,
> Roberto Pavan, rpavan@physics.ubc.ca
>
> If a birth is the fall-out from the explosion caused by the union of
> two unstable elements, then perhaps a half-life is all we can expect.
> -- Salman Rushdie, "The Moor's Last Sigh"
>