8.10. Å kompilere en kjerne
Kjernene som Debian leverer har med flest mulig funksjoner, samt et maksimalt antall drivere, for å dekke det bredeste spekteret av eksisterende maskinvareoppsett. Dette er grunnen til noen brukere foretrekker å rekompilere kjernen for bare å ta med det de spesifikt trenger. Det er to grunner for dette valget. For det første kan det være å optimalisere minneforbruk, ettersom kjernekoden, selv om den aldri blir brukt, opptar minne uten nytteverdi (og aldri "går ned" til vekselminne, siden det er selve RAM den bruker), som kan redusere den totale systemytelsen. En lokalt utarbeidet kjerne kan også begrense risikoen for sikkerhetsproblemer siden bare en brøkdel av kjernen koden er kompilert og kjører.
Rekompilering av kjernen er også nødvendig hvis du ønsker å bruke bestemte funksjoner som bare er tilgjengelig som programfikser (og ikke er med i den standardversjonen av kjernen).
8.10.1. Introduksjon og forutsetninger
Ikke overraskende håndterer Debian kjernen i form av en pakke, som ikke er hvordan kjerner tradisjonelt har blitt kompilert og installert. Siden kjernen forblir under kontroll av pakkesystemet, kan den således fjernes rent, eller utplasseres på flere maskiner. Videre, skriptene knyttet til disse pakkene automatiserer samspillet med oppstartslasteren og initrd generatoren.
Oppstrøms Linux-kilder inneholder alt som trengs for å bygge en Debian-pakke fra kjernen. Men du trenger fortsatt å installere build-essential for å sikre at du har de verktøyene som kreves for å bygge en Debian-pakke. Videre, konfigurasjonstrinnet for kjernen krever libncurses5-dev-pakken. Til slutt vil fakeroot-pakken se til at Debian-pakken lages uten at administratorrettigheter benyttes.
Som alt som kan være nyttig i et Debian-system, Linux-kjernens kilder er tilgjengelig i en pakke. For å hente dem, bare installer
linux-source-version-pakken.
apt-cache search ^linux-source
kommando viser de ulike kjerneversjoner versjoner pakket av Debian. Den nyeste versjonen er tilgjengelig i
Unstable -distribusjonen. Du kan hente dem uten mye risiko (spesielt hvis APT er konfigurert i henhold til instruksjonene fra
Seksjon 6.2.6, «Å arbeide med flere distribusjoner»). Merk at kildekoden som finnes i disse pakkene ikke samsvarer nøyaktig med det som er publisert av Linus Torvalds og kjerneutviklere. Som alle distribusjoner, bruker Debian en rekke programfikser, som kan (eller kanskje ikke) finner sin vei inn i oppstrømsversjoner av Linux. Disse endringene omfatter backports av rettinger/funksjoner/drivere fra nyere kjerneversjoner, nye funksjoner som ikke ennå er (helt) fusjonert inn i det oppstrøms Linux-treet, og noen ganger til og med konkrete endringer i Debian.
Resten av dette avsnittet fokuserer på 3.16-versjonen av Linux-kjernen, men eksemplene kan selvsagt tilpasses den spesielle versjonen av kjernen som du ønsker.
Vi går ut fra at linux-source-3.16-pakken er blitt installert. Den inneholder /usr/src/linux-source-3.16.tar.xz
, - et komprimert arkiv av kjernens kilder. Du må pakke ut disse filene i en ny katalog (ikke direkte under /usr/src/
, siden det ikke er behov for spesielle tillatelser for å lage en Linux-kjerne): ~/kernel/
er hensiktsmessig.
$
mkdir ~/kernel; cd ~/kernel
$
tar -xaf /usr/src/linux-source-3.16.tar.xz
8.10.3. Å konfiguere kjernen
Det neste trinnet består i å konfigurere kjernen etter dine behov. Den nøyaktige fremgangsmåten avhenger av målene.
When recompiling a more recent version of the kernel (possibly with an additional patch), the configuration will most likely be kept as close as possible to that proposed by Debian. In this case, and rather than reconfiguring everything from scratch, it is sufficient to copy the /boot/config-version
file (the version is that of the kernel currently used, which can be found with the uname -r
command) into a .config
file in the directory containing the kernel sources.
$
cp /boot/config-3.16.0-4-amd64 ~/kernel/linux-source-3.16/.config
Unless you need to change the configuration, you can stop here and skip to
Seksjon 8.10.4, «Compiling and Building the Package». If you need to change it, on the other hand, or if you decide to reconfigure everything from scratch, you must take the time to configure your kernel. There are various dedicated interfaces in the kernel source directory that can be used by calling the
make target
command, where
target is one of the values described below.
make menuconfig
compiles and executes a text-mode interface (this is where the libncurses5-dev package is required) which allows navigating the options available in a hierarchical structure. Pressing the Space key changes the value of the selected option, and Enter validates the button selected at the bottom of the screen; Select returns to the selected sub-menu; Exit closes the current screen and moves back up in the hierarchy; Help will display more detailed information on the role of the selected option. The arrow keys allow moving within the list of options and buttons. To exit the configuration program, choose Exit from the main menu. The program then offers to save the changes you've made; accept if you are satisfied with your choices.
Other interfaces have similar features, but they work within more modern graphical interfaces; such as make xconfig
which uses a Qt graphical interface, and make gconfig
which uses GTK+. The former requires libqt4-dev, while the latter depends on libglade2-dev and libgtk2.0-dev.
When using one of those configuration interfaces, it is always a good idea to start from a reasonable default configuration. The kernel provides such configurations in arch/arch/configs/*_defconfig
and you can put your selected configuration in place with a command like make x86_64_defconfig
(in the case of a 64-bit PC) or make i386_defconfig
(in the case of a 32-bit PC).
8.10.4. Compiling and Building the Package
Once the kernel configuration is ready, a simple make deb-pkg
will generate up to 5 Debian packages: linux-image-version that contains the kernel image and the associated modules, linux-headers-version which contains the header files required to build external modules, linux-firmware-image-version which contains the firmware files needed by some drivers (this package might be missing when you build from the kernel sources provided by Debian), linux-image-version-dbg which contains the debugging symbols for the kernel image and its modules, and linux-libc-dev which contains headers relevant to some user-space libraries like GNU glibc.
The version is defined by the concatenation of the upstream version (as defined by the variables VERSION
, PATCHLEVEL
, SUBLEVEL
and EXTRAVERSION
in the Makefile
), of the LOCALVERSION
configuration parameter, and of the LOCALVERSION
environment variable. The package version reuses the same version string with an appended revision that is regularly incremented (and stored in .version
), except if you override it with the KDEB_PKGVERSION
environment variable.
$
make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1
[...]
$
ls ../*.deb
../linux-headers-3.16.7-ckt4-falcot_3.16.7-1_amd64.deb
../linux-image-3.16.7-ckt4-falcot_3.16.7-1_amd64.deb
../linux-image-3.16.7-ckt4-falcot-dbg_3.16.7-1_amd64.deb
../linux-libc-dev_3.16.7-1_amd64.deb
8.10.5. Compiling External Modules
Some modules are maintained outside of the official Linux kernel. To use them, they must be compiled alongside the matching kernel. A number of common third party modules are provided by Debian in dedicated packages, such as xtables-addons-source (extra modules for iptables) or oss4-source (Open Sound System, some alternative audio drivers).
These external packages are many and varied and we won't list them all here; the apt-cache search source$
command can narrow down the search field. However, a complete list isn't particularly useful since there is no particular reason for compiling external modules except when you know you need it. In such cases, the device's documentation will typically detail the specific module(s) it needs to function under Linux.
For example, let's look at the xtables-addons-source package: after installation, a .tar.bz2
of the module's sources is stored in /usr/src/
. While we could manually extract the tarball and build the module, in practice we prefer to automate all this using DKMS. Most modules offer the required DKMS integration in a package ending with a -dkms
suffix. In our case, installing xtables-addons-dkms is all that is needed to compile the kernel module for the current kernel provided that we have the linux-headers-* package matching the installed kernel. For instance, if you use linux-image-amd64, you would also install linux-headers-amd64.
$
sudo apt install xtables-addons-dkms
[...]
Setting up xtables-addons-dkms (2.6-1) ...
Loading new xtables-addons-2.6 DKMS files...
First Installation: checking all kernels...
Building only for 3.16.0-4-amd64
Building initial module for 3.16.0-4-amd64
Done.
xt_ACCOUNT:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.16.0-4-amd64/updates/dkms/
[...]
DKMS: install completed.
$
sudo dkms status
xtables-addons, 2.6, 3.16.0-4-amd64, x86_64: installed
$
sudo modinfo xt_ACCOUNT
filename: /lib/modules/3.16.0-4-amd64/updates/dkms/xt_ACCOUNT.ko
license: GPL
alias: ipt_ACCOUNT
author: Intra2net AG <opensource@intra2net.com>
description: Xtables: per-IP accounting for large prefixes
[...]
8.10.6. Applying a Kernel Patch
Some features are not included in the standard kernel due to a lack of maturity or to some disagreement with the kernel maintainers. Such features may be distributed as patches that anyone is then free to apply to the kernel sources.
Debian distributes some of these patches in linux-patch-* or kernel-patch-* packages (for instance, linux-patch-grsecurity2, which tightens some of the kernel's security policies). These packages install files in the /usr/src/kernel-patches/
directory.
To apply one or more of these installed patches, use the patch
command in the sources directory then start compilation of the kernel as described above.
$
cd ~/kernel/linux-source-3.16
$
make clean
$
zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.0-3.17.1-201410250027.patch.gz | patch -p1
Note that a given patch may not necessarily work with every version of the kernel; it is possible for patch
to fail when applying them to kernel sources. An error message will be displayed and give some details about the failure; in this case, refer to the documentation available in the Debian package of the patch (in the /usr/share/doc/linux-patch-*/
directory). In most cases, the maintainer indicates for which kernel versions their patch is intended.