This topic covers how to compile your own kernel, based on a configuration customized to your system, and how to install it. It also will be useful for anyone who wishes to try a newer kernel version than one available in pre-compiled form, or to compile a more compact kernel (without unneeded device drivers, for example, to save memory) than a kernel compiled to run on a wide variety of machines (like the ones that are installed by default with a distribution).
The process of compiling your own kernel involves three general steps:
1. getting the kernel source code;
2. configuring and compiling the kernel; and
3. installing the kernel.
1. Get the kernel source code
YDL includes the source code for the kernels included in a particular distribution; for example, those with YDL 2.1 can install the kernel-source-2.4.10-12a.ppc.rpm from the install CD; and those with YDL 2.0 have kernel-source-2.4.4-1a.ppc.rpm on the Tasty Morsels CD.
If you're compiling your own kernel, however, you probably want to try a more recent kernel.
1a. Choose which kernel to try.
The 'official' kernel sources are available from http://www.kernel.org/ . Normally, if downloading from there, it's the 'latest stable' version of the kernel source that you want. The 'prepatch (alpha)' kernel sources will be useful only if you need some feature, driver, or bug fix that hasn't made it into the 'stable' kernel yet; read the Changelog files to see what's different, and make sure that the feature, driver, or fix you want is there. Similarly, the 'ac' kernels available there may be useful for the same reason (they are part of a kernel tree maintained by Alan Cox, which are described as "frequently more experimental in nature than the official series," so again, checking the Changelog can help you decide if you need an 'ac' kernel. If you're not sure, get the 'latest stable' one. And, since kernel source code packages are big, using a mirror site (http://mirrors.kernel.org/) might help with the download.
An alternate source of kernel source code for PPC Linux users is http://www.ppckernel.org/ . This site is the home for kernel source code designed specifically by people for PowerPC-based machines. These, like the 'ac' kernels from kernel.org, might be useful if you need a particular driver or bug fix, in particular for use on a PowerPC-based machine. Note, however, that just because these kernels are designed for PPC Linux, this does not mean that the standard kernels won't work --- on the contrary, stable kernels from kernel.org should also work fine in PPC Linux. What it does mean is that the people maintaining the source code at ppckernel.org deal particularly with issues and drivers for PowerPC machines. Ultimately, a great deal of the work done here for the PowerPC architectures eventually ends up in the main kernel sources at kernel.org, particularly for kernels after 2.2.18 and 2.4.0-test10; similarly, changes made to the main sources at kernel.org end up being merged into the ppckernel.org sources. In any case, if you decide to try a kernel from ppckernel.org, one of the the 'BitKeeper' kernels at ppckernel.org will likely be the one you'd want, since the BitKeeper kernels are the most actively maintained; Changelogs for the BitKeeper kernels (2.2.x and 2.4.x) can be found at http://www.bitkeeper.com/bkweb/ (look for the Linux/PPC kernel trees). And, as with the kernel.org sources, it is safest to get the 'stable' version, not the development version.
Finally, should you get the latest 2.2 kernel or the latest 2.4 kernel? Most people these days with YDL 2.0 or 2.1, and especially those with more recent Macintosh hardware, should be safe with the most recent stable kernel from the 2.4 series (anyone with YDL 2.1 already has a 2.4 kernel, while YDL 2.0 users have a 2.2 kernel by default, but a 2.4 kernel will work fine). The 2.4 kernels have many new features (including much more powerful firewalling capabilities, called Netfilter), new and improved drivers (including USB and Firewire, particularly useful for those with recent Apple hardware), and many other optimizations and improvements (such as new and faster virtual memory code). Still, more conservative users who are currently running a 2.2 kernel might be inclined to get the latest 2.2 kernel instead, particularly if their machines are already stable running a 2.2 kernel and don't need any of the new features or drivers added in the 2.4 kernel. In the end, the choice is yours.
1b. Download the kernel source
Once you've chosen the kernel version you want, download its source code. Kernel source code is normally distributed as a gzip'ed tar file, so it should be downloaded as a binary file. Download the archive to wherever you like (your home directory is fine).
Then, to unpack the source and set up for compiling, use the following commands as root:
(if this directory doesn't exist, create it; if it does exist and contains a symbolic link called 'linux', delete that link, or if it contains another directory called 'linux', rename or delete that)
gunzip -c /pathto_kernel_archive/linux-2.X.X.tar.gz | tar xvf -
(be sure to include the - at the end)
ln -s /usr/src/linux-2.X.X /usr/src/linux
Of course, replace pathto_kernel_archive with the pathname of wherever you downloaded it, and the 2.X.X with the version number of the kernel you downloaded (e.g. 2.4.14). Note that the filenames used above follow the convention used at kernel.org; if you get your kernel sources somewhere else, you may need to use slightly different names.
In any case, you should end up with a /usr/src/linux-2.X.X directory (or similar), and a /usr/src/linux linked to /usr/src/linux-2.X.X.
2. Configure and compile the kernel
2a. Start the configuration tool
Before you can compile the kernel, it must be configured. First,
make menuconfigThis displays a nicely organized screen of the kernel options; navigate using the up and down cursor keys, and select items using the space bar; also, use the left and right cursor keys with the return key to use the buttons at the bottom of the screen (the 'help' button usually brings up information about the selected option, which can be very useful). The 'menuconfig' will work just fine in a text terminal, too, so you don't need to be running X.
Alternatively, if you're running an X session and would rather point and click, you can use
make xconfigwhich will give a GUI version of the menuconfig screen.
Another option is what might be called 'the old-fashioned way':
make configThis will go through the kernel configuration by giving you a series of questions and answers. Most users, however, will prefer the easier-to-use 'menuconfig' or 'xconfig'.
Kernel options can be set to one of two, and sometimes three, different values:
* selected, or 'y', means you want the option compiled into your kernel;
* not selected, or 'n',means the option will not be compiled into your kernel;
* 'm' means the option will be compiled as a module, which can be loaded or unloaded while the system is running (not all options can be compiled as a module).
In the 'menuconfig' method of kernel configuration, options that can be only 'y' or 'n' have [ ] next to them, while options that can also be compiled as a module have < > next to them.
For an option you want to include and that can be compiled as module, do you want to compile it as a module, or just compile it into the kernel? As a rule of thumb, if you definitely need a feature most of the time you're using your machine, just compile it into your kernel. If it's a feature you only need occasionally, compiling it as a module will do. And, if you definitely don't need a feature (as is often the case with drivers for devices you don't have, or features you never intend to use), you don't need to include its option at all.
If you're using 'make menuconfig' or 'make xconfig', it is an excellent idea to take the time to look at all the categories in the kernel configuration, and use the help to get information about an option if necessary. Often, the help will say, "if you're not sure, say Y" or something similar, which can be very helpful, indeed!
Users with Mac hardware should pay particular attention to a few sections while configuring: Platform Support, Console Drivers -> Frame Buffer Support, Macintosh Device Drivers, USB Support, and IEEE 1394 (Firewire) Support. Of course, SCSI Support, Network Device Support, Sound, and IrDA Support will probably also be useful, as will Networking Options for those running servers (the Netfilter/iptables options are in Networking Options, too). Note, too, that a few options, e.g. Plug and Play, make sense only for x86 Linux users, not Mac users.
If, even after checking the configuration help, you're not sure whether or not you need a particular driver or feature, there are three good sources of information:
* the 'dmesg' command, which will output the kernel's boot messages, which include messages from the kernel's detection of devices on your machine;
* the /var/log/messages file (or one of its archived versions in /var/log), which includes the same information, written every time the computer boots;
* the /proc filesystem (if you have one), in particular, /proc/pci and /proc/bus/usb/devices (viewable like ordinary text files, with 'cat' or 'more').
These things can tell you which devices you have, and for which you will need drivers in the kernel.
When you're finished selecting the configuration options you want, exit the configuration tool; you'll be asked whether you want to save your configuration: say yes! The configuration will be saved to a file called /usr/src/linux/.config -- if you think you might compile this kernel again, it's a good idea to save a backup of this file somewhere else. It's a plain text file, so you can view it if you want to check to see what options you chose, or even use it again when compiling a new kernel. On the other hand, if you compile a much newer version of the kernel than the one that you last configured, it's probably a good idea to go through the configuration process again, rather than use an old config file, since the newer kernel may have newer options that are better for you to use.
2c. Compile the kernel
cd /usr/src/linuxwhich the kernel configuration program probably told you to do when you saved your configuration. It may have also told you to 'make clean' after 'make dep', which you should do if it told you to. When that's done,
make vmlinuxYou'll see lots of messages fly by as the kernel is compiled. Depending on the speed of your machine and the options you chose, this might take a little while or even a long time. It's a good time to step away from your computer and take a break!
With luck, the kernel will compile without error; most stable kernels should.
If you do get errors, and the compilation stops before it finished compiling the kernel, try 'make vmlinux' again -- the compiler will pick up where it left off; sometimes this works. If you still get errors, it's possible that there are problems with something in your kernel source code (if it's with a particular driver, try doing the config again and remove all unnecessary drivers or select those drivers as modules -- it might help, as might searching the web for the error messages you're getting), or with your hardware (you may not have enough memory; or, since compiling a kernel is a very taxing process for your machine, there could be problems with your memory or something else that don't normally cause problems under lighter load -- this often exhibits itself as a 'signal 11' error from the compiler). And, of course, if your kernel source code was not marked 'stable', that could be the problem!
When it does compile, unless you want to do kernel debugging,
strip vmlinuxStrictly speaking, this isn't necessary, but it removes the debugging information from the kernel, and makes it a smaller file.
2d. Compile the kernel modules
cd /usr/src/linuxThis will do the compilation for those things that were set to 'm' (module) in your kernel configuration.
3. Install the kernel
3a. Put the new kernel in place
The Linux kernel is kept in /boot . In case your new kernel has problems, it's a very good idea to keep a copy of your old one; this is IMPORTANT, in case you have troubles booting with your new kernel. First, see how your current kernel is installed:
ls -l /boot/vmlinuxIf it's a symbolic link to the 'real' vmlinux file, you don't need to do anything special, but if it's the kernel itself, make a copy of it, and call it 'vmlinux.old' or something like that. Do the same for the file /boot/System.map (including making sure to save a copy).
Now, as root, put your new kernel in place:
cp /usr/src/linux/vmlinux /boot/vmlinux-2.X.Xwhere 2.X.X in each case is the version of the kernel you compiled.
ln -s /boot/vmlinux-2.X.X /boot/vmlinux
cp /usr/src/linux/System.map /boot/System.map-2.X.X
ln -s /boot/System.map-2.X.X /boot/System.map
Anyone using BootX still has one more thing to to copy: copy the new kernel to the partition on which BootX is installed, and put it where BootX can find it, in System Folder -> Linux kernels. This can be done by copying it directly there (if you've mounted that partition such that you can write files to it); or it can be done indirectly, by copying it to something like a Zip disk (useing xhfs, for example) or another machine (using ftp/sftp/scp), then rebooting to the MacOS and putting it in place. However you do it, you probably want to save a copy of your old kernel on the Mac side, too, and hit the 'save prefs' button in BootX when you've chosen the new kernel from the BootX pop-up menu of kernels, so that the new kernel becomes your default.
Finally, users of other boot loaders (like yaboot) may have to set their system to boot with the new kernel. Yaboot users, for example, may have to edit /etc/yaboot.conf. But, given that the new kernel is now linked to /boot/vmlinux, if your old kernel was also /boot/vmlinux (or linked to it) you might not have to change anything at all to boot from the new kernel.
3b. Install the modules
Kernel modules are kept in /lib/modules/2.X.X , where 2.X.X is the kernel version number for which the modules were compiled. To install them, as root:
cd /usr/src/linuxThat's it. You may, however, also need to edit /etc/modules.conf if your new kernel includes some things 'built-in' that were compiled as modules for your old kernel, or if you want certain modules to load at boot time ('man modules.conf' for information about this file and its format). After booting, modules can be loaded manually, using /sbin/modprobe or /sbin/insmod; use /sbin/lsmod and /sbin/rmmod (or modprobe with the appropriate options) to list or remove modules, respectively.
When all that's done, it's time to reboot, and enjoy the giddy feeling associated with running a computer with your own custom kernel! With luck, it will boot properly, and you'll be on your way.
If it did not boot properly, try again (don't know why, but I've seen my machine hang early in the boot process on the first boot with the new kernel, but then work perfectly an all subsequent reboots). If it still does not boot, it's time to tell your bootloader (BootX, yaboot, etc.) to use your old kernel, and go back and try again; this is why it's important to keep a copy of your old, 'known good' kernel. Check your kernel configuration; it's possible that you need to select other drivers or options required for your system, or remove options that are causing problems. Also, search the web or check mailing lists (such as at http://lists.linuxppc.org/) to see if others are having similar problems. Then, try again.
That's it! Assuming all the above was successful, you're now using a system running with your own custom kernel. Good luck, and enjoy!
Links mentioned above, in order of mention:
For more information:
(the main Linux Kernel HOWTO, but largely oriented to x86 users)
(for more information about the Linux kernel)
(for information on the most cutting-edge kernel development)
This HOWTO was prepared by Marc Ozon ... many thanks for such an indepth presentation.