These are the scripts I use for building and installing the kernels, plus a bunch of other useful stuff for maintaining the repository. One should distinguish two types of user, the person who creates and maintains the repository, and the person who uses the kernels from it. The most important scripts for the maintainer are: - KernelBuild.sh, which builds one kernel version, - BuildAll.pl, which builds a set of kernels, and - BuildMissingVersions.pl, which builds any versions which are not already built. These scripts make use of some of the other scripts, namely - KernelBuild.cmds, which contains the commands needed to build a kernel, - KernelConfig.exp, which configures the kernel, - Meanwhile.pl, which runs the whole thing in the background, freeing the user to do other things. The administrator of the repository would not normally ever call these scripts directly. There's also FetchAndRepackKernels.sh, which uses Anonymous-FTP.exp to get kernel images from a kernel archive mirror and repack them the way I want them. Then there's some scripts for users of the repository: Installkernel.pl and InstallHeaders.pl, which install the built kernel and its header files respectively. Finally, kernel_version and set_link are useful to users and administrators of the installed kernels. For the administrator: There are three important environment variables for the building scripts. You can set them explicitly in your environment or they will set them to default values. There names are MY_ROOT, MY_WORK, and MY_SRC. MY_ROOT is a directory where the scripts will put a link 'linux' to point to a given source tree once that tree is unpacked. For standard Linux installations, if you build the kernel as root, then MY_ROOT would be '/usr/src'. I prefer to be able to build kernels as a normal user, so I have made /usr/src/linux a soft-link to /Linux/kernel/repository/linux, and _that_ is a link to the version I am compiling at any given time. So, for me, MY_ROOT is /Linux/kernel/repository. This directory, and everything in it, is owned by me, not by root. MY_WORK is the location for building the kernel and distribution files. It may be anywhere that is writeable and has enough space. Again, in a standard Linux environment, this would be '/usr/src'. In my machine, I use '/Linux/kernel/repository'. It defaults to the same value as MY_ROOT. MY_SRC is the path to the directory holding the source of the linux kernel versions. I use '$MY_ROOT/source' by default. It may seem that having three environment variables is overkill, but there are advantages: Suppose a user 'fred' wants to build these kernels with slightly different options. He can set MY_ROOT to /usr/src, MY_WORK to /afs/cern.ch/user/f/fred/public/Linux, and MY_SRC to /afs/cern.ch/user/w/wildish/public/Linux/kernel/repository/source. Then he copies these scripts to $MY_WORK/bin/*, modifies them as he sees fit, and runs them! I use a naming convention for the kernel source trees which is non-standard, but straightforward. After unpacking a kernel and applying any patches that I want, I rename the top-level directory from 'linux' to 'linux-.', and make a tar/bzip2 archive of that. These archives are then kept in $MY_SRC. This allows me to have several kernel trees unpacked at the same level simultaneously without conflict, and reminds me which one I am looking at at any given time. I encode the same name into the compiled kernel too, so that 'uname -v' on the running kernel will tell you which patches it has and how many processors it was compiled for. -------------------------------------------------------- The individual scripts are: -------------------------------------------------------- KernelBuild.sh: --------------- This script will build a kernel version for me and keep a logfile. Use this if you want to build a kernel and have a record of the build. Basically all I do is type 'KernelBuild.sh ' where a file called '$MY_SRC/.tar.bz2' exists, and it does the rest. The steps are: 1) unpack the kernel tree in the $MY_WORK directory 2) set the link $MY_ROOT/linux to point to this unpacked distribution 3) configure the kernel using $MY_WORK/bin/KernelConfig.exp 4) build the uniprocessor version 5) installs it in the $MY_WORK/root directory 6) make a tar archive in the $MY_WORK/dist directory 7) then repeat the config, make, and install cycles for the SMP version. When this is all over it sends me a mail to tell me to go see what it did, and I look in $MY_WORK/log/.log for the full story. For example, on my machine, './KernelBuild.sh linux-2.0.36.bphys' will do everything I need to get the uni- and smp-versions of 2.0.36 with the bigphysarea patch - always assuming I have prepared the source tree! Note that you do _not_ give the '.tar.bz2' extension, the script will add this for itself! The end result will be that I have two files, /Linux/kernel/repository/dist/linux-2.0.36.bphys-UNI.tgz and -SMP.tgz, with the distributable compiled kernels. I also have the record of the entire build process in /Linux/kernel/repository/log/linux-2.0.36.bphys.log. Note that the distribution files contain a copy of the Expect script (KernelConfig.exp) used to configure it. This allows you to really verify how the kernel was created, in the event that this script changes. -------------------------------------------------------- KernelConfig.exp: ----------------- If you wish to configure a kernel and have the same set of choices as we have for these kernels, use this script. It's an Expect script that runs 'make config' for you. It hardwires some of the options (e.g. Pentium, ramdisk, initial ramdisk, ext2, minix etc). For all other options it builds the feature as a module if it can, or takes the default if building as a module is not an option. Just unpack the source tree and set the link for /usr/src/linux, then 'cd' into the top of the source tree and run this script with no arguments. It is not intended to be a definitive solution to compiling all possible kernels. It _is_ intended to be a deterministic way of configuring sensible defaults into any kernel from the 2.[012] series. Take this as your starting point and we should be able to limit any divergence. N.B. KernelConfig.exp reacts to the defaults that are defined for your kernel. These in turn are the builtin defaults if you have never configured this kernel, or are taken from the last set of configuration options if you have. You may want to 'make mrproper' first, to be sure you have a completely clean tree. -------------------------------------------------------- KernelBuild.cmds: ----------------- This script is fed to the real workhorse - 'Meanwhile.pl'. It could be executed as a SH/BASH script if you like, though you would have to make sure that the environment variables it uses are defined properly first. If they aren't, the script will exit. It is useful in that it serves as a record of exactly how I built the kernels. It does steps 4-7 of the procedure outlined above, producing the distribution files and everything else, but _not_ the build logs. For that, use the 'KernelBuild.sh' script. You would not normally run this script by hand. -------------------------------------------------------- Meanwhile.pl: ------------- Thisis a Perl script that is launched by KernelBuild.sh to run the commands listed in KernelBuild.cmds. You would not normally run this by hand. It is designed to allow you to start a job and then go off and do something else completely while the job runs in the background, disconnected from the terminal. When it is finished it sends a mail to the user who launched it, hence it's name: It does all the work for you, meanwhile, you do something else. It has nothing to do with Linux kernels per se, for instance the ATLAS offline use it as part of their overnight build process. Meanwhile.pl saves the output from the commands it runs in a logfile in $MY_WORK/log/.log. You can scan this log looking for lines beginning with '======', because I use this as a separator, followed by the command that I execute, followed by the output of that command. It's easier if you look at the logfiles themselves for the explanation! -------------------------------------------------------- InstallKernel.pl: ----------------- For those among you who are brave enough to allow an automatic installation of a kernel, 'InstallKernel.pl ' will install the kernel and modules in the root partition and will _carefully_ add an entry to /etc/lilo.conf, saving a copy as a backup first. It will _NOT_ run lilo for you, nor will it reboot your system or change the default kernel. I have been very careful with this script, so nothing should go wrong (WRONG, Wrong, wrong...). For instance, it will refuse to unpack the archive if it would clobber an existing file by doing so, unless you explicitly tell it to. You can use it to install the kernels directly from AFS if you wish. E.g, as root you can run # ./InstallKernel.pl ../dist/2.2.3.orig-UNI.tgz -------------------------------------------------------- BuildAll.pl: ------------ BuildAll.pl will build the whole lot, in turn. If you want to make your own archive with different versions, all you need take are the source directory and the bin directory, then run 'BuildAll.pl' without any arguments. It takes 10 hours on my desktop machine (PII/233 + 64MB). If you give arguments, it does a wildcard match of the arguments against files in the source directory and builds whatever it finds that matches them. E.g. If I type # BuildAll.pl 2.2.0 bphys it will build all the versions of 2.2.0 that I have, and will also build all kernels with the bphys patch. It is smart enough, however, that it will only build 2.2.0-with-the-bphys-patch once, even though it matches both arguments. Tony Wildish. 26/01/99 updated 24/03/99 Copyright 1999 T.Wildish (Tony.Wildish@cern.ch). This file may be distributed under the terms of the GnU Public Licence.