Kernel Compiling FAQ's: The PhoenixWing Way

From PhoenixWing

Why have /boot/System.map ? Rather than reiterate something that's been done and said, check this URL: Peter's Page: System.map

Why have /boot/config ? This is a general "safe" place to keep backup copies of kernel configs that work for a running kernel. Some programs have been known to use the configuration information, though I haven't been able to confirm this as of yet.

Why have /boot/vmlinuz and not just use /boot/kernel-some-vers? Old habits die hard. Some older linux installations use to rely on the kernel residing as the filename "vmlinuz" in a certain directory. The kernel used to reside in / and slowly became standard to put it in /boot/. With modern boot loaders becoming less rigid, you could call the kernel by any name, and place it in just about any location. However, I tend to stick with the latest standards, by placing it in /boot/ and naming it 'vmlinuz-version'. This way, I can compile multiple kernels, and keep backups, and provide symlinks to the kernel I am actively using.

You mention NOT compiling linux from source in /usr/src/linux, why? This is another controversial issue, but as I state plenty of other places, I'd rather be safe than sorry. For more information google it, or check these links: TAG, The Answer Gang and Symlinks in the Kernel.

Of course, there's also the Linux kernel README file:

 From the 2.4.0 release, in linux/README: 
 
 INSTALLING the kernel:
 
 - If you install the full sources, put the kernel tarball in a
 directory where you have permissions (eg. your home directory) and
 unpack it:
 
 gzip -cd linux-2.4.XX.tar.gz | tar xvf -
 
 Replace "XX" with the version number of the latest kernel.
 
 Do NOT use the /usr/src/linux area! This area has a (usually
 incomplete) set of kernel headers that are used by the library header
 files.  They should match the library, and not get messed up by
 whatever the kernel-du-jour happens to be.

On another note, when running systems such as Slackware, I have often installed the unaltered distro version of the kernel source for the headers used by the system to the /usr/src/linux location. If Slackware's compiled with Kernel 2.6.14.3 and I'm using Kernel 2.6.15.1, then I keep the 2.6.14.3 kernel source from the Source tarball provided by Slackware in the /usr/src/linux directory... my own source is in my home directory, /home/johnseth/compile/linux-2.6.15.1

I recompiled everything and I adjusted my /boot partitions using LVM and ... Hold up a moment. Not trying to be rude, but LVM is a tricky beast to tame. Once it is installed and working, it's powerful, and a sysadmin's dream come true. However, I would strongly suggest not setting up your /boot and / (root) partitions to utilize LVM. /home, /var, /usr, /some/other/directory... sure, hack away. Why? Well, from the LVM-HowTo:

 /boot is not included on the LV because bootloaders don't understand LVM
 volumes yet. It's possible boot on LVM will work, but you run the risk
 of having an unbootable system.

... also from the LVM-HowTo ...

 Warning! root on LV should be used by advanced users only: root on LVM
 requires an initrd image that activates the root LV. If a kernel is upgraded
 without building the necessary initrd image, that kernel will be unbootable.
 Newer distributions support lvm in their mkinitrd scripts as well as their
 packaged initrd images, so this becomes less of an issue over time.

In the case of the / device utilizing LVM, be sure to create an updated initrd image as described in my kernel compile articles. It's also helpful to check out mkinitrd's man page... you know, that wonderful 'man' command that so many people think is antiquated and a sysadmin's mistake (every sysadmin should know their system without having to use 'man'... yeah, right!).