Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Kb269

Kb269

Emulab FAQ: Customizing your experiment: How do I build a custom Linux kernel?

Emulab FAQ: Customizing your experiment: How do I build a custom Linux kernel?

If your kernel build is failing, the kernel panics, or anything else, this guide should help you compile a working kernel for Emulab machines. Since most users are interested in building the latest, greatest vanilla kernel from kernel.org, these instructions apply to the 2.6 kernels. The instructions assume a machine running one of the Emulab standard Fedora Core 4 or 6 images (i.e., FC4-STD or FC6-STD). Note that the instructions for FC4 and FC6 differ slightly, since FC6 uses GRUB instead of LILO as the bootloader.

First, note that lots of useful information for building your own images can be found in /share on users.emulab.net . For the purposes of this guide, we're interested in /share/fedora/FC4/src and /share/fedora/FC6/src, which have kernel config files and source trees (if only the config files are present, you can download the source from kernel.org). The config-emulab kernel config will get you a kernel which should boot on all machines that we currently have. For kernel versions prior to 2.6.20, the config-emulab-SMP config gets you a kernel that enables SMP, hyperthreading, and multi-core support (which will work on pc3000s and pc3000ws. The reason these two configs are separate is because SMP-enabled kernels don't seem to boot on our older machines, as of 2.6.18.1. However, the 2.6.20 FC6 configs contain support for SMP, hyperthreading, and multi-core, and build kernels that work on all our machines.

Now, let's get to building your kernel.

  • Swap in a one-node experiment with FC4-STD or FC6-STD (or another of our Fedora Core 4/6 images).
  • Once logged into the node you just swapped in, run these steps from a shell (note that they require local_root privileges), changing the kernel version as desired:
    $ sudo chown -R YOUR_UID:YOUR_GID /usr/src [[BR]] $ cd /usr/src [[BR]]
    If you only need to add some modules for your application, we suggest that you try using the Emulab kernel source tree for either FC4 or FC6 in /share; i.e.,
    $ rsync -avz ops.emulab.net:/share/fedora/FC6/src/linux-2.6.20-1.2944.fc6.emulab-1 ./ [[BR]]
    Otherwise, download the kernel that you're interested in from kernel.org:
    $ wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.1.tar.bz2 [[BR]] $ bunzip2 -c linux-2.6.18.1.tar.bz2 | tar xf - [[BR]]
    Then, continue with
    $ ln -s linux-<version> linux [[BR]] $ cd linux [[BR]] $ cp /share/fedora/FC6/src/linux-2.6.20-1.2944.fc6.emulab-1/config-emulab .config [[BR]] $ make [[BR]] $ sudo make modules_install [[BR]] $ sudo make install [[BR]]
  • If you're building on FC6, make install will not produce errors, but you need to fix up /boot/grub/grub.conf. Make sure that each line starting with kernel contains the correct root=/dev/(s,h)dX parameter (i.e., you need to set the root parameter to the device and partition on which the current root partition is mounted). For our machines, this is either /dev/sda2 or /dev/hda2 (find out which via mount | grep dev; look for something like /dev/sda2 on / type ext3 (rw). Do not use the standard Fedora root="LABEL=/" syntax; if you do, we cannot assure that your image will run on all our machines.

    If you're building on FC4 and make install complains about duplicate aliases, this is really lilo complaining about duplicate aliases for kernel image entries in /etc/lilo.conf. So, just sudo emacs -nw /etc/lilo.conf (or your preferred editor) and change the top image entry's alias= to something different than the others in the file. Then, do
    $ sudo /sbin/lilo -v
    and note that there are no errors. Then you should be ready to go.

If you need to modify our default kernel configs, try as much as possible (shouldn't be a problem) NOT TO MODIFY the device drivers. If you remove support for certain chipsets, NICs, and disk controllers, your kernel will probably not boot on some or all of our machines. If you absolutely must reduce the size of the kernel or build times, the output of "dmesg | less" can help you understand which drivers are actually being used by devices on a particular node.