I would like to make a couple of small changes to the kernel config.

I used make menuconfig to do this, and assumed that the subsequent make would only recompile the bits changed. But instead it proceeded to rebuild each and every module. Since on my machine a kernel build takes literally hours, I was forced to abandon.

Is there no way to reconfigure without a full rebuild?

Help appreciated...

(If anyone could suggest a workaround, what I am trying to do is as follows:

1. Device drivers > Generic driver options > Prevent firmware from being built - N (currently Y)
2. Device drivers > Generic driver options > Hotplug firmware loading support - Y (currently M))

Honestly I don't remember if make menuconfig recreates all the makefiles. It's possible. If so, changing only kernel configuration file (in main kernel dir) may be a betetr option. From your post it looks that you only need the kernel, not modules. It means you can break it when it starts building modules (if you use standard config, there are hundreds of them and module compilation is much longer than kernel core).

Another note: you can compile on another machine (faster) and then move the kernel file. It will work (make sure platform and processor is set correctly for the machine you want to move the kernel to).

Thanks for that information, Mara.

So, just to be sure I understood. I could change the options in .config, save, and then... just make?

How and at what point would it be best to "break" the compile process?

Yes, just this way. Modules start compiling after something like 'Making modules' is written. It's only one message in many different ones, so may be hard to spot.

I am uncomfortable with the idea of aborting the make and also with trying to build from a system in which a make has been aborted.

I recommend that you:

• Make a safe backup copy of your .config file.
• make clean
• Verify that the .config is still as you left it.
• Do another complete make starting tonight. Let the computer grind away at it all night.

From my experience, generally a recompile will only rebuild the parts that I've changed but once every blue moon it decides to poke a stick up my nose and rebuild everything just for fun. I'm going with the build overnight option also. Something you can do is go over the entire config and make sure it's only building modules for hardware you actually have. One of the full compiles for me takes about 15mins when I have only selected the stuff on my system, compiling the kernel from my distros standard package takes a lot longer though.

I have to say I'm surprised that there doesn't appear to be a definitive way to turn off compiling of modules. But thanks for the input all three of you, that really helped.

I too am uncomfortable with doing any unnecessary kill, so I am going to go with Sundial's advice. And yes, I'm also compiling lots of unnecessary modules, for fear of missing one I didn't know I needed. I guess I'll just have to take the risk of missing them out. If it works, then at least I can use that config as a base the next time. At the moment, a full compile is taking over four hours, though that's also partly because of my slow machine...

If you only want to insert modules into the kernel, that is, you want to change /usr/src/linux/.config to reflect only additions of modules, you can make the modules individually and insert them into the running kernel with modprobe.

Goto the directory with the module source and run

make

this will make all the modules in that directory which are configured to be made in .config.

Then, insert the module with

modprobe module.ko

Hello AwesomeMachine! Thanks for that, it was so useful that I now have more questions.

1. Where are the kernel modules actually stored? This should be simple - "in /lib/modules/$linuxversion/". So what are all those modules under /usr/src/linux? Are they supposed to be duplicated like that? This one has been bugging me for a while.

2. I have three kernels installed. Why does nothing appear under the one I am currently running except a couple of empty subdirectories leading to a single file, ie /usr/src/&currentlinuxversion/i386/default/Module.symvers ?

The completed, loadable modules are in /lib/modules/$linuxversion/, while the source-code and other materials used to compile and build them are in /usr/src/linux. When you do the final make install, the files are copied to the /lib/modules/... location.
Did you build the one you are currently using? If it came from a distro, did you load the source-code packages? It sounds to me like you did not; hence, the directory is empty. But any modules should be in /lib/modules/... for that particular version.

As for "what modules should I compile," the Linux build process will determine what to build according to your selections when you configured the kernel. The defaults, in many cases, include "support for just about every device-type this side of the moon," as a module. When your system is actually up and running, you can use the lsmod command to determine which modules you actually are using at that moment in time. Bear in mind that the modules can be loaded and unloaded dynamically, e.g. when you plug-in a new type of USB device.

It took a slight bit of doing, but these days I do take the time to figure out what kind of device-support I actually need, and put only that (very small) number of device-drivers directly into the kernel. In particular, I do not use an "initial ramdisk." But, that's just me.

