J'aimerais essayer d'utiliser un noyau autre que celui fourni par ma distribution - soit d'ailleurs, soit personnalisé par moi. Est-ce difficile ou dangereux ?

Par où commencer ?

Réponse acceptée :

Construire un noyau personnalisé peut prendre du temps - principalement dans la configuration, puisque les ordinateurs modernes peuvent faire la construction en quelques minutes - mais ce n'est pas particulièrement dangereux si vous conservez votre noyau actuel et fonctionnel et assurez-vous de le laisser en option via votre chargeur de démarrage (voir l'étape 6 ci-dessous). De cette façon, si votre nouveau ne fonctionne pas, vous pouvez simplement redémarrer l'ancien.

Dans les instructions suivantes, les chemins à l'intérieur de l'arborescence source prennent la forme [src]/whatever , où [src] est le répertoire dans lequel vous avez installé la source, par ex. /usr/src/linux-3.13.3 . Vous voulez probablement faire ce genre de choses su root car l'arborescence source doit rester sécurisée en termes d'autorisations d'écriture (elle doit appartenir à root).

Bien que certaines étapes soient facultatives, vous devriez quand même les lire car elles contiennent des informations nécessaires pour comprendre le reste du processus.

1. Téléchargez et décompressez l'archive source.

   Ceux-ci sont disponibles sur kernel.org. Les derniers sont répertoriés sur la première page, mais si vous regardez à l'intérieur du /pub/ répertoire, vous trouverez une archive remontant jusqu'à la version 1.0. À moins que vous n'ayez une raison particulière de faire autrement, vous feriez mieux de choisir simplement la « dernière écurie ». Au moment d'écrire ces lignes, il s'agit d'un tar.xz de 74 Mo fichier.

   Une fois l'archive téléchargée, vous devez la décompresser quelque part. L'endroit normal est dans /usr/src . Placez-y le fichier et :

   tar -xJf linux-X.X.X.tar.xz
   

   Notez que les distributions individuelles recommandent généralement d'utiliser l'un de leurs packages source au lieu de l'arbre vanilla. Celui-ci contient des correctifs spécifiques à la distribution, qui peuvent ou non vous intéresser. Il correspondra également aux en-têtes d'inclusion du noyau utilisés pour compiler certains outils de l'espace utilisateur, bien qu'ils soient très probablement identiques de toute façon.

   En plus de 15 ans de création de noyaux personnalisés (principalement sur Fedora/Debian/Ubuntu), je n'ai jamais eu de problème avec la source vanilla. Cela ne fait pas vraiment de différence, cependant, au-delà du fait que si vous voulez le dernier noyau absolu, votre distribution ne l'a probablement pas encore emballé. Donc, la route la plus sûre est toujours d'utiliser le paquet de distribution, qui devrait s'installer dans /usr/src . Je préfère la dernière écurie pour pouvoir jouer le rôle de cobaye avant qu'elle ne soit déployée dans les distributions 🙂

2. Commencez par une configuration de base [facultatif].

   Vous n'avez pas à le faire - vous pouvez simplement plonger et créer une configuration à partir de zéro. Cependant, si vous n'avez jamais fait cela auparavant, attendez beaucoup d'essais et d'erreurs. Cela signifie également devoir lire la plupart des options (il y en a des centaines). Un meilleur pari est d'utiliser votre configuration existante, si disponible. Si vous avez utilisé un paquet source de distribution, il contient probablement déjà un [src]/.config fichier, vous pouvez donc l'utiliser. Sinon, recherchez un /proc/config.gz . Il s'agit d'une fonctionnalité optionnelle ajoutée dans le noyau 2.6. S'il existe, copiez-le dans le niveau supérieur de l'arborescence des sources et gunzip -c config.gz > .config .

Si elle n'existe pas, c'est peut-être parce que cette option a été configurée en tant que module. Essayez les sudo modprobe configs , puis vérifiez le /proc répertoire pour config.gz à nouveau.

