How do I safely make custom kernels?
 

I'm trying to learn the kernel customization and compilation process, using whatever articles I can find and the book Linux Sea as a reference. I haven't gotten it to work yet, and for some reason I have now made my system unusable beyond the CLI. That's OK though (I can just reinstall, although it takes almost a day), what I don't like is being so clueless.

I would like to know how I managed to screw my system up when installing the modules, so that booting the original kernel doesn't work anymore, and how I can go back to my old configuration. I'm using Slackware current and have been using its huge-smp-2.6.35.7.
My current installation doesn't matter much, I want to understand the general process.

Question:
What is the clean, safe way of trying a new kernel configuration, that won't leave any traces if I decide it was a failure and go back to the previous kernel?

Short explanation: The apparently necessary make modules_install seems to change stuff system-wide - or for all kernels of the same version - making saving a LILO entry to my old vmlinuz insufficient as a safety measure. Learning this will be tedious if I can't go back when I screw up - the compilation taking up to 2+ hours is killing me already. :P

Long version: The first time I only ran 'make menuconfig', 'make', copied the new bzImage to /boot and updated LILO. In the boot messages, among other things it warned several times that it was expecting the 686 architecture and not the new one I had chosen (Atom), and although I could boot, X didn't work. Later when I read that I should run make modules_install after 'make' and tried that, these warnings disappeared. However I had screwed something else up this time and needed to go back. Trying to boot the original kernel (huge-smp, because generic can't mount my ext4 root fs for some reason), it now had lots of complaints about modules (which I assume had been updated for my custom kernel), so I tried restoring the original state by doing make clean in the kernel src dir, deleting .config, copying the bundled original .config for huge-smp, recompiling with 'make' just in case, and then running make modules_install again. After rebooting with my original huge-smp, nothing seems to have changed, the modules still aren't working and I get various errors, and only a CLI, X won't start (complains about modules that cannot be inserted).

What did I do? All the guides I've read only mention keeping a LILO or GRUB entry for the old kernel, which I did, and it's clearly not working in this case.
Is the system.map file relevant? Should I dare to use make install rather than copying the bzImage manually - would it overwrite a kernel of the same release?

Something that may make your life a little easier is that you can start with the .config file from the distribution media. On the Slackware64-13.1 DVD it's in the kernels/huge.s directory and you can simply copy that file into /usr/src/linux and proceed from there; that .config is what the distribution kernel was built from.

You may want to make mrproper, then copy the .config file (mrproper wipes that out), then make. If you've really done a lot of source code changes, you may want to reinstall the kernel source. And, yeah, it's going to take a while to build but then you can make install, run lilo and you ought to be good to go (look through the README file in /usr/src/linux).

After you get that stuff done, you can edit the configuration (don't run make mrpropter again), use an editor or the gui utility and make from there (see the README). You don't need (nor do you want) to start from scratch -- start with the distribution configuration and then edit that to customize things, lots easier, that -- you know, get back to something that works then twiddle it, add the current stuff and the like.

Hope this helps some.

Or you may be able to generate a .config file from the running kernel with zcat /proc/config.gz > .config_from_running_kernel. Definitely a better starting point than the "clean" kernel build environment's .config which has some strangely chosen (IMHO) defaults.

I am not knowledgeable enough to answer your specific questions but will contribute what I can, based on experience with 13.0 and 13.1 32- and 64-bit using GRUB.

If you have enough disk space you can save time on re-installing by backing up the OS file systems and then simply restoring; always nice to have a safety net.

I read a lot of HOWTOs etc. but found it hard to get started on kernel building until I found Alien Bob's page.

I use make install and have been able to revert to earlier kernels.

EDIT: having read H_TeXMeX_H's post below, I am reminded that I have always used a "local version" string.

Here's how I compile the kernel, after I grab the latest kernel from kernel.org and extract it to a stable location, I open a terminal there and run:

'installkernel' is a script I made:

If you are installing the same kernel version, it is likely that the '/lib/modules/$(uname -r)' will be overwritten and you will NOT be able to boot the older kernel. So append a local version by going to General setup->Local version and imputing something there. This is how they get the '-smp' on some of them.

Make sure to have an entry in lilo for the older kernel.

System.map is important, use my script and it will copy it properly.

This is very important, and probably what the OP is missing.
Life will (should) be much easier then.

Do'h - just read catkins edit...

Thank you, those are all great helpful answers! With all this and Alien Bob's article I feel confident to give another shot.

Just one minor follow-up question: Let's assume that I am way too greedy for my own good and keep going back every time it works, trying to save another 8 bytes of memory... Seeing how overwriting the modules messed me up this time, can I recycle the custom string I'm experimenting on, or should I make it custom-133, custom-134 et c? If I want to really clean those up, would it be sufficient to rm -r /lib/modules/custom-2.6.xx.x, or will there be leftovers somewhere else?
I mean, it would be annoying if I unknowingly created the ultimate configuration one day and it didn't work because of conflicting old stuff from 283 previous attempts.

Now how do I mark this thread as solved... :)

It is useful to increment the custom string so you can boot an older version for investigation or backout. AFAIK it is sufficient to rm -r /lib/modules/2.6.xx.x-<local version(s)> and the corresponding files in /boot.

Threads can be marked SOLVED via the Thread Tools menu.