Before we begin, we recommend this page for some information on how to build the kernel on a GNU/Linux Debian system. We are just describing the steps we went through for this particular system, but that tutorial is more generic and explains some of the options in more detail.
In our previous post, we fixed two problems someone was having with Debian on the Dell Inspiron 8500. With the screen resolution clean in Gnome and surfing the web over our wireless connection, we got started on building a custom kernel.
When we installed the “kernel-sources-2.6.8″ and “ndiswrapper-source” Debian packages on the system previosuly, two files were created in the “/usr/src” directory, “kernel-source-2.6.8.tar.bz2″ and “ndiswrapper-source.tar.bz2″. “kernel-source-2.6.8.tar.bz2″ contained the source code for the GNU/Linux 2.6.8. kernel in a bzip2 compressed tar archive, and that was what we dealt with first.
To extract the source code, we ran “tar -xvjf kernel-source-2.6.8.tar.bz2″ in the “/usr/src” directory. This created a directory “kernel-source-2.6.8″. We removed the old “/usr/src/linux” symbolic link (“rm -rf /usr/src/linux”) and added a new one (“ln -s /usr/src/kernel-source-2.6.8 /usr/src/linux”). By default, virtually everything would be enabled in the kernel configuration and almost all of these enabled features would be loaded as kernel modules (i.e., not compiled directly into the kernel, but rather, compiled into their own object files and loaded as needed by the kernel). If the kernel was built this way, there would be a large number of kernel modules, many of which would never be needed for the system we were running on. For us, we wanted to configure the kernel in order to support the hardware of the laptop and potential additions to the laptop, but not everything under the sun.
To do this, we ran a “dmesg | less” to see what the output from the kernel was during boot up, including the hardware detected. With this information, we could go in and configure the kernel specifically for the system it was running on. The easiest way we found to configure the kernel was to run “make menuconfig” from the “/usr/src/linux” directory. This presented us with a clean menu for walking through the kernels features. From there, we took the output of “dmesg” and determined what could be safely enabled/disabled. For example, we were configuring this kernel for a laptop and the Dell Inspiron 8500 contains a mobile Pentium 4 with speedstep, so we wanted to turn on power management features and cpufreq. Additionally, for this laptop in particular, most of the main hardware functionality was provided by Intel components, the video card was an nVidia, and the onboard NIC was a Broadcom.
Once we had completed configuring the kernel options, it was time to build the kernel. Since this was a Debian system, we did this the Debian way. If not already installed, we needed to install the Debian “kernel-package” package. (Fired up “aptitude”, and searched for and installed “kernel-package”.) Since we were not going to be running as “root” during our build, we needed to use “fakeroot” to build the kernel image package correctly, so, if not already installed, we installed it. (Fired up “aptitude”, and searched for and installed “fakeroot”.)
Now, you may be wondering why we also extracted “ndiswrapper-source” in our previous post. Well, this kernel module was specific to the kernel it was built for but was not part of the main kernel tree, so it would not automatically be built as part of our kernel build. However, Debian made it easy for us to build this as we build our kernel. When we extracted “ndiswrapper-source.tar.bz2″, it was placed in “/usr/src/modules/ndiswrapper”, which was where it needed to be for the command we were about to execute.
Ok, so we had configured the kernel, and we were now ready to build. The following command wes what we executed to create a custom kernel image and “ndiswrapper” Debian packages.
- fakeroot make-kpkg clean
- fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers kernel_doc modules_image
What did this do?
- “fakeroot make-kpkg clean” cleaned out the kernel source tree from the last build so that no conflicts or other mismatchings came up. For example, we have seens posts about there being a revision conflict detected in the Debian changelog during build when using “–revision” – this could be solved by doing a make clean.
- “fakeroot make-kpkg –append-to-version=.11092005 –revision=10.00.Custom –added-modules=ndiswrapper kernel_image kernel_headers modules_image” built a kernel (“kernel_image”) labeled with the version number 2.6.8.11092005 (“–append-to-version”) and created a Debian package (“make-kpkg”) for it, generated kernel headers (“kernel_headers”) Debian package (“make-kpkg”) for this kernel labeled with the version number 2.6.8.11092005 (“–append-to-version”), and built the ndiswrapper source (“–added-modules”) for the ndis kernel module (“modules_image”) labeled for kernel version 2.6.8.11092005 (“–append-to-version”) and created a Debian package for it (“make-kpkg”). All of the Debian packages included the revision identifier (“–revision”) in their filenames, which was the extent of the use of “–revision”.
These packages were all placed in the “/usr/src” directory ending with “.deb”. To install them (you must be root), we ran “dpkg -i <.deb package name>”, where “<.deb package name>” is the name of the package to be installed, and started with the kernel image. Since the software was packaged with the custom version numbers appended to their names, there was no need to put the packages on hold.
The laptop we were using used “grub” as its bootloader. When the kernel-image was installed from the Debian package, it automatically updated “/boot/grub/menu.lst” using “update-grub”; however, not everything was setup correctly for this to work properly.
Since we installed our custom ndiswrapper kernel module, we wanted to be sure all of our kernel module dependencies are configured. In order to do so, we ran “depmod -v 2.6.8.11092005″.
Our kernel was installed as “/boot/vmlinuz-2.6.8.12092005″, a System.map was created as “/boot/System.map.2.6.8.11092005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.11092005″. There was no “initrd-img” created for this kernel. To create the “initrd-img”, we ran “mkinitrd -o /boot/initrd-img-2.6.8.11092005 2.6.8.11092005″.
Next, we ran “update-grub” and rebooted, selecting our new kernel 2.6.8.11092005. All went well, but if it had not, we would have booted into an older kernel, uninstalled the packages, reconfigured our custom kernel, rebuilt the packages, reinstalled the packages, and rebooted.
We are good to go.
[...] As has been read numerous times in previous Debian posts on this blog, I fired up “aptitude” and searched for “loop-aes”. Lo and behold, there it was. I installed the “loop-aes-source” and “loop-aes-utils” Debian packages. Now, as described in the previous post, the “loop-aes-source” was the code for kernel module, and so it had to be custom built for the custom kernel I was running. Well, as we saw before, that can be quite easy. [...]