La configuration de la distribution n'est pas très idéale dans le sens où elle inclut presque tous les pilotes matériels possibles. Cela n'a pas beaucoup d'importance pour les fonctionnalités du noyau, car ce sont des modules et la plupart d'entre eux ne seront jamais utilisés, mais cela augmente très considérablement le temps nécessaire à la construction. Il est également gênant dans la mesure où il nécessite un initramfs pour contenir certains modules de base (voir l'étape 4 ci-dessous). Cependant, c'est probablement un meilleur point de départ que la valeur par défaut.

Notez que les options de configuration changent et changent d'une version du noyau à l'autre, et lorsque vous exécutez l'un des make config programmes sous votre .config sera d'abord analysé et mis à jour pour correspondre à la nouvelle version. Si la configuration provient d'une version beaucoup plus ancienne, cela peut conduire à des résultats étranges, alors faites attention lorsque vous effectuez la configuration. AFAIK, cela ne fonctionnera pas du tout dans l'autre sens (en utilisant une configuration d'une version plus récente).

3. Créer un .config uration.

   [src]/.config est un fichier texte utilisé pour configurer le noyau. Ne modifiez pas ce fichier directement . Changer les options n'est souvent pas une simple question de remplacer un Y avec un N , etc; il existe généralement un ensemble d'interdépendances et de possibilités de ramification. Au lieu de cela, vous souhaitez utiliser l'une des cibles de configuration du fichier makefile du noyau (ce qui signifie, entrez make _____ sur la ligne de commande depuis le répertoire source de niveau supérieur) :

   • make config est le plus basique mais probablement pas au goût de la plupart des gens. C'est une séquence de questions - beaucoup de questions - et si vous changez d'avis, vous devez recommencer.

   • make oldconfig est comme make config sauf si vous avez déjà un .config d'une version précédente, ignorera les questions sauf celles relatives aux nouvelles options. Il peut encore y en avoir beaucoup et la plupart d'entre eux ne seront pas pertinents pour vous, donc encore une fois, je ne le recommande pas.

   • make menuconfig est ma méthode préférée (et je pense que la plupart des autres). Il construit et exécute une interface TUI (menus colorés qui fonctionneront sur un terminal). Cela nécessite que vous ayez le -dev package pour ncurses installé. C'est assez explicite, sauf pour la recherche qui est accessible via /; l'« aide » F1 fournit une explication de l'option en cours. Il existe une version alternative, make nconfig , avec quelques fonctionnalités supplémentaires, où F2 "syminfo" est l'équivalent de F1 de menuconfig.

   • make xconfig est une interface graphique complète. Cela nécessite qmake et le -dev package pour Qt soit installé, car encore une fois, c'est un programme qui est compilé et construit. Si vous ne les utilisiez pas auparavant, cela peut représenter un téléchargement important. La raison pour laquelle je préfère menuconfig à la version GUI est que les hiérarchies d'options sont présentées à l'aide d'écrans successifs dans le premier mais ouverts en accordéon dans le second.

   L'une des premières choses à faire (mais pas obligatoire) est d'ajouter une chaîne "Version locale" (sous Configuration générale ). La raison en est mentionnée au point 5 ci-dessous.

   "Labyrinthine" est un bon moyen de décrire la hiérarchie des options, et entrer dans les détails avec elle dépasse largement la portée d'un Q&A comme celui-ci. Si vous voulez vous asseoir et tout parcourir, réservez heures . Greg Kroah-Hartman (développeur principal de longue date pour le noyau Linux) a un livre en ligne gratuit sur le noyau (voir les références ci-dessous) qui contient un chapitre sur la configuration, bien qu'il ait été écrit en 2006. Mon conseil est de commencer avec une base raisonnable à partir de votre noyau de distribution actuel (selon # 2), puis parcourez-le et décochez toutes les choses dont vous savez que vous n'avez pas besoin. Vous voudrez probablement aussi changer certaines des options du « module » en « intégré », ce qui nous amène au point suivant…

4. À propos de initramfs [facultatif]

   Un "initramfs" est un système de fichiers compressé intégré au noyau et/ou chargé au démarrage. Son objectif principal est d'inclure les modules dont le noyau aura besoin avant de pouvoir accéder à ceux de /lib/modules sur le système de fichiers racine - par exemple, les pilotes du périphérique contenant ce système de fichiers. Les distributions les utilisent toujours en partie parce que les pilotes sont mutuellement incompatibles et ne peuvent donc pas tous être intégrés au noyau. Au lieu de cela, ceux qui conviennent au système actuel sont sélectionnés à l'intérieur du initramfs .

   Cela fonctionne bien et ne représente aucun inconvénient, mais c'est probablement une complication inutile lors de la construction de votre propre noyau. Le hic, c'est que si vous n'utilisez pas d'initramfs, vous devez vous assurer que les pilotes de votre système de fichiers racine (et le périphérique sur lequel il se trouve) sont intégrés au noyau. Dans menuconfig , c'est la différence entre un M (=module) option et un * (=intégré). Si vous ne faites pas cela correctement, le système échouera au début du processus de démarrage. Ainsi, par exemple, si vous avez un disque dur SATA et un système de fichiers racine ext4, vous avez besoin de pilotes pour ceux intégrés. [Si quelqu'un peut penser à autre chose qui est indispensable, laissez un commentaire et je l'intégrerai ici].

   Si vous voulez utiliser un initramfs , vous devrez sélectionner les options appropriées dans Configuration générale . Il existe un guide squelette pour en créer un intégré au noyau dans [src]/Documentation/filesystems/ramfs-rootfs-initramfs.txt , mais notez que les distributions ne le font pas ; ils utilisent un fichier cpio externe compressé. Cependant, ce document contient une discussion sur ce qui devrait aller dans le initramfs (voir "Contenu de initramfs").

5. Construisez et installez le noyau.

   La prochaine étape est facile. Pour créer le noyau, exécutez simplement make dans le [src] annuaire. Si vous êtes sur un système multicœur, vous pouvez ajouter -j N pour accélérer les choses, où N est le nombre de cœurs que vous souhaitez dédier + 1. Il n'y a pas de test ou check . Une fois cela fait, vous pouvez make modules . Sur une box rapide, tout cela devrait prendre <10 minutes.

   Si tout se passe bien, make INSTALL_MOD_STRIP=1 modules_install . Cela créera un répertoire dans /lib/modules correspondant au numéro de version du noyau plus la chaîne "Version locale" mentionnée à l'étape 3, le cas échéant. Si vous n'avez pas utilisé de chaîne "Version locale", faites attention si vous avez déjà un noyau de la même version dont vous dépendez , car ces modules remplaceront ceux-là.INSTALL_MOD_STRIP=1 est facultatif, pour la signification voir ici.

   Vous pouvez alors make install pour installer le noyau à un emplacement par défaut. Ma recommandation, cependant, est de le faire vous-même pour vous assurer qu'aucun fichier existant ne soit écrasé. Regardez dans [src]/arch/[ARCH]/boot pour un fichier nommé bzImage , où [ARCH] est x86 si vous êtes sur une machine x86 ou x86-64 (et autre chose si vous êtes sur autre chose). Copiez-le dans /boot et renommez-le en quelque chose de plus spécifique et informatif (peu importe quoi). Faites la même chose avec [src]/System.map , mais renommez-le selon le schéma suivant :

   System.map-[VERSION]
   

   Ici, [VERSION] est exactement identique à le nom du répertoire dans /lib/modules créé par make modules_install , qui inclura la chaîne "Version locale", par exemple, System.map-3.13.3-mykernel .

6. Configurez le chargeur de démarrage GRUB 2.

   Si vous n'utilisez pas grub (la majorité des utilisateurs de bureau Linux le sont), cela ne s'applique évidemment pas à vous. Vous devriez avoir un /etc/grub.d/40_custom fichier avec pas grand-chose dedans. Sinon, créez-le appartenant à root et chmod 755 (il doit être exécutable). Ajoutez à cela :

   menuentry 'My new kernel, or whatever' {
       set root='hd0,1'
       linux /boot/[name-of-kernel] root=/dev/sda1 [other kernel options]
   }
   

   Si vous utilisez un initramfs, vous devriez également avoir une dernière ligne initrd /path/to/initramfs . Méfiez-vous du set root= doubler. L'exemple suppose que grub a été installé sur la première partition du premier disque dur (hd0,1). Si vous avez plusieurs lecteurs, vous pouvez utiliser l'UUID de la partition à la place et remplacer cette ligne par :

       search --no-floppy --fs-uuid --set=root [the UUID of the partition]
   

   À moins que grub ne soit pas sur votre système de fichiers racine, cela devrait également correspondre au root= directive sur linux ligne, qui indique votre système de fichiers racine (celui avec /sbin/init et /lib/modules ). La version UUID de celui-ci est root=UUID=[the UUID] .

   Vous pouvez regarder votre /boot/grub2/grub.cfg existant pour un indice sur le nom de l'appareil. Voici un bref guide pour cela sous grub 2. Une fois que vous êtes satisfait, exécutez grub2-mkconfig -o /boot/grub2/grub.cfg (mais sauvegardez votre grub.cfg actuel première). Vous pouvez ensuite modifier ce fichier et déplacer votre entrée vers le haut. Il doit toujours contenir une liste pour votre ancien noyau (en cours d'exécution), et votre distribution peut avoir un mécanisme qui duplique automatiquement une entrée pour le nouveau noyau (car il a été trouvé dans /boot; Fedora le fait, donc, en utilisant un titre distinct avec menuentry est une bonne idée). Vous pourrez le supprimer plus tard si tout se passe bien.

   Vous pouvez également simplement insérer le menuentry dans grub.cfg directement, mais certaines distributions écraseront cela lorsque leur noyau sera mis à jour (alors qu'en utilisant /etc/grub.d/ le maintiendra intégré).

   C'est ça. Il ne vous reste plus qu'à redémarrer. Si cela ne fonctionne pas, essayez de déduire le problème de la sortie de l'écran, redémarrez en choisissant un ancien noyau et revenez à l'étape 3 (sauf utilisez le .config vous avez déjà et modifiez cela). Il peut être judicieux de make clean (ou make mrproper ) entre les tentatives mais assurez-vous de copier [src]/.config à une sauvegarde d'abord, car elle sera effacée. Cela permet de s'assurer que les objets utilisés dans le processus de construction ne sont pas obsolètes.

7. Concernant les en-têtes du noyau et. al.

   Une chose que vous devriez probablement faire est le lien symbolique (ln -s -i ) /lib/modules/X.X.X/source et /lib/modules/X.X.X/build au /usr/src répertoire où se trouve l'arborescence des sources (conservez-le). Cela est nécessaire pour que certains outils de l'espace utilisateur (et installateurs de pilotes tiers) puissent accéder à la source du noyau en cours d'exécution.

   Un problème lié à ceci est .h fichiers dans /usr/include , etc. Celles-ci changent très progressivement et sont rétrocompatibles. Vous avez deux choix :

   • Laissez ceux utilisés par votre distribution. Si vous mettez à jour l'ensemble du système régulièrement, la distribution en installera de nouvelles périodiquement de toute façon, c'est donc l'option "la moins compliquée".

   • Utilisez make headers_install .

   Puisqu'ils sont rétrocompatibles (ce qui signifie "un programme construit avec une bibliothèque C utilisant des en-têtes de noyau plus anciens doit s'exécuter sur un noyau plus récent"), vous n'avez pas à être trop pointilleux à ce sujet. Le seul problème potentiel serait si vous construisez un noyau personnalisé et que vous le conservez pendant un certain temps, pendant lequel la distribution met à jour le package "kernel-headers" vers un plus récent version que celle utilisée pour construire votre noyau, et il s'avère qu'il y a une certaine incompatibilité (qui ne s'appliquerait qu'aux logiciels compilés ultérieurement à partir des sources).

En relation :Linux – la commande finger ne fonctionne pas ?

Références

Voici quelques ressources :

• [src]/README comprend un bref guide de construction et d'installation.

• Le [src]/Documentation contient beaucoup d'informations qui peuvent être utiles pour la configuration.

• Une grande partie du livre de Greg K-H Linux Kernel in a Nutshell (disponible ici gratuitement sous forme de série de PDF) tourne autour de la construction du noyau.

• Grub 2 a un manuel en ligne.

Connexe:Env ou pas env?