Table des matières
Debian : Compiler un noyau avec "kernel-package"
Il y a de nombreuses raisons de vouloir compiler son noyau, de la simple curiosité pour cet élément central du système gnu/linux au besoin plus technique d'optimisation. Quel que soit votre objectif cette opération sur Debian est assez simple, en grande partie grâce au paquet “kernel-package”.
<note>Un signe $ précède les commandes qui ne nécessitent pas de droits administrateur ; un signe # précède celles qui nécessitent des droits administrateur (ces signes ne font <color red>PAS</color> partie des commandes). Les lignes qui ne commencent pas par un signe $ ou # correspondent au résultat de la commande précédente.
Les touches utilisées sont indiquées entre crochets, exemple [ctrl] pour la touche “contrôle”</note>
Récupérer les sources du noyau
Ça paraîtra une évidence à certains, mais pour compiler un noyau il faut posséder ses sources. Vous pouvez récupérer facilement les sources fournies par Debian en installant le paquet “linux-source” éventuellement suivi d'une version spécifique si plusieurs vous sont proposées. Si le paquet n'apparaît pas vérifiez bien que vos dépôts (fichier /etc/apt/sources.list, voir cette page) contient bien les lignes visant les paquets sources (commençant par “deb-src”).
Si vous êtes aventureux, ou avez besoin des derniers pilotes pour votre matériel, vous pouvez récupérer les sources du noyau Debian en cours de développement. Il suffit d'ajouter à votre fichier sources.list :
# Dépôt développement noyau Debian - Experimental ! deb http://kernel-archive.buildserver.net/debian-kernel/ trunk main deb-src http://kernel-archive.buildserver.net/debian-kernel/ trunk main
Ce dépôt a une priorité très basse, pour installer un paquet qui s'y trouve il faut le demander explicitement. Aucun risque de voir votre noyau courant mis à jour avec un paquet en provenance de “kernel-archive” automatiquement.
Les noyaux Debian font l'objet de patchs, pour corriger des bugs, appliquer des options spécifiques ou retirer des éléments dont la licence n'est pas compatible avec les standards de Debian (firmware…). Si cette valeur ajoutée ne vous intéresse pas, vous pouvez récupérer les sources “brutes” (on dit “vanilla”) sur kernel.org. Il n'y a en général pas de problème à utiliser des sources “vanilla”, à ceci près que certains paquets sources Debian pourraient ne pas compiler avec un noyau très récent (par exemple les pilotes de cartes graphiques fglrx ou Nvidia, Virtualbox, etc…
Attention aux sources dont la version contient le suffixe “-rc”, il s'agit de versions en plein développement, parfois (rarement) instables au point de pouvoir endommager le matériel.
Installer les bons outils
En dehors des sources, vous aurez besoin de :
- kernel-package
- build-essential (ce paquet provoquera à lui seul l'installation de tous les outils nécessaires, y compris “fakeroot”)
- fakeroot (facultatif, voir ci-dessous)
- bzip2
- libncurse5-dev (pour “menuconfig” et “nconfig”)
- libqt3-mt-dev (pour “xconfig”, facultatif)
- libglib2.0-dev, libglade2-dev, libgtk2.0-dev (pour “gconfig”, facultatif)
Les autres paquets nécessaires seront installés automatiquement à titre de dépendances.
Le paquet “fakeroot” n'est nécessaire que si vous voulez compiler le noyau en espace utilisateur et ne pas avoir à invoquer les droits root (nécessaires uniquement pour l'installation finale). La méthode recommandée consiste à créer un répertoire de compilation dans votre répertoire personnel (on trouve aussi des adeptes de /tmp, /usr/local/src, etc…, le tout étant d'avoir des droits d'écriture sur le répertoire), effectuer toutes les opérations de compilation comme utilisateur, et d'utiliser “fakeroot” afin de créer un paquets “.deb” dont les permissions seront correctes. Cette façon de faire a l'avantage de minimiser les risques d'erreur désastreuse en opérant avec des droits root, dans /usr/src/ où sont stockées les éventuelles autres sources et “headers” (en-tête) des noyaux installés.
Si vous procédez de cette manière les droits root ne seront nécessaires que pour installer le(s) paquet(s) créé(s).
Ici nous effectuons la compilation dans /usr/src, j'indiquerai la seule commande qui soit différente entre ces deux méthodes, tout le reste est identique. Pour pouvoir travailler dans /usr/src sans invoquer les droits root à chaque commande, vous pouvez ajouter votre utilisateur au groupe “src”:
<code># usermod -a -G src utilisateur $ newgrp src
Remplacez “utilisateur” par votre identifiant.
Configuration de "kernel-package"
Si vous opérez sur Debian “Lenny” il n'y a rien de plus à faire qu'installer le paquet. Si en revanche vous utiliser une version de “kernel-package” égale ou supérieure à “12.001”, vous devrez prêter une attention particulière à la configuration.
Les dernières versions de “kernel-package” sont plus souples, mais au prix d'un peu de complexité. Par défaut la commande “make-kpkg” ne créera rien d'autre qu'une paquet binaire “.deb” à partir des sources du noyau. Pas de création d'initrd (même avec l'option “--initrd”), pas de gestion des liens symboliques, pas de rafraîchissement du chargeur d'amorçage… Ceci signifie que sans configuration de votre part vous ne pourrez vraisemblablement pas démarrer sur le noyau nouvellement créé !
Pour obtenir un comportement plus proche des versions antérieures, vous devrez copier les scripts “modèles” présents dans les sous-répertoires de /usr/share/kernel-package/examples/etc/kernel/*.d, vers les sous-répertoires correspondant de /etc/kernel/*.d.
Aperçu des scripts exemples fournis :
$ ls -lR /usr/share/kernel-package/examples/etc/kernel/*.d /usr/share/kernel-package/examples/etc/kernel/header_postinst.d: total 4 -rwxr-xr-x 1 root root 1404 mai 1 23:00 link /usr/share/kernel-package/examples/etc/kernel/header_postrm.d: total 4 -rwxr-xr-x 1 root root 522 mai 1 23:03 link /usr/share/kernel-package/examples/etc/kernel/header_prerm.d: total 4 -rwxr-xr-x 1 root root 430 mai 1 23:04 link /usr/share/kernel-package/examples/etc/kernel/postinst.d: total 20 -rwxr-xr-x 1 root root 1380 mai 1 22:56 force-build-link -rwxr-xr-x 1 root root 3012 avr 13 00:16 grub_conf -rwxr-xr-x 1 root root 612 mai 1 23:15 initramfs -rwxr-xr-x 1 root root 3326 avr 13 00:16 symlink_hook -rwxr-xr-x 1 root root 587 mai 1 23:15 yaird /usr/share/kernel-package/examples/etc/kernel/postrm.d: total 16 -rwxr-xr-x 1 root root 692 mai 1 22:55 force-build-link -rwxr-xr-x 1 root root 2780 avr 13 00:17 grub_rm -rwxr-xr-x 1 root root 919 mai 1 23:16 initramfs -rwxr-xr-x 1 root root 770 avr 30 19:09 yaird
À titre indicatif uniquement, les scripts que j'utilise :
$ ls -lR /etc/kernel/*.d /etc/kernel/header_postinst.d: total 8 -rwxr-xr-x 1 root root 317 jun 22 22:21 dkms -rwxr-xr-x 1 root root 1404 mai 1 23:00 link /etc/kernel/header_postrm.d: total 4 -rwxr-xr-x 1 root root 522 mai 1 23:03 link /etc/kernel/header_preinst.d: total 0 /etc/kernel/header_prerm.d: total 4 -rwxr-xr-x 1 root root 430 mai 1 23:04 link /etc/kernel/postinst.d: total 16 -rwxr-xr-x 1 root root 317 jun 22 22:21 dkms -rwxr-xr-x 1 root root 612 mai 1 23:15 initramfs -rwxr-xr-x 1 root root 264 mar 19 21:16 initramfs-tools -rwxr-xr-x 1 root root 3331 sep 8 22:08 symlink_hook /etc/kernel/postrm.d: total 8 -rwxr-xr-x 1 root root 919 mai 1 23:16 initramfs -rwxr-xr-x 1 root root 220 mar 19 21:16 initramfs-tools /etc/kernel/preinst.d: total 0 /etc/kernel/prerm.d: total 4 -rwxr-xr-x 1 root root 615 fév 24 2009 dkms
À noter que certains scripts ne sont pas liés à “kernel-package” (“dkms, “initramfs-tools”).
Nous allons détailler un peu le rôle des différents scripts, et les éventuelles modifications à y apporter.
- “link” : Permet de générer les liens symboliques dans /lib/modules/$(uname -r) pour qu'ils pointent vers les “headers” correspondant. Utile si vous créez un paquet “linux-headers-*”.
- “initramfs” : Permet de générer un “initrd” à l'installation du noyau (et de l'effacer lors de sa désinstallation). Indispensable si vous utilisez un “initrd”, à moins d'utiliser “update-initramfs -c -k (version-noyau)” manuellement. <color blue>Si vous installez “initramfs-tools” supérieur à 0.94 ce script n'est plus nécessaire, le disque initial de démarrage sera créé automatiquement.</color>
- “symlink_hook” : Permet de créer/mettre à jour les liens symboliques “vmlinuz” (lien vers le noyau) et “initrd.img” (lien vers l'initrd). Pas vraiment nécessaire vu que les chargeurs d'amorçage récents n'ont plus besoin de ces liens. Si vous utilisez “lilo” ou que vous souhaitez pouvoir utiliser des entrée de menu grub génériques pointant vers ces liens, c'est le script qu'il vous faut.
Modifiez la variable “SYMLINKDIR=” à votre convenance, par défaut elle pointe sur ”/“ (voir plus bas “kernel-img.conf” également à ce sujet).
Si vous n'en avez pas l'usage, vous pouvez également commenter les passages facultatifs, ça évite de laisser du code “mort” et de générer des erreurs inutilement :
# If you want version-specific links, here's how to start #STD24="$(grep vmlinuz-2.4 $outfile | head -n 1 | sed 's/vmlinuz-//')" || true #OLD24="$(grep vmlinuz-2.4 $outfile | head -n 1 | tail -n 1 | sed 's/vmlinuz-//')" || true #STD25="$(grep vmlinuz-2.5 $outfile | head -n 1 | sed 's/vmlinuz-//')" || true #"OLD25="$(grep vmlinuz-2.5 $outfile | head -n 1 | tail -n 1 | sed 's/vmlinuz-//')" || true
Cette partie (ligne 67) vise à créer plusieurs niveaux de liens symboliques par famille ou versions de noyaux. Si vous en avez l'usage vous devrez l'adapter à vos besoins. En fin de script vous pourrez également commenter la commande “lilo” si vous ne l'utilisez pas.
Par défaut le lien vers l'image du noyau portera le suffixe ”-rd“ (”/vmlinuz-rd“), cela permet de différencier le lien créé par “kernel-package” mais ça entraîne la création d'entrées de menu superflues par grub. Si vous voulez éviter ce comportement, éditez le script en changeant toutes les occurences de “vmlinuz-rd” par “vmlinuz” (on suppose qu'on se trouve dans le répertoire où est “symlink_hook”) :
$ sed -ne /vmlinuz-rd/p < symlink_hook
rm -f vmlinuz vmlinuz.old vmlinuz-rd vmlinuz-rd.old initrd.img initrd.img.old
ln -s "$vmlinuz_dir/"vmlinuz-$STD vmlinuz-rd
ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz-rd.old
# mv symlink_hook symlink_hook.original
# sed -e '/rm -f/!'s/vmlinuz-rd/vmlinuz/g < symlink_hook.original > symlink_hook
Ici on emploi “sed” pour rechercher les lignes qui contiennent le motif qu'on désire remplacer (“vmlinuz-rd”). Remplacer la première occurence dans la commande “rm -f…” n'est pas une bonne idée, si un lien “vmlinuz-rd” existe autant que le script le détecte et l'efface. On renomme donc le fichier original par sécurité (commande “mv”), et on utilise donc à nouveau “sed” pour remplacer uniquement les deux occurences suivantes. Le résultat est enregistré dans un nouveau fichier “symlink_hook”. Bien sûr vous pouvez utiliser n'importe quel éditeur de texte pour éditer “à la main” le script.
- “force-build-link” : Sert uniquement à forcer la création des liens symboliques (“build” et “source”) dans /lib/modules/$(uname -r) afin qu'ils pointent tous les deux vers les “headers”, même si les sources sont présentes. Ça n'est nécessaire que dans de rares cas, si vous voulez effacer le répertoire des sources après installation du noyau et des “headers”, vous pourrez toujours recréer les liens à la main.
- “grub_[conf|rm]” : Sert à lancer une mise à jour de grub lors de l'installation ou la désinstallation du noyau. Ce script ne concerne que “grub-legacy”, pas grub2. Le paquet “initramfs-tools” installe lui aussi des “hooks” qui lancent la mise à jour du chargeur d'amorçage, et la directive “do_bootloader = yes” ou bien l'appel à une commande comme :
postinst_hook = update-grub2 postrm_hook = update-grub2
peut être inclu dans /etc/kernel-img.conf (voir plus bas).
- “yaird” : “yaird” signifie “Yet Another mkInitRD” (“et encore un créateur d'initrd”) est une alternative (plus limitée) à “mkinitramfs” et “update-initramfs” (founis par “initramfs-tools”). Utilisez ce script si vous utilisez “yaird”.
En plus de ces scripts, vous pourrez prêter attention à /usr/share/kernel-package/examples/etc/sample.kernel-img.conf. Il contient des exemples de directives à ajouter si nécessaire à /etc/kernel-img.conf. (traduction libre)
# Si vous voulez que le lien symbolique (ou l'image, si "move_image" est utilisé)
# soit créé ailleurs que "/", modifiez cette variable pour indiquer la cible
# du lien. Ceci n'est pas une variable Boléenne.
# (Si "image_dest" et "link_in_boot" sont utilisées, "link_in_boot" l'emporte).
image_dest = /
# Cette variable concerne le lien symbolique "build" dans /lib/modules/$version.
# Si un répertoire d'en-têtes ("headers") est détecté, le lien "build" pointera
# vers celui-ci.
#relink_build_link = YES
# Si cette variable est utilisée, le script "preinst" essayera de
# déplacer un répertoire /lib/modules/$version déjà présent si une
# même version de noyau est installée.
# Option dangereuse, utilisez à vos risques et périles.
# Alternative : "dpkg -i --force-overwrite" (dangereux) pour installer
# le noyau de même version.
#clobber_modules = NO
Un exemple de fichier /etc/kernel-img.conf :
$ cat /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = no do_bootfloppy = no do_initrd = yes link_in_boot = no image_dest = /
D'autres variables sont disponibles, consultez /usr/share/kernel-package/docs/README. Regardez en particulier “reverse_symlinks” et “move_image” (à utiliser conjointement) si vous avez besoin de déplacer l'image du noyau “vmlinuz” ailleurs que dans /boot.
Autre modification importante, “kernel-package” n'assure plus aucun support pour l'application de patchs (”--added-patches“ n'existe plus), ceux-ci doivent être appliqués manuellement auparavant (avec “patch -p1 [--dry-run] < patch-$version” par exemple).
Configuration des sources du noyau
Vous devrez commencer par créer un répertoire qui accueillera les sources du noyau (ici /tmp/src, attention car /tmp est vidé au redémarrage, c'est donc un mauvais endroit si vous souhaitez conserver les sources), et décompresser celles-ci. Si vous avez récupéré les sources via les dépôt Debian l'archive se trouvera dans /usr/src/.
$ mkdir /tmp/src $ cd /tmp/src $ tar xjf linux-2.6.31.tar.bz2 $ cd linux-2.6.31
À adapter à votre version de noyau et votre répertoire de compilation. Si l'archive est au format ”.gz“ et non ”.bz2“ vous utiliserez “tar xzf”.
La première étape du processus est également la plus importante, il s'agit de créer le fichier ”.config“ qui va servir de règle à la compilation. C'est ce fichier qui fixe toutes les options de compilation, pour commencer il est conseillé de partir d'une configuration dont on sait qu'elle fonctionne, par exemple celle du noyau de la distribution, dont on copie le fichier /boot/config-$(uname -r) :
$ pwd /tmp/src/linux-2.6.31-vanilla $ cp /boot/config-$(uname -r) .config $ ls -la | grep config -rw-r--r-- 1 tux tux 82014 sep 11 11:33 .config
Facile, vous avez maintenant un fichier ”.config“ avec lequel configurer les sources :
$ make oldconfig
À ce stade vous avez un noyau configuré avec exactement les mêmes options que celui dont vous avez copié le fichier “config”. Si de nouvelles options (nouveaux pilotes…) de configuration sont apparues entre temps, lors du “make olconfig” il vous sera demandé de les initialiser en choisissant “No”, “Yes” ou “Module”.
Pour véritablement personnaliser le noyau il faut éditer le fichier ”.config“, soit directement avec un éditeur de texte (ou l'option “config”, qui revient à éditer ligne par ligne également), soit plus facilement au travers d'une des interfaces de configuration “menuconfig”, “xconfig” ou “gconfig”. Ici nous utiliserons “menuconfig” qui nécessite peu de dépendance, et est disponible même en console :
$ make menuconfig
Dans l'interface de “menuconfig” les différents raccourcis sont explicités en haut de la fenêtre. Si vous voulez des informations sur une option donnée (en Anglais…) il vous suffit de taper [?]. Pour effectuer une sélection on utilise [espace], et [tab] pour sélectionner les boutons au bas de la fenêtre.
Un aperçu de “xconfig”, qui s'ouvre dans une fenêtre indépendante :
Le but n'est pas de traiter ici des différentes options de configuration. Ces options changeant très régulièrement au grès des évolutions du noyau il vaut mieux vous référer à des sites spécifiques sur le sujet, voir la dernière section “Liens”.
Si vous ignorez ce qu'est un “initrd”, ou la différence entre compiler un pilote en temps que module ou “en dur” au sein du noyau, ou encore si vous n'avez jamais exécuté les commande “lspci” et “lsusb” sur votre machine, prenez le temps de vous documenter. 
La compilation proprement dite
Vous disposez maintenant d'un fichier de configuration, il ne reste plus qu'à passer à la compilation. La commande à employer diffère en fonction de la manière dont vous effectuez la compilation :
- Si vous compilez en espace utilisateur (ou dans /tmp/, etc…, bref là où vous avez des droits d'écriture), vous aller utiliser la commande “fakeroot” :
$ fakeroot make-kpkg --initrd --append-to-version -perso --revision 1 kernel-image kernel-headers
Dans cet exemple on suppose que vous désirez créer un “initrd” (option “--initrd”), et que vous voulez créer un paquet contenant les “headers” du noyau (option “kernel-headers” en plus du paquet “linux-image” (option “kernel-image”).
L'option “--append-to-version” permet de donner un suffixe personnalisé au noyau, celui-ci devrait être différent des suffixes standards des noyaux Debian afin d'éviter les confusions. Le répertoire devrait refléter ce nom également sous la forme “linux-source-suffixe_perso”.
L'option “--revision” permet de différencier plusieurs compilations d'un même noyau (même version, même suffixe).
- Si vous compilez dans /usr/src, vous devez utiliser la même commande, mais sans “fakeroot” et avec des droits root ("su" ou "sudo").
<note>Si vous disposez d'un processeur multi-cœurs, vous pouvez décider d'allouer plus de ressources processeur au processus de compilation. Par exemple pour un processeur “dual-core” la directive CONCURRENCY_LEVEL=2 dans /etc/kernel-pkg.conf provoquera l'utilisation des deux cœurs du processeur. Attention, la disponibilité du système pour d'autres tâches diminuera d'autant, mais le temps de compilation sera moindre.
Une autre possibilité est d'augmenter le nombre de “jobs” alloués à la compilation, tester avec deux fois le nombre de cœurs est une bonne base de départ. Sur un processeur quadri-cœur on pourra tester “make-kpkg -j 8 […]” par exemple.</note>
Installation du noyau, vérifications
La commande “make-kpkg” va créer un paquet ”.deb“ pour le noyau, éventuellement pour les “headers” si vous avez utilisé cette option, dans le répertoire de niveau supérieur aux sources (”../“). L'installation peut se faire simplement avec “dpkg” :
# dpkg -i linux-image-$version.deb linux-headers-$version.deb
Ensuite le(s) nouveau(x) paquets apparaîtront dans “apt-get” (Synaptic), “aptitude”, ou n'importe quel gestionnaire de paquets.
Si les bons scripts ont été utilisés lors de la configuration de “kernel-package”, et les bonnes options lors de la compilation (--initrd), vous pouvez normalement redémarrer tranquillement sur votre nouveau noyau. Dans la pratique il vaut mieux jeter un œil dans ”/boot“ et vérifier la présence de l'image “vmlinuz-$version” du nouveau noyau, celle de l'initrd si vous en utilisez un (“initrd.img-$version”), et vérifier que votre chargeur d'amorçage a bien été mis à jour pour prendre en compte le nouveau noyau. À vérifier également la présence des liens adéquats (“build” et “sources”) dans /lib/modules/$version, important si vous devez recompiler des modules externes (pilotes de carte graphique…). Enfin si vous utilisez les liens génériques ”/vmlinuz“ et ”/initrd.img“ contrôlez qu'ils pointent bien vers le noyau désiré.
N'oubliez pas qu'au redémarrage suivant vous devrez recompiler les éventuels modules externes, ça signifie que vous vous retrouverez souvent sans interface graphique si vous utilisez les pilotes propriétaires "fglrx" ou "nvidia".
Recompilation partielle
Si vous avez “manqué” une option dans la phase de configuration des sources, inutile de tout reprendre à zéro. Désinstallez (purge) le noyau s'il a déjà été installé (ça implique d'en avoir un autre sur lequel démarrer…), déplacez-vous dans le répertoire des sources et effacez le répertoire “debian”. En suite reprenez la configuration, puis relancez un “make-kpkg”.
Si vous n'avez plus que votre nouveau noyau et qu'il soit bancal, copiez le répertoire des sources quelque part (/tmp, etc…), effacez également le répertoire “debian” à l'intérieur du répertoire des sources que vous venez de copier, et reprenez le processus de configuration. Attention à donner un numéro de version ou un suffixe différent lors du “make-kpkg.
Voilà, c'est fini, la bonne nouvelle c'est que la phase de configuration de “kernel-package” n'est à effectuer qu'une fois. À la prochaine compilation il suffira de recopier l'ancien fichier ”.config”, et de passer directement à “make-kpkg”.
Bonne compil !
Liens
- "kernel-newbies" (eng), parfait pour un résumé des nouveautés du noyau.]]
- Liste de diffusion de Linus Torvald.Les discussions “chaudes”, très gros volume d'informations techniques, pas adapté au non spécialistes…
- "linuxfr.org" publie un résumé des nouveautés en Français, faites une recherche avec le mot “noyau” pour les versions plus anciennes.
Retour à la page "Debian"
Envoyer un message au mainteneur de la page