The most current version of this document can be found at http://users.wowway.com/~zlinuxman/Kernel.htm.
Step 1: Update Your sources.list File
Step 2: Update the List of Available Packages
Step 3: Apply Pending Updates
Step 4: Install the Kernel Source Package
Step 5: Unpack the Kernel Sources
Step 6: Install
Step 7: Patch the Kernel
Step 8: Configure the Kernel
Step 9: Create the Kernel Image Package
Step 10: Customize the Kernel Installation Environment
Changing Boot Loaders
Customizing the Squeeze (6.0) Environment
Customizing the Wheezy (7.1) Environment
Customizing the Jessie Environment
Step 11: Install the Kernel Image Package
Step 12: Shutdown and Reboot
Step 13: Clean Up
Step 13a: Clean Up (Part Two)
Step 14: Maintenance
A Specific Example
Another Specific Example
This is not an official Debian site. The author is not a member of the Debian kernel team. This is not an official Linux kernel site. This document details the author's experiences and recommendations in building a custom Linux kernel under Debian GNU/Linux. All opinions expressed are those of the author and do not necessarily represent the opinions or the official positions of Debian, the Linux kernel organization, or any other organization or individual. This information is presented in the hope that it will be useful, but without any warranty or guarantee of any kind. This information is presented free of charge, free of support, free of service, and free of liability. Take this information with as many grains of salt as you think it's worth; and use it, if you choose to do so, entirely at your own risk. The author hereby explicitly places this material in the public domain. All trademarks, registered trademarks, service marks, etc. are the property of their respective owners.
Most of the time, the stock kernel images obtained from Debian are adequate. But occasionally one may need to create a custom kernel image in order to take advantage of some special feature or solve a particular problem. Or you may want to create a custom kernel in order to create a "lean and mean" kernel: one which is as small as possible and contains only the code necessary to do the function assigned to this machine. (This is often done in embedded systems.) I assume that you already know why you need or want to build a custom kernel. The purpose of this document is to show you how. Most of my examples are from the i386 architecture, but the techniques are applicable to all architectures.
I had a roommate in college who had spent four years in the Navy. He told me that in the Navy there are three ways to do everything: the right way, the wrong way, and the Navy way! Well, kernel building in Debian is like that too. Although there are similarities to other distributions, Debian definitely has its own way of building kernels. Information that you may find on distribution-independent Linux sites or sites from non-Debian-based distributions that talk about building a custom kernel are not likely to be very useful in Debian. Debian wants everything, including the kernel itself, to go through its package management system. As a result, kernel building in Debian is quite different from other non-Debian-based distributions.
I have found that the documentation for kernel building in Debian is spread out over several different sources. Some of these documents are out of date. Furthermore, there are a number of small but important steps that are often left out. This write-up is an attempt to document the procedure in detail. In addition, this document shows how a custom kernel fits in with the overall lifecycle of upgrading and maintaining a Debian system. If you're going to be running a custom kernel on an on-going basis, you need to know how to integrate the custom kernel with Debian maintenance procedures.
I am assuming that you have never downloaded or configured a kernel source package on your system before and that you want to create a custom kernel image package of the same kernel release as the stock kernel that you are currently running. I'll be using kernel 3.2.46 from the Wheezy (7.1) release and the i386 architecture in most of my examples, but as I said earlier the techniques are applicable to all releases and architectures.
If you're going to follow the procedures recommended in this
document, your non-root user account must be enrolled in the "src"
# adduser steve src
Make sure you do that before you start, and verify (by means of the "groups" command) that your non-root user account actually has the "src" group listed in the output of the "groups" command before you attempt to perform any of these steps using that account. It used to be that once root enrolled a user in a new group, all instances of that user had to logout before a new login of that user would actually have the privileges of that group. This included the graphical desktop environment, if that user logged into the graphical desktop. In rare cases, such as hung processes, etc., one had to reboot after enrolling the non-root user in a new group before the output of the groups command issued by that user would show the new group as one of its groups.
However, with newer systems, this no longer appears to be the case. It now appears that any session which existed prior to the new group being added will not have the privileges of the new group, but any new login session created after the privilege has been granted appears to have the privileges of the new group. I'm not sure exactly when that change was made; so you'll have to follow one procedure or the other, depending on the age of your system. The bottom line: do whatever it takes to get the output of the "groups" command issued by the non-root user to show the new group in its list of groups.
Also, make sure that the directory /usr/src is owned by user
root and by group src, and that the group has read and write
privileges on the directory.
Execute privileges on the directory should be granted to all users
(user, group, and other).
Also, make sure that the
$ ls -ld /usr/src drwxrwsr-x 3 root src 4096 Aug 24 13:52 /usr/src
The lower-case letter "s" in the seventh position of the file attributes
indicates that the
# chmod g+s /usr/src
(Any changes to the privileges on the /usr/src directory must be done by root.) Once you select a non-root user account for kernel-building purposes, you must use that same userid for all non-root steps.
Do this step as root.
The retrieval of packages in Debian is
controlled by a file called /etc/apt/sources.list.
If you installed Debian
You will need to issue this command once for every CD in your set
that is not already listed in sources.list.
If you have several
When running a graphical desktop environment, such as GNOME,
the udisks daemon may give you trouble.
The udisks daemon tries to auto-mount any data CD inserted
in the CD drive while it is running and interferes with
CD mounting and unmounting by
udisks --inhibit-polling /dev/sr0
(I am assuming here that /dev/sr0 is the block special file name
of your CD drive, or a symbolic link to the block special file
name of your CD drive.
If not, substitute the appropriate device name.)
Then, switch to another terminal session and do your work.
When finished, including removal of the last CD from the CD drive,
switch back to the terminal session running udisks
and type ^C (Ctrl+C) to cancel the udisks command.
If you don't have any mountable media sources listed in
/etc/apt/sources.list, and you don't plan to add any
If you have access to the internet, you should also include an internet server in sources.list. This is true even if you installed Debian from CDs. You should also make sure that the updates and security sites are present as well. (The updates site should only be used if you are running the stable release. This takes the place of the old "volatile" site.) If you didn't have access to the internet during installation, the installer may have included such entries, but commented them out. If you have access to the internet now, but you didn't during installation, uncomment these entries. This will allow you to install the most recent version of a package, if there is a newer version than the one on the CD.
Packages in the stable release are not
normally updated during the life of the
release except to fix bugs involving
security vulnerabilities or to replace data that is highly volatile in
An example is the virus signature data for an
anti-virus software package.
Occasionally some "safe" fixes are also introduced.
These are important fixes which have been well tested
and are extremely unlikely to cause any
forward compatibility issues.
(Well, that's the theory anyway.)
These fixes are introduced from time to time as
"stable point releases."
You might also want to add entries for the
With the exception of the security site, which must use
HTTP, you have a choice, for most of the Debian mirrors,
whether to use HTTP or FTP as the file transfer protocol.
Be careful though some of the
mirrors use a different path name for HTTP and FTP.
For a full list of Debian mirrors, see
Choose the mirror nearest to you or which gives you the
shortest latency or the highest data transfer rate.
Make sure you choose a mirror which supports the file
transfer method you want to use and specify the correct path
for that type of file transfer.
Also, make sure that you choose a mirror that mirrors your
(Not all mirrors mirror all architectures!)
For more information, see the man page for sources.list(5)
and the above-mentioned web page which lists all the mirrors.
For all sources except CDs, DVDs, and
. . (possible CD/DVD/Blu-ray entries added by apt-cdrom) . deb ftp://carroll.aset.psu.edu/pub/linux/distributions/debian wheezy main non-free contrib deb-src ftp://carroll.aset.psu.edu/pub/linux/distributions/debian wheezy main non-free contrib deb ftp://carroll.aset.psu.edu/pub/linux/distributions/debian wheezy-updates main non-free contrib deb-src ftp://carroll.aset.psu.edu/pub/linux/distributions/debian wheezy-updates main non-free contrib deb http://security.debian.org wheezy/updates main non-free contrib deb-src http://security.debian.org wheezy/updates main non-free contrib
The "deb" entries specify a server for binary packages and
Note: always use a release code name, such
as wheezy, jessie, etc., rather than a status, such as stable, testing,
etc., in /etc/apt/sources.list.
The reason for this is that nasty things will happen when a new
release comes out if you code a status.
For example, suppose you used "stable" in your /etc/apt/sources.list file
back when Squeeze (6.0) was the stable release.
The result will be an attempted release upgrade from Squeeze (6.0)
to Wheezy (7.1)
at the next
Sometimes you may need to define multiple releases in your sources.list
For example, you are running the testing release; but you need
at least one package from unstable (or maybe even experimental).
In particular, if you need or want to fetch kernel source code that
is newer than the newest source code available in your current release,
you will need to define multiple releases in sources.list.
Here is a sample sources.list file for a system which is running
the current testing release (Jessie) but that also needs one
or more packages from the unstable release (Sid) or experimental:
. . (possible CD/DVD/Blu-ray entries added by apt-cdrom) . deb ftp://carroll.aset.psu.edu/pub/linux/distributions/debian jessie main non-free contrib deb-src ftp://carroll.aset.psu.edu/pub/linux/distributions/debian jessie main non-free contrib deb ftp://carroll.aset.psu.edu/pub/linux/distributions/debian sid main non-free contrib deb-src ftp://carroll.aset.psu.edu/pub/linux/distributions/debian sid main non-free contrib deb ftp://carroll.aset.psu.edu/pub/linux/distributions/debian experimental main non-free contrib deb-src ftp://carroll.aset.psu.edu/pub/linux/distributions/debian experimental main non-free contrib deb http://security.debian.org jessie/updates main non-free contrib deb-src http://security.debian.org jessie/updates main non-free contrib
Once again note that status names (testing, unstable, etc.) are not used:
release code names (jessie, sid, etc.) are used instead.
Also note that the updates site (
When mixing releases in the same system, it is important to define
the default release.
You do this in /etc/apt/apt.conf.
Put a line such as the following in the above-named file:
This will cause
Note: synaptic does not understand or honor
this definition of a default release.
In synaptic you set the default release with
Settings -> Preferences, click on the Distribution tab,
select the radio button next to "Prefer versions from:", then select
your default release from the drop-down menu.
I'd avoid using synaptic if I were you.
My advice, for what it's worth, is to
Do this step as root.
Once the sources.list file has been
updated, you need to update the package
management system's list of available packages.
I used to recommend
Do this step as root.
After updating the list of available packages, as outlined above,
you should apply all the pending updates that have accumulated since
you last applied updates (or since installation, if
you have never applied updates).
To do this, enter the following command:
Note: whenever you apply updates, as per above,
and you have more than one kernel image package installed,
watch the console output carefully to see if an initial RAM file
system image file gets rebuilt; and if it does, check to see if the
initial RAM file system image file that got rebuilt is the one that
corresponds to your running kernel.
This is especially important if you are using MODULES=dep in
As an example, suppose that you have two kernels installed:
2.6.32-3-686 and 2.6.32-5-686.
You have a traditional IDE hard disk.
You have "MODULES=dep" specified in
If you apply maintenance and it causes the initial RAM file
system image file for your running kernel
to be re-built, shutdown and boot the other installed
kernel images in turn and rebuild their initial RAM file
system image files with
update-initramfs -uk $(uname -r)
Continue the process until all the initial RAM file system image files have been rebuilt while running the corresponding kernel.
If the maintenance causes a cross-build
of an initial RAM file system image file,
and you are using MODULES=dep; first rebuild the correct
initial RAM file system image file
(i.e. the initial RAM file system image file for your running kernel)
update-initramfs -uk $(uname -r)
Then change MODULES=dep to MODULES=most, cross-build the same initial RAM file system image file again that was cross-built the first time, then shutdown and boot that kernel. After the reboot, change MODULES=most back to MODULES=dep and rebuild the initial RAM file system image file for that kernel again. If there are any other installed kernels besides these two, shutdown and boot each of the remaining kernels in turn, rebuilding their initial RAM file system image files while the corresponding kernel is running.
In any case, whenever an initial RAM file system image file is rebuilt as the result of applying updates, and you have more than one kernel image package installed, you must take care to rebuild all of the remaining initial RAM file system image files manually. The exact procedure to use will depend on the circumstances. If you are installing a new kernel and you are using MODULES=dep, it is safest to use MODULES=most initially, then re-build with MODULES=dep after you are running that kernel.
The Debian maintenance system is supposed to be smart enough
to know when an initial RAM file system image needs to be rebuilt
and to do so automatically.
However, there have been times, when running
Note: I personally like to use the
I recommend that you subscribe to three mailing lists
if you are running the current stable release.
They will tell you when updates are made.
The first is the
to install the updates.
If you are running the testing release or the unstable release,
you should perform this procedure regularly,
since updates are not generally announced.
When you are finished installing package updates, use
to delete the package files (.deb files) from the package cache (/var/cache/apt/archives). Once the packages have been installed, you don't need the package files themselves anymore. This will save disk space. Once the updates have been installed, it is a good idea to shutdown and reboot. This is especially true if the kernel has been serviced or an initial RAM file system image has been rebuilt.
only package files downloaded from the internet end up in the
Package files read from
if you are running the testing or unstable releases,
Do this step as root.
Once you have updated the list of available packages with
Use aptitude to list the available source packages that you can install.
aptitude --disable-columns search linux-source
Packages with a status of "p" or "r" are not installed.
To install the package, use aptitude.
aptitude install linux-source-3.2
This will install the kernel source code. (Although it is kernel source, it is classified as a "binary" package in the Debian packaging system; therefore, you must be root to install it.)
You can obtain kernel source code packages from other places, such as pristine kernel source tarballs from kernel.org or one of its mirrors; but I recommend using official Debian kernel source packages whenever possible because they contain all of the Debian-specific modifications. Another advantage to using a Debian package is that you will automatically get the package dependencies, such as bzip2. However, under certain circumstances, you may need to download the very latest pristine kernel source code, such as when testing a fix written by the kernel people for a problem you reported. When manually downloading a pristine kernel source tarball, do so as the non-root user and download to directory /usr/src.
If you have out-of-kernel-source-tree kernel module source
packages to install, do that at this time also.
(If you don't know what an out-of-kernel-source-tree kernel module
source package is, you probably don't need one;
so don't worry about it at this point.)
Once these commands have completed, enter
to delete the package files (.deb files) from the package cache.
A kernel source package file is huge;
so this is important to save disk space.
(Obviously, you don't need to issue
Do this step as a non-root user.
Use the same userid for all non-root steps.
The non-root user must be a member of group "src".
So what did
cd /usr/src tar -xjf linux-source-3.2.tar.bz2
The "x" switch of tar indicates that the "extract" function will be used. The "j" switch tells tar to filter the archive through bunzip2 to decompress the archive first, before tar itself processes the file. And finally, the "f" switch specifies that input is to be read from a file specified on the command line, instead of standard input.
The above "tar" command will create a directory
under the current directory
Note: when issuing the above "rm" command as a non-root user, you may be prompted as to whether or not you want to erase a write-protected file. That's due to the fact that the file is owned by user root and group root, and your id is not root and you're not enrolled in group root either. Go ahead and respond with a "y". The rm command will still succeed because group src has write privileges to the directory /usr/src, and your id is a member of group src.
Recent official Debian Linux kernel source packages for Wheezy (7.1)
now also install another file in /usr/src besides the source tarball.
For example, package
cd /usr/src bunzip2 linux-patch-3.2-rt.patch.bz2 cd linux-source-3.2 patch -p1 <../linux-patch-3.2-rt.patch cd .. rm linux-patch-3.2-rt.patch
The bunzip2 command will create the file
Starting with Debian package
tar -xJf linux-source-3.10.tar.xz
If your version of tar does not support the
unxz linux-source-3.10.tar.xz tar -xf linux-source-3.10.tar
Alternatively, you can use a pipeline to avoid creating
an intermediate file.
xz -dc linux-source-3.10.tar.xz|tar -xf -
If you have installed out-of-kernel-source-tree kernel module source packages, their tar files will also be present in /usr/src. Unpack them also in a similar manner and then delete the tar files once they have been successfully unpacked. These tar files will be extracted to a directory under /usr/src/modules.
Do this step as root.
If you have not already done so, install the
dpkg-query -l kernel-package|grep ii
If it is not already installed, install it.
aptitude install kernel-package
Read the README file for
Determine what additional packages you may need,
assuming that you are going
gcc (This is actually a dependency package which brings in the real one) libc6-dev libncurses5-dev binutils make module-init-tools (or kmod in Wheezy (7.1) and newer releases) mawk | gawk (one or the other, you don't need both) gzip coreutils grep zlib1g-dev (if CONFIG_LGUEST is set) fakeroot (if building the kernel as a non-root user)
(Note: bin86 used to be required to compile the kernel
for the i386 architecture, but as of kernel releases 2.4.x and later,
bin86 is no longer required.)
Many of these packages will already be installed.
To check to see if these packages are installed,
dpkg-query -l gcc|grep ii
Install those packages which you need
aptitude install libncurses5-dev zlib1g-dev aptitude clean
There may also be some packages needed to install the
kernel image package once it has been built.
For example, you may need
At this point I recommend
that you edit the
If you are using
cd /usr/share/kernel-package ... (download the patch file to the current directory) patch -p1 <linuxv3.diff
This is an unofficial patch: it is not provided by or endorsed by the
upstream author or the Debian package maintainer.
Also please note that
Do this step as a non-root user. Use the same userid for all non-root steps. The non-root user must be a member of group "src". At this point, apply any patches to the kernel source code that are needed or desired for your custom kernel. If you have any patches to apply to out-of-kernel-source-tree kernel module source packages, apply them at this time as well.
As an example, here is a patch that I am currently running on my custom kernel: edid_strict.diff. This patch allows monitors with invalid EDID check sums or EDID version numbers, but which otherwise have usable EDID data in them, to be used with Linux, despite the failure to strictly comply with the EDID standard. (It only works with KMS-based drivers.) In particular, it allows my Future Power 17DB77 CRT monitor to be used at 1024x768 resolution with an 85 Hz vertical refresh rate (non-interlaced). Without this patch, a 60Hz vertical refresh rate (non-interlaced) was the best I could get out of it. Even then, I got errors written to /var/log/syslog about every 10 seconds, which will fill up the hard drive eventually, if the system stays up long enough. With the patch, I get error messages written to /var/log/syslog during boot; but ongoing error messages every ten seconds disappears.
Here's how to use the patch.
Download the patch to a file in the /usr/src directory.
Give it a meaningful name.
I called it edid_strict.diff on my system.
Now make a symbolic link to the patch in the home directory of your Linux
cd /usr/src . . (download patch to edid_strict.diff) . cd linux-source-3.2 ln -s ../edid_strict.diff edid_strict.diff
Do not move (mv) the patch to the Linux source code
Make a symbolic link to it.
The reason for this will become apparent when we get to the
Now apply the patch:
patch -p1 <edid_strict.diff
Now create a file in /etc/modprobe.d called local.conf.
(You'll have to create this file as root.)
Put the following line in it:
options drm edid_strict=0
Save the file and exit the editor. I hope that someday this patch, or something similar to it, will be incorporated into the official kernel; but in the mean time, you can add this support yourself by patching the kernel source code and building a custom kernel.
Do this step as a non-root user.
Use the same userid for all non-root steps.
The non-root user must be a member of group "src".
First, change directories to the home directory for
the source code.
Now, initialize the .config file based on the configuration file
used by the stock Debian kernel.
cp /boot/config-3.2.0-4-686-pae .config
This means that if you make no changes, your custom kernel will be configured exactly like the stock Debian kernel. Obviously, adjust the name of the config file to copy based on your architecture and kernel release. The file you need will start with "config" and will have your kernel version name in it.
Note: this assumes that you have
installed the kernel source code for one of the stock kernels
that is currently installed.
I don't recommend that you migrate to a new kernel
release this way.
Don't use a config file from one kernel release as the
basis for customization of a different kernel release
(unless the kernel source is newer than the config file
and you follow-up with
Similarly, if you're using a recent Wheezy (7.1) kernel source code package
(or newer releases)
and you have not applied the patches for real-time preemption,
make sure that the config file you copy is from a stock kernel
that does not have
Starting with Debian package
cd /usr/src cp linux-config-3.10/config.i386_rt_686-pae.xz . unxz config.i386_rt_686-pae.xz cp config.i386_rt_686-pae linux-source-3.10/.config rm config.i386_rt_686-pae cd linux-source-3.10
Now it's time to configure the kernel:
After some preliminaries, an ncurses-based full-screen application will be launched that allows you to configure the kernel. I assume that you know what to do here. (Obviously this is going to require that you are using a full-screen terminal. Don't try this on a pure line-mode device, such as a teletype machine or something analogous to it. On systems which do not have a full-screen console, such as s390/s390x, login via a remote ssh client to perform this step.)
Note: In the process of configuring your kernel, make sure that you leave CONFIG_BLK_DEV_INITRD set to Y, which is the default. This is listed under "General Setup" as "Initial RAM file system and RAM disk (initramfs/initrd) support". You're probably going to need that. I'll have more to say about that later.
Note: Newer kernel config files contain
some settings that you should
These include CONFIG_LOCALVERSION (Local version - append to
kernel release) and CONFIG_LOCALVERSION_AUTO (Automatically append
version information to the version string).
These are found under "General Setup".
Note: even if you do not plan to change
the kernel configuration file copied
from the /boot directory at all,
you must still run
It used to be a real pain to create a
"lean and mean" custom kernel: one which only contains
the function necessary to execute on your specific machine.
It can easily take all day to customize the kernel configuration
to get everything you need but nothing that you don't need,
and it is easy to leave something out that you need but don't
realize that you need.
However, starting with kernel version 2.6.32, a new kernel
configuration option is available called
Of course, before you run this, you should plug in and turn on
all peripheral equipment that you plan to use with this machine
but which is not always connected.
For example, if you have an external USB
Of course there is a down side to building a "lean and mean" kernel: if you subsequently reconfigure your system, such as changing video cards, network adapters, sound cards, etc., there will likely be no support in your previously-built kernel for the new hardware. This is a trade-off you will have to weigh and decide what's most important to you.
Unless you specifically intend to debug the kernel, I recommend that you set CONFIG_DEBUG_INFO to N (i.e. leave it unset). (This option is under "Kernel Hacking" and is listed as "Compile the kernel with debug info". Starting with 3.11 kernel releases, this option is in a submenu under "Kernel Hacking" called "Compile-time checks and compiler options".) Setting this option makes the kernel and modules much larger and provides no benefit under ordinary operating conditions. Setting it to N (i.e. leaving it unset) greatly reduces the size of the kernel and its modules.
If you build your kernel with
Do this step as a non-root user. Use the same userid for all non-root steps. The non-root user must be a member of group "src". This step will compile the kernel source code and create a Debian binary package file for the custom kernel. But before I get to the specific commands, I need to discuss naming conventions. This is critically important. I need to talk about the difference between the kernel version name and the kernel revision name. Both the kernel version name and the kernel revision name become part of the package file name (.deb file) that gets created. However, when the package file gets installed, the kernel revision name does not become part of the package name. It also does not become part of the kernel image file name or the initial RAM file system image file name that gets created in the /boot directory. Similarly, the directory in which the kernel modules get installed (/lib/modules/...) does not contain the kernel revision name either. Since you want to retain your existing kernel image file, initial RAM file system image file, and kernel modules unaltered as a backout, you must make the kernel version name different from the stock kernel version name in some way.
This is accomplished by means of the
On the other hand, I would keep the kernel revision exactly the same
as the stock kernel.
That way, I know exactly which stock kernel revision it
For example, at the time of this writing,
Of course, if you're using a pristine kernel source instead of
a Debian source package, there won't be a Debian package version
You'll have to make something up in this case.
However, make sure that whatever you choose is compliant with
Debian policy guidelines for kernel image package version names.
One other complication has recently arisen starting with Wheezy (7.1).
The kernel's "internal version" is no longer consistent with the
version implied by the package name for stock kernel image packages.
For example, at the time of this writing, the stock kernel image package
name in Wheezy (7.1) for modern machines of the i386 architecture is
When you build a kernel image package with
Note: if you are using the latest Wheezy (7.1)
kernel sources with the real-time preemption patches applied, the patches will
automatically include the
Also, I need to talk about initial RAM file system images. A standard stock Debian kernel is configured with almost everything built as a module, if it can be a module, rather than built in to the kernel. This allows for installation on as wide a variety of hardware configurations as possible while holding the size of the kernel down as much as possible. But modules reside on disk. And any kernel function that is required for the kernel to be able to mount the partitions or do I/O to the disks must be loaded into storage before any kernel modules can be read from disk. This means that either this support must be compiled into the kernel or else it must be loaded from the initial RAM file system. This is the primary purpose for an initial RAM file system: it allows the kernel to load modules that it needs before it can read them from disk. (Recently, the initial RAM file system has acquired a second purpose: it allows user-space processes, such as udev, to be launched that assist the kernel in finding its permanent root file system and suspend/resume images.) Once the permanent root file system is mounted read-only, the initial RAM file system is freed from memory.
As an example from the i386 architecture, suppose your permanent root file system, which contains /lib/modules/..., is mapped to a partition on a SCSI disk. But the kernel support for the SCSI adapter is not compiled into the kernel: it is a loadable module. As an example from the s390x architecture, how can you load the dasd driver modules from disk when those modules must be loaded in order to do I/O to the disk? In such cases, you need an initial RAM file system.
Stock Debian kernel image packages are set up via the boot loader
(grub, lilo, zipl, etc.) to use
initial RAM file system image files.
I am assuming in
these instructions that you are going to do the same.
If not, then you must do five things:
(1) You must make sure that all kernel function needed to get
the permanent root file system mounted is built-in to the kernel.
(2) You must disable initial RAM file system support in the kernel.
This is handled by the CONFIG_BLK_DEV_INITRD variable, which you should
set to N (i.e. make unset).
In the menuconfig menus, this is labeled "Initial RAM file system
and RAM disk (initramfs/initrd) support".
For recent kernels, this is in "General Setup".
(3) You must not supply the
OK, with all that said, we are ready to start issuing commands.
Issue the following command to build the package(s):
make-kpkg --append-to-version -4custom01-686-pae \ --revision 3.2.46-1 --initrd --rootcmd fakeroot \ kernel_image modules_image
If you don't have any out-of-kernel-source-tree kernel module source
packages installed, you can omit the modules_image target.
If your computer has more than one processor, and your currently-running
kernel is SMP (Symmetric Multi-Processing) enabled, you may be able to
get the compilation done faster by using the CONCURRENCY_LEVEL
Set the CONCURRENCY_LEVEL environment variable to the number of
simultaneous compile tasks that you want to use.
The maximum practical value for CONCURRENCY_LEVEL is the number of
processors which are online in your configuration.
The minimum value is one.
The default value, if CONCURRENCY_LEVEL is not set, is also one.
CONCURRENCY_LEVEL=2 make-kpkg ...
will allow two simultaneous compile tasks. However, if your system is memory (RAM) constrained, this can actually slow things down. Running too many simultaneous compiles may cause excessive paging, which will cause the overall process to take even longer than if fewer compile tasks were running simultaneously. If you use this option, make sure you have enough memory to support it.
By the way, a system with a single "core" that is "hyper threaded" will appear to the kernel as a system with two processors. Using both of them simultaneously can increase throughput, but not to the same extent as a system with two cores which are not hyper threaded.
By using the "getconf" command, you can set CONCURRENCY_LEVEL
to the number of processors currently online, which, assuming that
you have sufficient memory (RAM), will be the optimum value
for compiling the kernel in the shortest possible time.
CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) make-kpkg ...
Of course, making all processors available for simultaneous compilation will slow down the rest of the system. There's always trade-offs!
A well-packaged out-of-kernel-source-tree kernel module
source package will have a Debian package designed for use with
You can still use these
uncooperative packages with your custom kernel
fakeroot make-kpkg --append-to-version -4custom01-686-pae \ --revision 3.2.46-1 --initrd kernel_image kernel_headers
This will cause
Compiling the entire kernel takes a while. We're talking hours, probably, depending on the speed of your processor, and assuming that your kernel configuration is not too different from a stock kernel configuration file. If you have configured a "lean and mean" kernel, it will compile much faster. For example, it may only take an hour instead of five hours.
I should probably say something here about fakeroot.
Compiling the kernel does not require root privileges, but building
a Debian package file (.deb file) normally does.
Root privileges are normally needed by
Do this step as root. This step has proven to be the most difficult one for me to document clearly (and concisely) because there are so many variations. Before we get lost in the nitty gritty details, I think it would be good to step back and review a little history. This will explain why this step is so messy.
The Debian kernel team used to
The advantage of making
On the down side, however,
With the exception of the documentation issue
One could argue that
if the Debian kernel team felt compelled
to use their own tools for creating official Debian stock kernel
image packages, they should have used a different configuration
Things weren't too bad until Squeeze (6.0).
But the version of
To further muddy the waters, the upstream Linux kernel developers
now support a
This web page really isn't about how to change boot loaders;
but this seems like a good time and place to mention it,
since we are up to our ears in kernel image package installation
If you are interested in switching to the LILO boot loader
(my personal favorite), see my
LILO Web Page.
Even if you do not plan to change boot loaders,
you may find it useful to read this page
because it provides useful
insights into how the kernel maintainer scripts,
If you are running Wheezy (7.1), you should still read this section
because this section is the foundation for both.
Squeeze (6.0) changes things.
The maintainer scripts that are packaged with a kernel image package
Here is a simplified overview of how hook scripts
work under Squeeze (6.0).
After a kernel image package is installed, any executable files found in
/etc/kernel/postinst.d will be invoked.
These executable files are normally script files placed there by
various packages that need or want to know about a kernel image package
installation or upgrade.
The kernel image package maintainer script invokes these scripts
One of the post-installation scripts
in this directory is
Similarly, when a kernel image package is removed or purged, any
executable files found in /etc/kernel/postrm.d will be invoked.
For completeness' sake, I should also mention that there are two other directories where hook scripts can be installed: /etc/kernel/preinst.d and /etc/kernel/prerm.d. You can probably guess by their names when their contents are invoked. But you normally won't need to be concerned about them.
As soon as multiple hook scripts are placed into the same
directory, the issue of execution order arises.
As previously stated, the
If your boot loader does not use symbolic links, you probably don't need any more hook scripts. But if you are using a boot loader that makes use of symbolic links, such as lilo or zipl, you will probably need some additional hook scripts. The current hook script policy can be found here. At the time of this writing, boot loaders which need them provide hook scripts; but they are usually not optimal. For example, they may not handle symbolic link maintenance for custom kernel image packages or may not prevent unnecessary invocations of the boot loader installer.
At the time of this writing, no boot loader packages that I have
looked at provide hook scripts that maintain symbolic links.
The maintainers apparently assumed that symbolic links would be
taken care of by
At the time of this writing, there are no hook scripts available
as part of the official Debian system which will maintain symbolic
links; but I have written some which are available on my web site
You can install the
Once you have downloaded these files and copied them to their proper
destination directories, be sure to use chown, chgrp, and chmod commands,
as needed, to set their attributes properly.
The group should be root, the owner should be root, and the permissions
The boot loader hook scripts provided with lilo
and zipl do not distinguish between
These hook scripts may run underneath a higher-level process, debconf to be specific, which has redirected both standard input (STDIN) and standard output (STDOUT). When the interface is fully active, debconf expects the program to write debconf protocol commands to STDOUT and read result codes on STDIN. Thus, output to STDOUT does not display on the terminal and can potentially wreak havoc. Thus, any console output produced by hook scripts must be redirected to standard error (STDERR). This is accomplished by means of the >&2 redirection operator. You can see this on all commands in the scripts that would normally write to STDOUT. Similarly, if a command normally reads from STDIN, its input must be redirected to another source, such as a file. If you don't anticipate STDIN being used, but you want to protect yourself against STDIN being accidentally used, you can redirect STDIN to /dev/null. This is done by the </dev/null redirection operator. If you see these redirection operators on commands in the hook scripts, you now know why they are there.
When run under debconf, for example during an
The postrm hook scripts are called for both a remove and
For a purge, they don't need to do anything, since all the
work was done at remove time.
Note: Debian bug number 599934 is now fixed in
Wheezy (7.1) for the lilo package, and Debian bug number 599931 is
now fixed in Wheezy (7.1) for the
OK, so we've installed these hook scripts for the benefit of
kernel image packages created by
The maintainer scripts for a stock kernel image
package delete the initial RAM
file system image file during a remove.
In summary, this is what I recommend for
do_symlinks = no
do_bootloader is omitted because its default value is "no"
for stock kernel 2.6.32.
For later stock kernels, it is a vestigial option.
The option is vestigial for all custom kernels in Squeeze (6.0)
and later releases.
The boot loader hook scripts will take care of running the
boot loader installer during a kernel image package install, update, or
There is one final hook script directory
of which you should be aware.
To allow the removal of special boot loader processing
logic from initramfs creators
The Wheezy (7.1) Environment is nearly
identical to the Squeeze (6.0) environment.
The main differences are as follows:
The Jessie environment is currently customized the same way as the Wheezy (7.1) environment.
Regardless of whether you are running Squeeze (6.0), Wheezy (7.1), or Jessie,
the customization of the kernel installation environment
only needs to be done
the first time you prepare to install a kernel image package
Do this step as root.
OK, now it's time to actually install the kernel image package.
You won't use aptitude or
cd /usr/src dpkg -i linux-image-3.2.46-4custom01-686-pae_3.2.46-1_i386.deb
Obviously, use the actual name of the package file,
which can be determined by using the ls command.
If you have both a kernel image package and one or
more modules image packages, install the kernel image package first,
then the modules image packages.
The latter will probably have a dependency on the former.
If you had to build a
If the kernel installation environment has been properly customized, the maintainer scripts or the hook scripts will automatically create the initial RAM file system image file, update the symbolic links (if requested), and re-run your boot loader installer, if necessary. But before you shut down and reboot, it is a good idea to check everything out in /boot and in your boot loader configuration to make sure that the new kernel was installed properly.
Do this step as root.
Shutdown and reboot to run your new custom kernel!
shutdown -r now;exit
Do this step as a non-root user.
Use the same userid for all non-root steps.
The non-root user must be a member of group "src".
Once the new kernel image package has been installed, you can
delete the package file (.deb file).
cd /usr/src rm linux-image-3.2.46-4custom01-686-pae_3.2.46-1_i386.deb
If you have also installed one or more modules image packages,
you can delete their package files too.
The same goes for a
Do this step as root.
Once you are satisfied with the new kernel, you may wish to de-install
the old kernel image package.
I like to keep at least one back version unless I know
that the old kernel will no longer work due to changes
made since migrating to the new kernel.
For example, if my system now depends on a kernel module
that did not exist in the old kernel, there's not much point
in keeping the old kernel around.
aptitude purge linux-image-3.2.0-4-686-pae
This will de-install the old kernel image package and
save some more disk space.
If you have out-of-kernel-source-tree kernel module image packages
installed that are tied to the old kernel image package,
purge the kernel module image packages first,
then purge the old kernel.
If you have a
Note: make sure you have shut down and re-booted using the new kernel before attempting to purge the old kernel! You don't want to try to purge a kernel while it is running! Besides, you don't yet know if your new kernel works!
May you have much enjoyment running your new custom kernel!
This is a mixed-mode step: some commands are issued as root
and some commands are issued as a non-root user.
OK, now what if you get the new custom kernel installed and running,
but you want to make changes to the kernel configuration?
Maybe you forgot something the first time.
Use a sequence of commands something like this.
(Note: the commands which must be run as root are prefaced with a
The commands which should be run as a non-root user are prefaced
with a dollar sign.
Use the same userid for all non-root steps.
The non-root user must be a member of the "src" group.)
$ cd /usr/src/linux-source-3.2 $ make-kpkg --rootcmd fakeroot modules_clean $ make-kpkg clean $ make menuconfig $ make-kpkg --append-to-version -4custom02-686-pae \ > --revision 3.2.46-1 --initrd --rootcmd fakeroot \ > kernel_image modules_image $ cd .. $ su # dpkg -i linux-image-3.2.46-4custom02-686-pae_3.2.46-1_i386.deb . . ("dpkg -i" commands to install the modules image package files) . # exit . . ("rm" commands to remove the modules image package files) . $ rm linux-image-3.2.46-4custom02-686-pae_3.2.46-1_i386.deb $ su # shutdown -r now;exit
Something like the above will do nicely.
(The ">" is the shell's continuation prompt.
Do not type it literally, just as you don't type the "$"
or "#" literally.)
Note the extra commands to do cleanup (
As before, if you need a headers package, add the kernel_headers
target to the main
For boot loaders which use symbolic links, such as lilo and zipl,
your boot loader is typically configured to boot two kernels: the primary
kernel, which is the most recently installed one, and one alternate one,
which is the next most recently installed one.
If you didn't de-install the
stock kernel last time, you should probably do so now.
You've got three kernel image
packages installed on your machine now:
the original stock kernel, your first custom
kernel, and your second custom kernel.
And only the two custom ones are
bootable at this point, unless you've been customizing your boot loader
configuration as well.
# aptitude purge linux-image-3.2.0-4-686-pae
If you have out-of-kernel-source-tree kernel module image packages installed that are tied to the old kernel image package, purge the kernel module image packages first, then purge the old kernel. If you have a headers package installed which is tied to the old kernel, purge it last. Once your first custom kernel rolls off the boot loader menu, de-install it in a similar manner. For boot loaders such as grub which do not use symbolic links, it's up to you how many back-level kernels you want to keep around. For most people, two bootable kernels (the current one and the previous one) are adequate.
OK, you've been happily running your custom kernel
for several months now;
and you get a security update notice from Debian.
After waiting a couple of days for the upload to propagate to all
mirrors, including the one you use,
you update the list of
available packages via
Well, it's time to clean house.
you've already run
$ cd /usr/src $ rm -r linux-source-3.2 $ tar -xjf linux-source-3.2.tar.bz2 $ rm linux-source-3.2.tar.bz2
For Wheezy (7.1) and later kernels, you will also have the real-time preemption patches to deal with, as discussed earlier. Either install them or erase them, per your choice.
For Jessie kernels (3.10.xx and later),
aptitude purge linux-source-3.10
This must be done as root, of course. The old source directory, since it does not get created automatically during package installation, must be erased manually.
A similar procedure is followed if an out-of-kernel-source-tree
kernel module source package has been downloaded and installed.
For example, if
$ cd /usr/src $ rm -r modules/nvidia-kernel-legacy-96xx $ tar -xjf nvidia-kernel-legacy-96xx-source.tar.bz2 $ rm nvidia-kernel-legacy-96xx-source.tar.bz2
If your kernel source is replaced, you don't need to use the "clean"
If you applied a patch file to your kernel source code in step 7, you now understand why I recommended to create a symbolic link to the patch file instead of moving the patch file to the top level directory of the kernel source code. When that directory was removed, the symbolic link disappeared with it; but the patch file itself in /usr/src still exists. All you need to do is to redefine the symbolic link and you're back in business. If you had moved the patch file to the top level directory of the kernel source code, the patch file would now be gone, and you would have had to recreate it. Of course, the same principle applies for a patch file to an out-of-kernel-source-tree kernel module source package.
Now proceed to step 7, with some minor variations.
If the kernel source was replaced, you will need to recreate the
symbolic link(s) to the patch file(s), if any, and reapply the
(The patch files themselves will still be there in /usr/src.)
If a kernel module source package was replaced, do the same for any
patch files you have against the module source.
If the kernel source was replaced, the name of the config
file that gets copied from the /boot directory to .config in the current
directory must change to match the current kernel config file.
Since the old config file may no longer be exactly in sync
with the new source code,
you will need to run
If the kernel source was replaced, you must
Note: sometimes the stock kernel configuration file
will change with a security update
or a new stable point release.
The powers that be may have decided to change a kernel configuration
option for security or other reasons.
The announcement e-mail should tell you what was changed and why.
In that case, if you want to keep your custom kernel configuration file
in sync with the latest stock kernel, you will need to
make a corresponding change to your custom kernel config file
when you run
If you're using an official Debian kernel source package, such as
You can get around this problem by installing the
For Linux kernels 2.6.31 and later,
If you have a kernel source package new enough to support
If you decide to use
$ make KDEB_PKGVERSION=3.2.46-1 deb-pkg
The equivalent of
The CONCURRENCY_LEVEL environment variable is not supported,
but the -j option provides equivalent function.
$ make -j2 deb-pkg
is the equivalent of setting CONCURRENCY_LEVEL to 2.
Anything pertaining to modules, such as the MODULE_LOC environment
/usr/src is the historic (and default) location for package source
code under Debian GNU/Linux, but
some people don't like to put it there because it violates the FHS
(Filesystem Hierarchy Standard).
They prefer to put it somewhere else, such as ~/src.
(~ represents the home directory of the non-root user
who will own the source code.)
If this is what you want to do, there are a few changes you will
need to make.
After installing the source package (as root) with
$ cd /usr/src $ tar -xjf linux-source-3.2.tar.bz2 -C ~/src
$ cd ~/src/linux-source-3.2 $ MODULE_LOC=~/src/modules make-kpkg ... modules_image
If MODULE_LOC is not specified,
the default value is /usr/src/modules.
Make other adjustments to path specifications as appropriate.
Note that if you do your processing under your home directory, as
in this example, your non-root user account does not need to be a
member of the src group.
If you do your processing under some other directory, make sure that
your non-root user account is a member of the group that owns the
directory, make sure that the group has read, write, and execute
the directory, and make sure that the
A couple of environment variables used by
$ cd ~/src/linux-source-3.2 $ CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) \ > MODULE_LOC=~/src/modules make-kpkg ...
In the prefix method, the environment variables are specified as
prefixes to the
In the export method, the environment variables are set as ordinary
variables in the current shell, then they are marked for export using
the shell's "export" command.
$ cd ~/src/linux-source-3.2 $ CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) $ MODULE_LOC=~/src/modules $ export CONCURRENCY_LEVEL MODULE_LOC $ make-kpkg ...
Optionally, the assignment of a value can take place on the export
$ cd ~/src/linux-source-3.2 $ export CONCURRENCY_LEVEL=$(getconf _NPROCESSORS_ONLN) \ > MODULE_LOC=~/src/modules $ make-kpkg ...
Either way, the shell variables listed on the export command are
passed to every subsequent command, whether you
want them to be or not, including
Note: it is important to distinguish between an environment variable and a make variable. A make variable is only used with the make command, must be assigned a value on the make command line, and comes after the command name, not before it. KDEB_PKGVERSION is an example of a make variable.
Since I initially announced this page on the
Given: a computer of the i386 architecture
with an Nvidia graphics
card, chipset GeForce2 MX/MX 400, running Debian Wheezy (7.1).
To accomplish: build a custom kernel from Debian kernel sources (3.2.46) that uses the proprietary "nvidia" X driver.
Note: it is not necessary to build a custom kernel in order to use the nvidia driver. There are other installation methods available that will allow the nvidia driver to be used with an official stock Debian kernel image package. But if you need or want to build a custom kernel for other reasons, and you also want to use the nvidia driver, this is the traditional Debian way to do it.
The first step is to determine which kernel module source package you
At the time of this writing
there are four nvidia kernel module source packages:
Note: if you don't know which chipset your Nvidia
graphics card uses, the easiest way to find out is to use the
My first attempt at this was on a computer which has an Nvidia graphics
card with a RIVA TNT2 chipset, which requires the
My second attempt, which is documented here, was on a computer which
has an Nvidia graphics card with a GeForce2 MX/MX 400 chipset,
which requires the
OK, now let's get started.
We assume that the login shell belongs to steve.
$ su # aptitude install linux-source-3.2 # aptitude install kernel-package # aptitude install libncurses5-dev zlib1g-dev # aptitude -R install nvidia-kernel-legacy-96xx-source # vi /etc/kernel-pkg.conf . . (change maintainer's name and e-mail address) . ZZ # exit $ cd /usr/src $ tar -xjf linux-source-3.2.tar.bz2 $ rm linux-source-3.2.tar.bz2 $ rm linux-patch-3.2-rt.patch.bz2 $ tar -xjf nvidia-kernel-legacy-96xx-source.tar.bz2 $ rm nvidia-kernel-legacy-96xx-source.tar.bz2 $ cd linux-source-3.2 $ cp /boot/config-3.2.0-4-686-pae .config $ make menuconfig $ make-kpkg --append-to-version -4custom01-686-pae \ > --revision 3.2.46-1 --initrd --rootcmd fakeroot \ > kernel_image modules_image
If you wish to specify which of the installed kernel module source
packages to build, use the
Note that the directory name does not necessarily match the package
name; so be sure to use the directory name(s).
In the specific case of the
It is possible to build the module packages separately,
but the kernel package
must be built first.
Otherwise, you will get errors involving "genksyms not found",
or something like that.
If you build the module package(s) separately, make sure to use the
Note that you do not need to build or install kernel headers packages
when using this installation method.
They are not needed because you have the kernel source package installed,
and the kernel headers are included as part of the kernel source.
Also, avoid installing packages such as
$ cd .. $ su # dpkg -i linux-image-3.2.46-4custom01-686-pae_3.2.46-1_i386.deb # aptitude install nvidia-kernel-common # dpkg -i nvidia-kernel-legacy-96xx-3.2.46-4custom01-686-pae_96.43.23-3+3.2.46-1_i386.deb
It is important to install both the custom kernel image package
# aptitude install nvidia-glx-legacy-96xx # aptitude clean
Section "Device" Identifier "Configured Video Device" Driver "nvidia" EndSection
You can tweak it later if you like, but right now we just want
to make sure that the nvidia driver gets loaded.
Now enroll in the "video" group all non-root users
on the system that might
possibly start or use the X server, if they aren't
# adduser steve video # adduser candy video
Now shutdown and reboot. It should work. For help with troubleshooting, see this link. After rebooting, you might want to consider purging the stock kernel, since your system now depends on the nvidia kernel module, which doesn't exist in the stock kernel. You may also delete the package files (.deb files) that you created in /usr/src, now that they have been installed.
This example illustrates how to use out-of-kernel-source-tree
kernel module source packages which are not designed for use
All the assumptions for the previous specific example (except those involving Nvidia hardware and software) are repeated here. We add the additional assumption that you have already verified that you have an internal modem physically installed and recognized by lspci or lsusb that is supported by this driver. (This package also supports certain USB modems as well.) We also add the assumption that no previous attempts have been made to install this driver, either through Debian packages or using native upstream installation methods. We also make the assumption that you are using a real-time preemption kernel (3.2.0-4-rt-686-pae). This is not a requirement for the modem driver, but I wanted an example that uses real-time preemption.
The first thing we need to do is to disable the ALSA drivers
that want to take control of this modem.
Login as root, switch to directory /etc/modprobe.d, and
create a file called local.conf.
The contents should look like this:
Now, rebuild the initial RAM file system image file
for the running kernel, then shutdown and reboot.
# update-initramfs -uk $(uname -r) # shutdown -r now;exit
(The "$(uname -r)" substitutes the version name of the currently-running
In this case, it would be 3.2.0-4-rt-686-pae.)
After the reboot, login as a normal user and verify that snd_intel8x0m
is no longer loaded.
$ lsmod|grep snd_intel8x0m
OK, now it's time to install some stuff
$ su # aptitude install linux-source-3.2 # aptitude install kernel-package # aptitude install libncurses5-dev zlib1g-dev # vi /etc/kernel-pkg.conf . . (change maintainer's name and e-mail address) . ZZ # exit $ cd /usr/src $ tar -xjf linux-source-3.2.tar.bz2 $ rm linux-source-3.2.tar.bz2 $ bunzip2 linux-patch-3.2-rt.patch.bz2 $ cd linux-source-3.2 $ patch -p1 <../linux-patch-3.2-rt.patch $ rm ../linux-patch-3.2-rt.patch $ cp /boot/config-3.2.0-4-rt-686-pae .config $ make menuconfig $ fakeroot make-kpkg --append-to-version -4custom01-686-pae \ > --revision 3.2.46-1 --initrd kernel_image kernel_headers
Note that since the kernel_headers target is specified the entire
$ cd .. $ su # dpkg -i linux-headers-3.2.46-4custom01-686-pae-rt67_3.2.46-1_i386.deb # dpkg -i linux-image-3.2.46-4custom01-686-pae-rt67_3.2.46-1_i386.deb # shutdown -r now;exit
You should now be running your new kernel.
Login again as a normal user.
$ su # aptitude install dkms # aptitude install sl-modem-dkms sl-modem-daemon # aptitude clean
dkms should automatically build the slamr and slusb
kernel modules for the running kernel during installation
blacklist snd_intel8x0m blacklist slamr blacklist slusb
Why blacklist the new modules?
Because the init script will unload any driver modules it finds
for this modem, including slamr and slusb, then it will load slamr
So why load the appropriate module twice?
Blacklist it and it will only be loaded once.
(Remember, blacklisting a module only prevents udev
from loading it.
That is due to the fact that
when udev attempts to load a module, it uses the
# update-initramfs -uk $(uname -r) # shutdown -r now;exit
(This time, "$(uname -r)" substitutes as "3.2.46-4custom01-686-pae-rt67", since you are now running your new custom kernel.) Upon reboot, the modem drivers should be fully functional. Of course, to actually use the modem, you must install some type of user space package to access it, such as minicom, ppp, etc. Use device name /dev/ttySL0 to access the modem using these programs, rather than a traditional serial port device name (/dev/ttyS0, /dev/ttyS1, etc.). You might want to consider purging the original stock kernel at this point, since your system now depends on the slamr or slusb kernel module, which doesn't exist in the stock kernel. You may also delete the package files (.deb files) that you created in /usr/src, now that they have been installed.
Happy Kerneling! If anyone has any comments, suggestions, complaints, corrections, or any other form of feedback, please drop me a line at firstname.lastname@example.org.
Return to my home page