Le noyau Linux et Debian
Signature : | Mis en ligne le : 22/01/2009
Catégorie(s) :
  • GNU/Linux Magazine HS
  • | Domaine :
    Commentez

    Retrouvez cet article dans : Linux Magazine Hors série 28

    Avec une distribution aussi structurée et organisée que Debian GNU/Linux, le noyau occupe une place importante. En effet, celui-ci ne peut être considéré comme un simple paquet applicatif ou serveur. Son installation doit être aussi simple que celle d’un paquet mais sa reconstruction doit également permettre une grande souplesse. Pour gérer et manipuler correctement les sources et les versions binaires des noyaux Linux, le projet Debian a donc développé des outils spécifiques comme make-kpkg. Mais avant d’entrer dans le détail de la recompilation du noyau "façon Debian", voyons déjà l’aspect le plus simple : l’installation et la mise à jour. L’installation d’un noyau, ou plus exactement la mise à jour (puisque le système ne serait pas fonctionnel dans le cas contraire) se fait très simplement en utilisant apt-get. Mais encore faut-il choisir la bonne version pour votre machine. Le projet Debian met à disposition plusieurs variantes compilées et empaquetées du noyau Linux pour chaque version stable de ce dernier. Ainsi, pour la version 2.6.18 on trouve pas moins de neuf paquets : Les différents paquets se distinguent par le choix de la plate-forme dans la configuration des sources du noyau avant compilation. Le choix est relativement simple si vous connaissez votre matériel (ce que j’espère pour vous). Les paquets *xen* et *vserver* sont des versions "patchées" spécialement conçues pour fonctionner dans un environnement de para-virtualisation de type Xen ou Linux-Vserver. Note Les paquets *smp* destinés aux architecture multiprocesseurs n’existent plus. Toutes les versions binaires du noyau supportent à présent le SMP (Symmetric MultiProcessing). Une différenciation était faite car le support SMP utilisé sur un système monoprocesseur dégradait les performances avec les précédentes versions du noyau, ce qui n’est plus le cas à présent. Un paquet linux-image-2.6.X n’est pas un paquet comme les autres. Lors de son installation, il va générer un élément indispensable au fonctionnement et surtout au démarrage du système : l’image d’un disque mémoire d’initialisation initramfs. En effet, si vous jetez un œil au contenu du fichier linux-image-2.6.18-3-k7_2.6.18-7_i386.deb par exemple, vous constaterez que le fichier /boot/initrd.img-2.6.18-3-k7 n’est pas inclus. C’est, en effet, lors de l’utilisation d’apt-get install que le fichier est créé : mkinitramfs-kpkg est appelé pour créer le RAM Disk. Il ne s’agit en réalité que d’un "wrapper" pour mkinitramfs. Ceci est très important car l’image initramfs dépend fortement de votre configuration. Ainsi, si vous avez installé une solution de RAID logiciel, il est impératif que les scripts présents dans le RAM Disk configurent et activent le RAID avant le montage et le passage sur le système de fichier racine. Si vous changez votre configuration vers du RAID logiciel (par exemple comme détaillé dans l’article présent dans le GLMF HS 18), vous devrez utiliser update-initramfs afin de prendre le changement en compte pour le prochain démarrage et donc mettre à jour votre image initramfs. L’installation d’une nouvelle version du paquet noyau provoque également l’installation d’une nouvelle arborescence de modules noyaux dans /lib/modules. Le nom du répertoire créé dépend de la version du noyau et de sa révision. Ceci est fixé lors de la compilation du noyau et de la construction du paquet (voir plus loin). Accessoirement, si les sources utilisées pour la construction du noyau empaqueté sont installées, un lien symbolique sera ajouté entre /lib/modules/2.6.*/source et /usr/src/linux-source-2.6.*. Dans le cas contraire, apt-get ne manquera pas de signaler le problème (qui n’en est pas vraiment un) : Ce message est parfaitement normal lorsque vous installez un noyau provenant d’une distribution Debian puisque vous ne disposez pas de l’emplacement de construction original (/build/buildd/linux-2.6-2.6.18/debian/build/build-i386-none-k7 dans le cas présent).

    @ Recompilation d’un noyau Debian

    En principe, la recompilation d’un noyau n’est pas strictement nécessaire. Seuls certains cas particuliers d’optimisation ou d’activation de fonctionnalités justifient cela. Néanmoins, il est important pour un administrateur système de connaître le modus operandi façon Debian afin de respecter, le cas échéant, l’intégrité de la distribution. Trois paquets au minimum sont importants pour procéder :
    • les sources du noyau : linux-source-2.6.*
    • le paquet kernel-package fournissant, entre autres, le script de construction du paquet binaire make-kpkg
    • les fichiers d’en-têtes le la Libncurses, libncurses5-dev permettant la configuration du noyau via l’interface menuconfig (Libncurses/Dialog). Notez que cela n’est pas strictement nécessaire puisque le noyau dispose également d’une interface de configuration en ligne de commande par question/réponse. Enfin, si vous souhaitez quelque chose de plus convivial à la sauce GTK+ (make gconfig) ou Qt (make xconfig) il vous faudra installer d’autres paquets -dev.
    Voyons tout d’abord la manière la plus classique de recompiler et reconstruire un paquet binaire pour le noyau. Notez qu’il est possible de procéder aux manipulations qui suivent en tant qu’utilisateur normal (via fakeroot) mais j’ai pris le parti d’aller au plus simple en prenant l’identité root. En effet, la logique veut qu’une telle manipulation est faite dans le but d’installer un nouveau composant essentiel au système et donc qu’elle relève de la responsabilité du super-utilisateur. Le seul intérêt d’utiliser fakeroot est de se prémunir contre d’éventuelles erreurs de manipulations (pour les commandes sans fakeroot). Ce qui ne doit de toute façon pas arriver lorsque le super-utilisateur reconstruit un noyau. Commencez donc par installer les trois paquets cités plus haut puis placez-vous dans le répertoire /usr/src où vous trouverez linux-source-2.6.18.tar.bz2. Attention, il ne s’agit pas des sources d’origine (sources vanilla) du noyau Linux, contrairement à ce que le nom du fichier laisse entendre, mais une version spécifique à Debian et respectant normalement les DFSG (Debian Free Software Guidelines ou principes du Logiciel libre selon Debian). Désarchivez ensuite les sources avec tar xfj, vous obtiendrez une arborescence dans linux-source-2.6.18. Entrez dans ce répertoire. Plusieurs arguments peuvent être utilisés pour personnaliser la version et la révision du noyau ainsi que celle du paquet à construire. Dans un premier temps, nous utiliserons les valeurs par défaut nous permettant d’obtenir une version locale non conflictuelle capable de cohabiter avec une version du noyau identique à celle construite. Vous remarquerez, par exemple, que les modules installés par un paquet officiel sont placés dans /lib/modules/2.6.18-3-k7 qui correspond au paquet linux-image-2.6.18-3-k7. Le suffixe -3-k7 est ajouté par le responsable du paquet Debian précisément pour permettre aux utilisateurs de construire facilement leur noyau sans conflit. Notre première manipulation sera absolument sans intérêt si ce n’est didactique. Nous allons construire un paquet en tous points identique à celui fourni par Debian. Dans le répertoire des sources du noyau, copiez le fichier de configuration du noyau fourni par Debian de /boot/config-2.6.18-3-k7 en .config et lancez un make oldconfig pour vérification. Normalement rien ne vous sera demandé, oldconfig étant normalement utilisé pour adapter une configuration d’une précédente version du noyau à une nouvelle en interrogeant l’utilisateur sur les fonctionnalités non configurées au besoin. Ceci fait, il ne vous reste plus qu’à lancer le processus de construction avec : Notez la présence de l’option --initrd, indispensable pour générer toutes les actions nécessaires pour le RAM Disk d’initialisation lors de l’installation du paquet. Si, dans le cas présent, vous oubliez cette option, le système sera incapable de démarrer (le support IDE/SATA/SCSI est, par défaut, compilé sous forme de modules). Après un délai dépendant à la fois de votre ou vos processeurs et de la mémoire disponible, vous obtiendrez le fichier linux-image-2.6.18_2.6.18-10.00.Custom_i386.deb dans /usr/src. C’est, bien entendu, le paquet Debian correspondant à votre noyau fraîchement compilé que vous pourrez installer avec dpkg -i. A ce stade, vous disposez normalement de deux noyaux 2.6.18. Le premier installé depuis le dépôt Debian et compilé par le responsable officiel et le votre : La version Debian de notre noyau est s.Custom et celle officielle, 2.6.18. Le paquet Debian quant à lui possède respectivement les valeurs 2.6.18-7 et 2.6.18-3-k7, valeur que l’on retrouve sur le système une fois ce noyau booté avec : Nous allons maintenant construire un troisième noyau bien plus personnalisé. Première étape, dans le /usr/src/linux-source-2.6.18, nettoyez les sources et les informations de make-kpkg avec make-kpkg clean. Vous pouvez maintenant utiliser les deux options importantes de make-kpkg : --revision est destinée au système de paquet. Par défaut, la révision utilisée est $(version)-10.00.Custom soit le numéro de version du noyau plus une chaîne de caractères. C’est la version Debian telle qu’affichée par dpkg -l et qui vous permettra d’installer plusieurs noyaux concurrents sans conflit et sans que le système APT ne considère le nouveau paquet comme une mise à jour. Ce numéro de révision doit être composé uniquement de caractères alphanumériques et des caractères "+" et ".". De plus, il doit impérativement comporter un chiffre. Attention, lors de la première utilisation de cette option, sa valeur est enregistrée, au moins jusqu’à l’utilisation de make-kpkg clean. Sa valeur est stockée dans conf.vars et elle ne sera révisée que si stamp-configure et stamp-debian sont supprimés. Plus clairement, sans make-kpkg clean, vous ne pouvez pas utiliser cette option plusieurs fois de suite. En revanche, cela vous permettra de relancer une compilation partielle sur la même base de configuration Debian en omettant --revision. --append-to-version vous permet d’influer sur la vraie version du noyau et donc sur le nom du chemin de recherche des modules (variable EXTRAVERSION dans le Makefile du noyau). C’est la valeur qui apparaît avec uname -r. Il est important de prendre cela en compte car, si vous utilisez comme argument -3-k7 vous allez créer un conflit avec le paquet noyau déjà installé puisqu’ils partageront tous deux le même répertoire de modules, le même nom pour l’image RAM Disk et le fichier du noyau dans /boot. Ce numéro de version ne doit contenir que des caractères alphanumériques minuscules et les caractères "-", "." et "+". Relancez donc la configuration du noyau et apportez vos modifications, comme par exemple, la désactivation des fonctionnalités qui ne vous servent pas (PCMCIA, ISDN, FireWire, RAID, LVM, etc.). Enfin, relancez la construction avec : Note l’utilisation de make-kpkg clean est indispensable après avoir utilisé make menuconfig car cette dernière commande crée un fichier include/linux/version.h qui ne tient pas compte de votre --append-to-version. make-kpkg clean permet de nettoyer les sources, et donc le fichier version.h. make-kpkg ne crée le fichier que s’il n’existe pas déjà, mais ne le mettra pas à jour s’il existe. Après un délai normalement plus court puisque vous avez désactivé des fonctionnalités, vous obtiendrez le fichier linux-image-2.6.18-hs28-1-k7_1.0.lef_i386.deb. Installez-le comme à l’habitude puis observez la sortie de la commande dpkg -l : Et de trois ! Idem pour /lib/modules : Vous êtes maintenant en mesure de construire autant de paquets qu’il vous plaira jusqu’à obtenir une version qui vous convienne. Vous pouvez, par exemple, créer une version entièrement statique du noyau et donc vous abstenir d’utiliser --initrd. Idéal pour un serveur.

    @ Compilation de modules

    Entendez par "compilation de modules", la prise en charge de modules au format source qui ne sont pas intégrés dans la branche de développement officielle dunoyau linux. C’est le cas, par exemple, du support pour LIRC (récepteur infra-rouge), des Webcam spca5xx ou encore des modems USB ADSL Eagle. Les raisons de la non-inclusion dans les sources du noyau peuvent être diverses, code trop "sale" et problèmes de compatibilité avec Linus, problèmes liés aux licences ou encore utilisation d’objets binaires propriétaires (firmwares). Quoi qu’il en soit, Debian fournit quelques-uns de ces modules en version source et parfois binaire. Dans le cas de la version binaire, il faudra s’assurer de la compatibilité avec votre version du noyau. Les paquets sont normalement judicieusement nommés, mais ce n’est pas toujours le cas. D’autre part, ces version binaires s’installeront dans le répertoire des modules propres à la version Debian du noyau. Si vous avez compilé votre propre version, votre noyau ne les prendra pas en compte. Heureusement, pour régler le problème, nous disposons aussi des sources de ces modules en version empaquetée. C’est le cas, par exemple, du module pour LIRC, lirc-modules-source, que nous allons utiliser en guise d’exemple. Nous venons de compiler notre noyau ou allons maintenant nous attaquer au module pour LIRC. Pour cela, il nous suffit tout d’abord d’installer les sources du modules avec apt-get install lirc-modules-source, ce qui aura pour effet d’ajouter un fichier lirc-modules.tar.gz dans notre /usr/src. En désarchivant celui-ci, nous obtenons une arborescence /usr/src/modules/lirc contenant les sources adaptées par Debian. Entrez alors dans /usr/src/linux-source-2.6.18 et utilisez : Notez que nous devons réutiliser --append-to-version. --revision pour sa part n’est pas nécessaire puisqu’il est enregistré dans les sources du noyau suite à la compilation précédente. Vous pouvez d’ailleurs le constater dans les premières lignes qui défilent à l’écran. La page de manuel de make-kpkg est d’ailleurs très claire sur ce point : "Notez aussi qu’une fois que vous avez utilisé --append_to_version toto pour la configuration ou la construction du kernel-image, vous devez aussi utiliser la même option lors de lancements ultérieurs de make-kpkg (par exemple, pour construire des modules indépendants, ou autres). make-kpkg ne se souvient pas de l’argument toto à chacun des lancements de la commande (ce comportement est différent de --revision, qui est lui persistant lors des différents lancements)". C’est le seul point délicat de l’opération. Une fois la compilation terminée, vous trouverez un fichier lirc-modules-2.6.18-hs28-1-k7_0.8.0-9+1.0.lef_i386.deb dans /usr/src. Il s’installera comme précédemment avec dpkg. On retrouvera les modules compilés dans /lib/modules/2.6.18-hs28-1-k7/misc. Enfin, avec dpkg -l on retrouve bien notre nom de paquet lirc-modules-2.6.18-hs28-1-k7 et sa version 0.8.0-9+1.0.lef avec notre argument pour l’option passée précédemment via --revision. Je sais que j’insiste sur ce point, mais il faut bien comprendre que c’est la source de nombreux problèmes pour les utilisateurs qui construisent leur noyau avec une distribution Debian et compatible. La seule maîtrise de ces gestions de versions suffit à éviter 95% des problèmes et donc des plaintes dans les groupes de discussion, les listes de diffusion et les forums. Si vous voulez construire un paquet binaire pour le module de manière à ce qu’il s’ajoute aux modules installés par un paquet noyau Debian, vous devez utiliser --append-to-version= suivi d’une partie de la valeur retournée par uname -r (-1-k7 par exemple). Ceci fonctionne, mais il est fortement conseillé de compiler son noyau personnel et ensuite ses paquets de modules pour s’assurer d’une certaine cohérence. Des problèmes liés au compilateur peuvent apparaître, mieux vaut une configuration homogène et qui ne laisse pas planer de doute sur la responsabilité d’un développeur Debian (via un rapport de bogue, par exemple).

    @ Patch du noyau

    Un certain nombre de fonctionnalités d’un noyau Linux, lorsqu’elles ne sont pas intégrées dans les sources officielles, ne peuvent pas prendre la forme de modules. Soit parce qu’il s’agit d’un choix du développeur, soit parce que c’est techniquement impossible. La solution pour inclure les fonctionnalités proposées passe donc par la modification des sources du noyau avant compilation. Debian prend parfaitement en charge ce type de modification sous la forme de paquets contenant un patch. Il existe un certain nombre de ces paquets mais vous ne devez jamais considérer ceci comme un gage de sécurité de la part de Debian. Ceci concerne, par exemple, le paquet kernel-patch-2.6-reiser4 qui précise dans son descriptif que, non seulement il ne s’applique qu’à des noyaux en version 2.6.8 et 2.6.8.1, mais qu’il n’est absolument pas recommandé d’en faire usage sur une machine de production. Quoi s’il en soit, l’application du patch avant compilation est conditionnelle. Dans la configuration Debian du patch, on trouve les différentes versions du noyau auxquelles il peut s’appliquer. Si nous prenons le cas de kernel-patch-bootsplash, on retrouve une variable KVERSIONS dans le fichier /usr/src/kernel-patches/all/apply/bootsplash qui ne spécifie aucune version au-delà de 2.6.16. En fonction de la version du noyau compilé, c’est l’un des patchs présents dans /usr/src/kernel-patches/diffs/bootsplash qui sera appliqué. Note Bien que cela ne soit pas recommandé, il est parfois possible de forcer l’application d’un patch pour une version non prévue du noyau. L’utilitaire patch permet en effet une certaine tolérance (ce qui n’est pas le cas du code lui-même). En modifiant le contenu du fichier dans kernel-patches/all/apply/ on peut donc "forcer" l’application d’un patch en trompant le test et en ajoutant soi-même la nouvelle version. Une solution plus propre est, bien entendu, de générer un nouveau fichier .diff, de le tester et de le proposer au responsable du paquet. A ce point de l’article, l’installation d’un patch est relativement simple. Il suffit, en effet, d’installer le paquet correspondant, comme kernel-patch-bootsplash. Automatiquement une nouvelle arborescence /usr/src/kernel-patches est créée et peuplée. A l’instar des modules, l’ensemble des patchs sont installés dans cet unique répertoire. En revanche, il ne sont pas appliqués automatiquement mais doivent être clairement spécifiés dans la ligne de commande de make-kpkg. Ainsi pour notre exemple, nous utilisons : Nous constatons parmi les différentes étapes de la construction, l’application correcte du patch : Le message dépend du patch, tous ne sont pas aussi explicites quant à leur application. Notez que si vous appliquez plusieurs patchs, il faut les lister tous en argument de --added-patches séparés par des virgules. Le ou les patchs sont appliqués lors de la phase de configuration des sources, il sont "désappliqués" (unpatch) lors d’un make-kpkg clean. Certains patchs appliquent simplement ces changements dans le code, mais également dans la configuration. Dans le cas de kernel-patch-debianlogo par exemple, le fichier de configuration du noyau est également changé. La configuration des sources ayant lieu après l’application du patch, le changement est détecté (comme avec un oldconfig) et le système demande votre intervention : Les problèmes surviennent avec les machines limitées en ressources. En effet, sur un pauvre AMD Duron il serait intéressant de ne pas avoir à recompiler l’intégralité du noyau dans le cas où une version précédente identique mais non patchée est déjà compilée. Malheureusement, il ne semble pas y avoir de solution "propre". Il est impératif d’utiliser make-kpkg clean avant d’utiliser à nouveau make-kpkg kernel_image, et donc, de recommencer un cycle complet de compilation de longue durée. Ceci vous incitera sans doute à consulter l’ensemble des patchs intéressants ou nécessaires pour votre configuration AVANT de perdre du temps avec la construction d’un noyau "juste pour voir". Bien entendu, avec une configuration plus récente, voire dernier cri, la compilation n’est plus un problème. Il semblerait que les nouveaux processeurs fassent réellement des merveilles dans ce domaine (les utilisateurs Gentoo sont aux anges).

    @ Conclusion

    Comme précisé en début d’article, la recompilation du noyau, mais également de tous paquets binaires, doit être motivée. Dans la plupart des cas, elle ne sera pas nécessaire. Les distributions Debian sont déjà suffisamment modulaires pour offrir la majorité des fonctionnalités qu’un utilisateur puisse attendre. Vous remarquerez toutefois que, même pour ces manipulations qui restent donc rares, les outils développés et proposés sont exemplaires. Si vous comptez vous pencher davantage sur la construction de noyaux, et passer du temps à expérimenter les différents patchs, modules et paquets, je vous conseille vivement de vous inscrire aux différentes listes de diffusion des développeurs Debian. Vous pouvez également surveiller régulièrement le système de suivi de bogues (voir article sur le sujet dans le présent numéro). Vos résultats, vos problèmes et vos solutions peuvent être utiles, tout comme le temps que vous consacrerez à la tâche.

    Retrouvez cet article dans : Linux Magazine Hors série 28

    Vous souhaitez commenter cet article ?
    Brèves Flux RSS
    Édito : GNU/Linux Magazine Hors-Série N°72
    Édito : Linux Pratique N°84
    Édito : MISC N°74
    Édito : GNU/Linux Magazine N°173
    Édito : MISC Hors-Série N°9
    Communication RSS Com. RSS Presse
    HACKITO ERGO SUM
    GNU/Linux Magazine, partenaire du SymfonyLive Paris
    Opensilicium, partenaire de RTS EMBEDDED
    Linux Pratique et Linux Essentiel, Partenaire de l’Open World Forum
    Gnu/Linux Magazine, Partenaire des JDEV 2013
    Rechercher un article dans notre base documentaire :
    En kiosque Flux RSS

    Le tout nouveau GNU/Linux Magazine HS est disponible dès maintenant chez votre marchand de journaux et sur notre site marchand.

    Découvrez le sommaire de ce numéro et un aperçu de ce magazine...

    Lire la suite...

    Le tout nouveau Linux Pratique est disponible dès maintenant chez votre marchand de journaux et sur notre site marchand.

    Découvrez le sommaire de ce numéro et un aperçu de ce magazine...

    Lire la suite...

    Le tout nouveau Misc est disponible dès maintenant chez votre marchand de journaux et sur notre site marchand.

    Découvrez le sommaire de ce numéro et un aperçu de ce magazine...

    Lire la suite...

    Le tout nouveau GNU/Linux Magazine est disponible dès maintenant chez votre marchand de journaux et sur notre site marchand.

    Découvrez le sommaire de ce numéro et un aperçu de ce magazine...

    Lire la suite...

    Le tout nouveau Open Silicium est disponible dès maintenant chez votre marchand de journaux et sur notre site marchand.

    Découvrez le sommaire de ce numéro et un aperçu de ce magazine...

    Lire la suite...