kernel comp questions w/ seperate modules??
 

hello.

in the past i have had no trouble compiling a new kernel using :

make dep ; make bzImage ; make modules ; make modules_install
and then moving the image to /boot

however, i am now having trouble. whenever i try to compile a new kernel, i get mad insmod errors when rebooting, from both the old and new kernel.

someone had told me that in order to have them coexist, each kernel must have its own modules and modules directory. can someone point me to the direction on how to do this so i will have no more problems trying to compile the kernel? is there anything else?

also, i have never been too sure of the /boot/System.map file, as well as the /vmlinuz file. when compiling kernels a year ago, i never touched these files, i just simply moved the newly compile bzImage to boot, added to lilo, and voila.

can someone describe to me how i can get this to work?

peace,
univerz.

Hi neoninja

Check out the Makefile in /usr/src/linux. Add an "extraversion" each time you compile a kernel and modules. I usually rename the System.map and the bzImage so that they have the same suffix, e.g. bzImage-2.4.22 and System.map-2.4.22.

Where is make clean and make mrproper? Did you forget to type them or did you forget to use them?

The make files should create the proper directories in /lib for each set of modules for each kernel. But the "source tree" has to be cleaned up between every kernel compilation. Else, there is a mess. That is what the make clean does, it cleans everything up so that the directories are empty in preparation for the new modules and kernel in the source "tree".

I think, but am not sure, that the make mrproper forces the creation of new target directories in /lib. This insures that each kernel has a full set of custom modules made specifically for it, in their own directory--using the full kernel name. If you are building the same kernel a second time, with different settings, you are supposed to imcrement the last number or give it a different build-name.

It's late, and I'm going to bed. Read the kernel docs. They will tell you better than I can.

I am going to try to answer your question. I use redhat linux but the methods of install should be the same. Typicallly this is what i do, i detar the source to my /usr/src there should already be a directory there for the kernel you are currntly booting in "linux2.4" with the source code. I then run my config and pick my options. One being "module support" seeing you want to use them (just sanity check). Then I actually run a make clean make dep ; make bzImage ; make modules. I usually run a make modlues_install and install after that is done. Depending on the bootloader I use grub cause its prety easy. With redhat I dont have to touch anything else other than the grub.conf. and add the new kernel entry as the default. Are you using lilo? Hopefully this helps a bit.

