You must rebuild the latest stable Linux kernel from source on your system. While many distributions provide both binary and source packages for their version of the kernel, you will download the latest version of the stable kernel from www.kernel.org. You will verify you have all the kernel building requirements (proper versions of tools, enough disk space), then configure, build, and (as root) install your new kernel. Note you don't have to be root to build a kernel, just to install one.
Make sure you new kernel includes the features needed in this course, including:
netfilter (the iptables
packet filter code) and related features .config support → Enable access
to .config through /proc/config.gz (Building features you don't need, even as modules, takes extra time and disk space. Don't include features you are sure you don't need (e.g., ISDN support).
Make a copy of your system journal pages that document the steps done and the kernel configuration you chose. (Note if you get the configuration wrong, it is a simple matter to change it and then rebuild the kernel from that point to us the new configuration.)
For this project, you may work either individually or with a single partner. Groups of more than two are not allowed! Each student must submit their own copy of the assignment which must include both your name and your partner's name.
uname command to check.)Stablekernel versions in the 2.6 series have version numbers such as
2.6.X.Y.)
(You can easily find out from
www.kernel.org/kdist/finger_banner.)df -h command.
(Note the download even after uncompressing isn't this large,
about 40MB to download and about 400MB
to unpack).
But many large files are created during the install so this much
space is needed, at least temporarily.)
Which filesystem has sufficient
space?
(Prefer $HOME to /usr/src if
possible.)/usr/src
you must take care not to overwrite existing files
there.
Depending on your distribution you may have to rename some
directories and files.
Rename an existing source directory of /usr/src/linux
to include the kernel version.
For example, if you currently have version 2.6.5-1.358
installed the source should be in a directory
/usr/src/linux-2.6.5,
and not /usr/src/linux.
Also check for a /usr/src/.config file, and
copy it to /usr/src/config-version or
/usr/src/config.old.
A backup of your grub.conf (or lilo.conf)
would be a good idea as well.cd ~/build # OR: cd /usr/src wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.X.Y.tar.bz2 wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.X.Y.tar.bz2.sign
gpg.
What is the ID of the Linux Archives
GPG key?tar -xf linux-2.6.X.Y.tar.bz2.
(This may take a short while.)
When installing under /usr/src, at this point you should
to create a symbolic (soft) link to the
/usr/src/linux-2.6.X.Y directory
with the name /usr/src/linux.
Then you can cd /usr/src/linux and complete the
install from there.
(Of course you should build in your home directory.
2.6 allows the source to be built in one place and installed
in another.)
cd ~/build # OR: cd /usr/src/linux make mrproper
(That step shouldn't be need for fresh source but it can't hurt!) The source is now installed and ready to be configured and built.
If you had any patches to install, now would be the time. Note that Red Hat does provide a source RPM package containing the patches they used for the shipped kernel for Fedora, but we shouldn't need it for this project.
To patch the Linux kernel, make sure you have the correct source code version for which the patch applies. Linux 2.6 patches apply to the head source code (2.6.X), not the latest stable code (2.6.X.Y)!
For example, if you have 2.6.5.2 and want to apply patches to get to 2.6.7.3, you need the 2.6.5 source code installed, then apply the 2.6.6 patch, then the 2.6.7 patch. These kernel patches aren't cumulative (unlike Microsoft service packs). You need all the patches between the version you have and the version you want, and must apply them all in order.
Once you have patched your way to the correct 2.6.X version, you can then apply a single (cumulative) patch to that to get the latest stable version (2.6.X.Y).
Unofficial patches are more dangerous than official ones.
Make sure you really need to do this!
In all cases use gpg to verify the originator and
integrity of the patch file you have downloaded.
To apply some patch called patch-2.6.X
to the source do the following:
# mv patch-2.6.X.bz2 ~/build # the parent directory of the kernel source # cd /usr/src/linux # bzip2 -dc ../patch-2.6.X.bz2 | patch -p1
For Solaris and other commercial Unixes the patches are binary files
that modify the kernel image file (and LKM files).
To patch your kernel with a Solaris (binary) patch you can use the
patchadd and patchrm commands.
Use patchadd -p to see list of installed
patches.
Or you can use
/usr/sadm/bin/smpatch {analyze|download|add}
to manage your patches.
However the easiest way to manage Solaris patches is to use the
popular (but 3rd party) pca script.
You can obtain pca from
www.par.univie.ac.at/solaris/pca/.
Solaris patches can be download from www.sun.com/sunsolve/patches/.
README file:
gcc is installed with
gcc --version.
What version of gcc do you have
installed, and what is the minimal version required? (lspci; cat /var/log/dmesg; cat/proc/cpuinfo) |lpr
2.6.X.Y.
If you install any patches or have custom configuration, you may
end up with several kernels with the exact same name.
To avoid this
you should change the value for
LOCALVERSION (EXTRAVERSION in older
kernels) to something like this:
–wp090521.
Here I use a dash, my initials, and the date, but you can use any
string you wish that makes sense to you.
The resulting kernel will have the name
vmlinuz–2.6.X.Y–wp090521.
make help for choices, and note that Fedora
puts old config files in /boot.
./.config.
Now run this command to begin:
make oldconfig # to update .config with new options make xconfig # to complete the configuration usig a GUI interface
For most choices you have the option of including the code in the
base kernel (a checkmark shows), including it as a module (a dot
shows), or not including it at all (the checkbox is empty).
The defaults include a lot of useless stuff as modules, which
doesn't hurt a thing except take up extra disk space.
However it can cause the build to last several hours!
If you skip some code for now and decide you need it later,
it is not hard to re-run
, and
mark the code to be included as a module.
Then you build just the missing code with
make xconfig
.
(Of course you will need to update the make all modules modules_installinitrd image
as well, or your new module won't be available to the kernel until
after the root filesystem has been remounted.)
If you're not sure which options to include, examine the system information you printed earlier for clues. When I built a kernel last year (!) on a spare computer, I made a number of changes to the default configuration. Your configuration will be very different than this! I provide this information for an example only.
The kernel .config support and access means you can extract
the config information from the running kernel,
from /proc/config.gz.
Loadable module versioning can cause headaches and is only
useful if you try to run modules from different kernel versions.
I selected the correct CPU type I actually have.
You also need to enable Preemptible Kernel or your
GUI will be horribly slow!
(This is due to a change in the 2.6 kernel from 2.4.)
The SELinux options support
SELinux in the kernel, but
enable it by default when booting.
The other options I changed just for fun.
I also disabled some code built as modules by default, stuff like
ISDN, frame-relay, battery monitor and other laptop
features.
A more through job of turning off stuff that isn't needed would have
saved a lot of time!
Go through all the configuration choices and read the help on each before deciding what to change. What configuration settings did you change from their default (or current kernel's) values?
Take a look at the .config file produced as a result of
your make xconfig.
You can also use diff to compare this configuration to
the old Fedora one.
If you change your mind about any options, you run the
command again and make any
needed changes.
make xconfig
Make a backup copy of your
.config file someplace.
Be sure to name it correctly with the kernel version
(and local version string).
date >~/build-date make # This can take several hours! sudo make modules_install # you need to be root for this part! date >>~/build-dateWhen this runs a lot of messages will scroll by very quickly, including some
warningmessages. This is normal. The time to worry is when you see
errormessages. How long did the build take?
make htmldocs mandocs installmandocs
(This step can take longer than the build itself!)
make install
command (which must be run as root), but this may or may not work
correctly on all systems.
This command invokes the shell script
/usr/src/linux/arch/i386/boot/install.sh
to do the install.
This script in turn runs an installkernel
script if it exists.
(It does on Fedora, in /sbin.)
Otherwise the script tries to install the kernel itself,
unfortunately configuring LILO and not
GRUB as the bootloader.
Fortunately Fedora does include a
/sbin/installkernel
shell script, which copies the files, makes the correct links,
and updates the GRUB configuration for you
(via another script,
/sbin/new-kernel-pkg.
That script invokes other scripts and eventually a command
called grubby to actually update the
grub.conf file.)
make install you can install
the kernel manually.
This involves copying (or linking) two files into /boot,
building an initial ramdisk, and updating the boot loader
configuration.
Part of this process is to make sure you can boot from your previous
working kernel if the new one doesn't work.
/boot./boot, using the
correct name.
Create the correct links.
The kernel can be found at
./arch/i386/boot/bzImage.
./System.map file to /boot,
again using the right names and links.
depmod command to update the dependency
information for the new kernel modules.
Check the man page for the correct options to use.
mkinitrd.
For example using version 2.6.1.2 (and no local version):
mkinitrd /boot/initrd-2.6.1.2 2.6.1.2
vmlinuz-version-localversion
(if I used any local version name).
Then I use symlinks to thee current and previous kernels with
the names vmlinuz and vmlinuz-old.
make install, you still need to
edit the Grub configuration.
This is because by default the system will boot your old kernel,
not the new one.
You want the new kernel as the default, with the old (working)
one available.
To do this, change the default=1default=0uname command to see if it is indeed your
new kernel running.
If it doesn't work reboot using the old one,
change the configuration, build additional (or fewer)
modules, and/or patch the source code, and then try again.
Make careful notes as you go, so you can correctly update your
journal later! Answers to the above questions and the relevant system journal entries. You can send as email to (preferred). If email is a problem for some reason, you may turn in a hard-copy. In this case the pages should be readable, dated, and stapled together. Your name should appear on the first page. See System Journal Hints for more details.
Don't turn in your whole journal, you will need to add to it every day in class! It is common in fact to keep the journal as a text file on the system (with a paper backup of course).
Please see your syllabus for more information about submitting projects.