Really useful information, Sundial.

Yep, my currently running kernel is the one provided by SUSE which I keep maintained and use as a safe option. Only problem is that it doesn't support USB! Only 2.6.11 does that on my hardware. And only 2.6.13 supports DVB, hence all the experimentation.

The Module.symvers file just contains lots of cross-referenced module device codes, so I guess the distro knows where to find its kernel at boot time because it isn't in /usr/src/.

I will definitely do a lot of module-pruning before the next recompile. However, on my system the initial kernel make does take a fair while, ie even before the modules start. Any ideas for safe options to turn off to cut down on this?

Apparently Module.symvers is used for module-versioning, and I confess that I am not terribly familiar with it.

Remember... the booted kernel is not in /usr/src. (As the name implies, that directory is for source-code.) The booted kernel always lives in a partition called /boot. You may find similarly-named files, or even copies, elsewhere where you were building them... but the only one that matters to the loader, afaik, is the one in /boot.

Here's what I think I'd do at this point, more-or-less: (Peanut Gallery, please feel free to chime in!)

• Copy your .config file to a safe place.
• In your source directory for your new kernel, do make distclean.
• Copy the .config file back from its safe place, keeping the copy.
• Note: As an alternative, i.e. if you think your present config is more-or-less frotzed, make defconfig will handily generate a pretty-good starting-point configuration that you can subsequently edit.
• Now make menuconfig (or whatever) and carefully review all of your options. Particularly the device-drivers. You know your hardware, so you know more or less what you need. (That is, if you don't have a DecNET token-ring model 12345-XYZ card or a Cray-67 Super Oatmeal-Cooler (Mark IV) card, you probably don't need support for it although a "stock" distro certainly might.) Get rid of the stuff that you know you don't need; if you're not sure about something, leave it be.
• Make sure that your kernel version, identifier, etc. do not match those of a kernel you really intend to keep. (You don't want to overwrite anything.)
• Make a copy of your final .config, before you build from it, remembering to provide a descriptive name against foggy memories later. (Space is cheap: keep 'em all!)
• Now, make your kernel, and review the output for errors. {I normally do make ... >make_log.txt 2>make_errs.txt or somesuch. Maybe there's a better way...}
• Do a make install, and once again check the contents of places like /boot, /lib/modules/xxx for "reasonableness." For example, are all of the modules nice and bright-shiny-new, as in "freshly made?"
• If it appears okay, boot 'er up.
• If it doesn't, always recompile the whole thing again from distclean!
• Now look at the output of the dmesg command, and any boot-logs that may now be in /var/log. Again, look carefully for trouble. Check all devices for correct operation.
• When you say, "it takes a long time..." ask yourself, "when? perhaps why?" The devil is in the details. The Linux startup sequence consists of many distinct phases... initrd (maybe); kernel boot; starting the init process; rc.sysinit; and finally, entering the desired runlevel with all of the many subsystem-initializations that occur at that time.

Another excellent post from Sundial. This thread is becoming almost sticky-able!

First, thanks for putting me right on the locations issue, Sundial. Seems obvious now, but these things can be confusing.

I'm going to follow Sundial's recommended course of action. In fact I've started it already, and had a surprise. As per instructions, I evacuated a copy of .config, ran make distclean and then make menuconfig, armed with the current output of lsmod.

But strangely the default options presented by menuconfig were much sparser than when run on the vanilla kernel. Hardly any modules were selected by default, although it seemed that the right ones mostly were. Is this correct? What exactly does make distclean do? It is described in the Makefile as "Remove editor backup files, patch leftover files and the like". It seems that the .config file was changed somehow. In any case I went thru the config carefully, making sure to re-check anything which my machine definitely or possibly uses. Notably ReiserFS. And leaving unchecked the majority of the hundreds of device drivers.

I will run it tomorrow and report feedback.

PS Where's a good module-by-module guide to the kernel configuration? There's a decent one at http://linux.developpez.com/guide/book1.html but it's in French, which is a minor inconvenience for a lot of people. Looks like it could have been translated, but I can't find the original.