When I used lilo, I ran lilo before booting to the new kernel. (It doesn't hurt anything, and I did have an install that didn't run it, so the new kernel wasn't an option on the boot list.)

With grub, I found that everything had been updated properly every time I have updated the kernel even when I used up2date. (That's RH specific.)

I looked everything up and found out something that makes me look stupid once again. ( I consider SuSE to be an unimpeachable source of linux information.) http://www.google.com/linux "make mrproper" The results:


Also check the FAQ at http://www.suse.com/support/faq and the
archives at http://lists.suse.com

On Wed, 4 Jul 2001, Rafael Herrera wrote:

rh> 'mrproper' leaves your sources as you got them when you unpacked the
rh> sources.
rh>

This will also remove your .config file, this is the file that contains
all your kernel configuration options for what to compile into the kernel
or as modules. So if you've spent alot of time coming up with the perfect
configuration for you system, save the file to another directory before
running mrproper.

rh> 'clean' deletes all the binary objects and a few other files, but leaves
rh> others, like the .depend files.
rh>

--
S.Toms - smotrs@mindspring.com - www.mindspring.com/~smotrs
SuSE Linux v7.0+ - Kernel 2.2.18

Loud burping while walking around the airport is prohibited in
Halstead, Kansas.

--
S.Toms" wrote:

> On Wed, 4 Jul 2001, Rafael Herrera wrote:
>
> rh> 'mrproper' leaves your sources as you got them when you unpacked the
> rh> sources.
> rh>
>
> This will also remove your .config file, this is the file that contains
> all your kernel configuration options for what to compile into the kernel
> or as modules. So if you've spent alot of time coming up with the perfect
> configuration for you system, save the file to another directory before
> running mrproper.

I learned that the hard way.

Actually, it seems that if you copy .config to another file in the same
directory, say config.00, it doesn't get clobbered by mrproper. Don't know
about distclean.

--

On 4 Jul 2001, S.Toms wrote:

> rh> 'mrproper' leaves your sources as you got them when you unpacked the
> rh> sources.
> rh>
>
> This will also remove your .config file, this is the file that contains
> all your kernel configuration options for what to compile into the kernel
> or as modules. So if you've spent alot of time coming up with the perfect
> configuration for you system, save the file to another directory before
> running mrproper.

'make mrproper' is supposed to be the first step when compiling
your kernel, so it makes sure there are no "stale" files lying
around from a previous compilation, thereby returning it to its
original prestine state. 'make clean', however, is supposed to
follow 'make dep'.
--

--------------------------------------------------------------------------------

Rafael Herrera wrote:

> 'mrproper' leaves your sources as you got them when you unpacked the
> sources.
>
> 'clean' deletes all the binary objects and a few other files, but leaves
> others, like the .depend files.

So what's the difference, then, between "mrproper" and "distclean"?



--------------------------------------------------------------------------------

Look at the makefile:

mrproper: clean archmrproper
find . \( -size 0 -o -name .depend \) -type f -print | xargs rm -f
rm -f $(MRPROPER_FILES)
rm -rf $(MRPROPER_DIRS)
$(MAKE) -C Documentation/DocBook mrproper

distclean: mrproper
rm -f core `find . \( -name '*.orig' -o -name '*.rej' -o -name '*~' \
-o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \
-o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -type f -print` TAGS tags

distclean removes other garbage.
(snip)


When ever I compile a kernel, I redo the configuration anyway, and I forgot why I do the make mrproper step--I've just done it that way since the very first time.

One reason is that things are changing so fast, that I may be unaware of some of the new options. (If I see something new I'll abort, and read the kernel docs--something I should do every time anyway.)
Another reason is that I really want to be aware of exactly what is built on the system. It forces me to be methodical, instead of just doing things on impulse--which makes it much more likely that I will log everything I do on the system. Who me? Forget to log something? Nah. Right.

The creation of the directory in /lib with the full name of the new modules-full_kernel_version_number is part of the makefile. As is the creation of full-named files and new links in /boot. These new kernels have terrific makefiles. I haven't repeatedly compiled kernels with the same name in a while.

When I did it[Before compiling and installing the new kernel]: I mv (rename) the old kernel and related files in /boot, remade the links to point to the corresponding files and directories; renamed (mv) the specific modules directory in /lib; and renamed (mv) the kernel name in /etc/lilo, and /boot/grub/grub.conf. (I try to keep even unused things in sync, because I am paranoid.). The other way is to make an edit in the makefile--something I rarely have the courage to do--unless it is broken, I don't mess with it. (I have written successful scripts and programs, but I don't write them every day.)

P.S. I keep the old source for a while, using it's full name, in the /usr/src directory--in case things break with the newer kernel. That way I can test the cutting edge stuff, but still have the option to apply patches and stay with the older kernel. If you ls -al /usr/src you will see that the linux directory is a link to the current source tree. Before compiling, generally you re-do the link to point to your new sources.
I still keep a copy of the source pkg., but I'm lazy. If I'm going to patch, I want it ready--not in a tar-ball. If you are tight on room in /usr, then tar your old source tree if you haven't kept the package or if it has been successfully patched.
I have a separate /DATA partition to keep stuff like that, downloads, backups, and other stuff I want to keep. /home is kept as small and clean as possible.

When working with any package, including downloaded kernel sources: After you expand it, read anything that says README or DOCS.

Every time I have botched things, or hosed a working system, it has been because I didn't read something. Don't be me. Learn from my mistakes.

If you are going to make mistakes, try to invent new ones.