Un guide pour compiler vous-même le noyau Linux

Un guide du bricoleur pour découvrir par vous-même la compilation du dernier noyau Linux.

Vous pourriez être intéressé par la compilation du noyau Linux vous-même, pour de nombreuses raisons. Il peut s'agir, sans toutefois s'y limiter, de l'un des éléments suivants :

Essayer un noyau plus récent que celui fourni par votre distribution Linux
Construire le noyau avec un ensemble différent d'options de configuration et/ou de pilotes
La curiosité d'un apprenant :)

Ce guide vous montrera comment compiler vous-même le noyau Linux, avec les commandes que vous devez exécuter, pourquoi exécuter ces commandes et expliquera ce qu'elles font. C’est long, alors préparez-vous !

🚧

Les distributions comme Ubuntu offrent des moyens plus simples d'installer le noyau Linux principal. Mais ce tutoriel consiste à faire les choses manuellement à partir du code source. style="white-space: pre-wrap;">Vous aurez besoin de temps, de patience et d'une bonne expérience avec la ligne de commande Linux pour ce didacticiel. Il s’agit davantage de vivre les choses de première main. Je conseille cependant de tenter cette aventure dans une VM ou sur votre système de rechange au lieu de la faire sur votre système principal.

Conditions préalables

Il y a deux conditions préalables pour construire quoi que ce soit (dans le contexte d'un logiciel).

Code source
Construire des dépendances

Ainsi, comme prérequis, nous allons télécharger les sources du noyau Linux sous forme d'archive tar et installer quelques dépendances qui nous permettront de construire le noyau Linux.

Introduction aux versions Linux

A un instant donné, il existe 4 "versions" du noyau Linux ~~Freax~~.

Ces « versions » de Linux, dans l'ordre du flux de développement, sont :

L'arborescence linux-next : Tout code à fusionner dans la base de code Linux est d'abord fusionné dans l'arborescence linux-next. Il s'agit de l'état le plus récent mais aussi le « moins stable » du noyau Linux. La plupart des développeurs et testeurs du noyau Linux l'utilisent pour affiner la qualité du code que Linus pourra extraire ultérieurement. Faites attention !
Communications RC/Mainline : Linus extrait de l'arborescence linux-next et crée une version initiale. La version bêta de cette version est appelée version RC (Release Candidate). Une fois qu'un RC est publié, Linus accepte uniquement les corrections de bogues et les correctifs liés à la régression des performances. Linus continue de publier un noyau RC chaque semaine jusqu'à ce qu'il soit satisfait du code (avec les retours des utilisateurs). Le suffixe -rc, suivi d'un numéro, est ajouté pour indiquer la version RC.
Versions stables : Une fois que Linus estime que la dernière version RC était stable, il publie la version finale "publique". Une version stable est maintenue pendant encore quelques semaines. C’est ce qu’utilisent les distributions Linux de pointe comme Arch Linux et Fedora Linux. Je vous recommande d'essayer ceci avant linux-next ou toute version RC.
Versions LTS : la dernière version stable d'une année donnée est maintenue pendant quelques années supplémentaires. Il s'agit généralement d'une version plus ancienne, mais elle est activement maintenue avec des correctifs de sécurité. Une version stable de Debian utilise la version LTS du noyau Linux.

Vous pouvez en savoir plus à ce sujet dans la documentation officielle.

Pour les besoins de cet article, j'utiliserai la dernière version stable disponible. Au moment de la rédaction de cet article, nous en sommes à la v6.5.5.

Préparer le système

Étant donné que le noyau Linux est écrit en langage de programmation C, vous avez besoin d'au moins un compilateur C pour compiler le noyau Linux. Il existe d'autres dépendances de ce type qui peuvent ou non être présentes sur votre ordinateur. Il est temps de les installer.

💡

Ce guide se concentrera sur la compilation du noyau Linux à l'aide du compilateur GNU C (GCC). Mais class="italic" style="white-space: pre-wrap;">peut-être dans un prochain article (plongée dans le support Rust) , je vais aborder l'utilisation du compilateur Clang de LLVM comme alternative à GCC.

Et non, MSVC ne compte pas. Cela dit, je m'attends à ce qu'un employé de Microsoft envoie un ensemble de correctifs pour cela. Qu'est-ce que j'ai fait?

Commande d'installation pour les utilisateurs d'Arch Linux et de ses dérivés :

sudo pacman -S base-devel bc coreutils cpio gettext initramfs kmod libelf ncurses pahole perl python rsync tar xz

Commande d'installation pour les utilisateurs de Debian et de ses dérivés :

sudo apt install bc binutils bison dwarves flex gcc git gnupg2 gzip libelf-dev libncurses5-dev libssl-dev make openssl pahole perl-base rsync tar xz-utils

Commande d'installation pour Fedora et ses dérivés :

sudo dnf install binutils ncurses-devel \
    /usr/include/{libelf.h,openssl/pkcs7.h} \
    /usr/bin/{bc,bison,flex,gcc,git,gpg2,gzip,make,openssl,pahole,perl,rsync,tar,xz,zstd}

Récupérer les sources du noyau Linux

Rendez-vous sur kernel.org et sur la page, recherchez la première version stable. Vous ne pouvez pas le manquer puisque c'est la plus grande boîte jaune ;)

Vous pouvez télécharger l'archive tar en cliquant sur la grande case jaune. Pendant que vous y êtes, téléchargez également le fichier de signature PGP correspondant. Cela nous sera utile lorsque nous vérifierons l’archive tar ultérieurement. Il porte l'extension .tar.sign.

Vérifier l'authenticité de l'archive tar

Comment savoir si l'archive tar que vous venez de télécharger est corrompue ou non ? Au niveau individuel, une archive tar corrompue ne fera que vous faire perdre de précieuses heures de bricolage, mais si cela est fait pour une organisation, vous pourriez faciliter la tâche d'un attaquant (à ce stade, vous aurez de plus gros problèmes à régler, mais n'abandonnons pas). SSPT à tous !).

Pour vérifier l'intégrité de notre archive tar, nous avons besoin de l'archive tar. Pour le moment, il est compressé à l'aide de l'algorithme de compression XZ. Par conséquent, j'utiliserai l'utilitaire unxz (simplement un alias pour xz --decompress) pour décompresser le fichier d'archive .tar.xz.

unxz --keep linux-*.tar.xz

Une fois extraites, nous récupérerons les clés publiques GPG utilisées par Linus Torvalds et Greg KH. Ces clés sont utilisées pour signer l'archive tar.

gpg2 --locate-keys [email  [email

Vous devriez obtenir un résultat similaire à celui que j'ai obtenu sur ma machine :

$ gpg2 --locate-keys [email  [email 
gpg: /home/pratham/.gnupg/trustdb.gpg: trustdb created
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman <[email >" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: key 79BE3E4300411886: public key "Linus Torvalds <[email >" imported
gpg: Total number processed: 1
gpg:               imported: 1
pub   rsa4096 2011-09-23 [SC]
      647F28654894E3BD457199BE38DBBDC86092693E
uid           [ unknown] Greg Kroah-Hartman <[email >
sub   rsa4096 2011-09-23 [E]

pub   rsa2048 2011-09-20 [SC]
      ABAF11C65A2970B130ABE3C479BE3E4300411886
uid           [ unknown] Linus Torvalds <[email >
sub   rsa2048 2011-09-20 [E]

Une fois les clés de Greg et Linus importées, l'intégrité de l'archive tar peut être vérifiée à l'aide de l'indicateur --verify ; ainsi:

gpg2 --verify linux-*.tar.sign

Si la vérification a réussi, vous devriez obtenir un résultat semblable à celui-ci :

$ gpg2 --verify linux-*.tar.sign
gpg: assuming signed data in 'linux-6.5.5.tar'
gpg: Signature made Saturday 23 September 2023 02:46:13 PM IST
gpg:                using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
gpg: Good signature from "Greg Kroah-Hartman <[email >" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 647F 2865 4894 E3BD 4571  99BE 38DB BDC8 6092 693E

Veuillez ne pas continuer à moins que vous ne voyiez un message indiquant gpg : Bonne signature !

💡

Vous pouvez ignorer en toute sécurité l'avertissement indiquant : AVERTISSEMENT : Cette clé n'est pas certifiée avec une signature de confiance ! Rien n'indique que la signature appartient au propriétaire.

Nous avons récupéré les clés dans les e-mails de Linus et Greg et n'avons pas à nous soucier de cet avertissement.

Extraire l'archive tar

Si vous êtes ici, cela signifie que la vérification de l'intégrité de votre archive tar s'est terminée avec succès. Il est maintenant temps d'en extraire les sources du noyau Linux.

Celui-ci est assez simple, il suffit de faire un tar -xf sur l'archive tar, comme ceci :

tar -xf linux-*.tar

L'option -x est utilisée pour spécifier l'extraction, et tar est informé du nom du fichier tarball à l'aide de l'option -f.

L'extraction prendra quelques minutes, ajustez et asseyez-vous droit :)

Configuration du noyau Linux

Le processus de construction du noyau Linux recherche un fichier .config. Comme son nom l'indique, il s'agit d'un fichier de configuration qui spécifie toutes les options de configuration possibles pour le noyau Linux. Il est nécessaire d'en avoir un.

Il existe deux méthodes pour obtenir ce fichier .config pour le noyau Linux :

Utiliser la configuration de votre distribution Linux comme base (recommandé)
Utilisation d'une configuration générique par défaut

💡

Il existe une troisième méthode dans laquelle vous pouvez configurer chaque option, à partir de zéro, à la main, mais attention, il existe plus de 12 000 options. Ceci n'est pas recommandé car cela prend beaucoup de temps pour tout configurer à la main et également suffisamment de savoir-faire pour savoir quoi activer et désactiver.

Utilisation de la configuration fournie par la distribution

Utiliser la configuration fournie par votre distribution Linux est une valeur sûre. Si vous suivez ce guide uniquement pour essayer un nouveau noyau que celui proposé par votre distribution, c'est la méthode recommandée.

Le fichier de configuration de votre distribution Linux pour le noyau Linux se trouvera à l'un des deux emplacements :

La plupart des distributions Linux comme Debian et Fedora, et leurs dérivés, le stockeront sous /boot/config-$ (uname -r).
Certaines distributions Linux comme Arch Linux l'ont intégré dans le noyau Linux lui-même. Par conséquent, il sera disponible sur /proc/config.gz.

💡

Si vous disposez des deux destinations, préférez utiliser /proc/config.gz car il se trouve sur un système de fichiers en lecture seule et donc non altéré.

Entrez le répertoire qui contient l’archive tar extraite.

cd linux-*/

Ensuite, copiez le fichier de configuration de votre distribution Linux :

## Debian and Fedora's derivatives:
$ cp /boot/config-"$(uname -r)" .config

## Arch Linux and its derivatives:
$ zcat /proc/config.gz > .config

Mise à jour de la configuration

Une fois cela fait, il est temps de « mettre à jour » le fichier de configuration. Vous voyez, il y a une forte probabilité que la configuration fournie par votre distribution soit plus ancienne que le noyau Linux que vous construisez.

💡

style="white-space: pre-wrap;">Cela s'applique également aux distributions Linux de pointe comme Arch Linux et Fedora. Aucun d'eux ne publie de mise à jour simplement parce qu'il y a une nouvelle version disponible. Ils effectuent un certain contrôle qualité, ce qui prendra forcément du temps. Et par conséquent, même le dernier noyau proposé par votre distribution aura quelques versions mineures en retard par rapport à ce que vous obtiendrez sur kernel.org.

Pour mettre à jour un fichier .config existant, la commande make est utilisée avec la cible olddefconfig. En panne, c'est une ancienne default configuration.

Cela prendra "l'ancien fichier de configuration" (qui est actuellement enregistré sous .config en tant que copie littérale de la configuration de votre distribution) et vérifiera toutes les nouvelles options de configuration qui ont été ajoutées à la base de code Linux depuis. Si de nouvelles options non configurées sont trouvées, la valeur de configuration par défaut de cette option est utilisée et le fichier .config est mis à jour.

Le fichier .config d'origine est renommé .config.old à mesure que la sauvegarde et les nouvelles modifications sont écrites dans .config.

make olddefconfig

Voici le résultat de ma machine :

$ file .config
.config: Linux make config build file, ASCII text

$ make olddefconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
.config:8593:warning: symbol value 'm' invalid for USB_FOTG210_HCD
.config:8859:warning: symbol value 'm' invalid for USB_FOTG210_UDC
#
# configuration written to .config
#

Pour les utilisateurs de Debian et de ses dérivés

Debian et ses dérivés utilisent un certificat pour signer les modules du noyau. Ce certificat, par défaut, est absent sur votre ordinateur.

Je recommande de désactiver l'option qui permet la signature du module. Cela peut être réalisé avec les commandes suivantes :

./scripts/config --file .config --disable MODULE_SIG

Ne pas le faire entraînera un échec de build plus tard, lorsque vous compilerez le noyau Linux. Vous êtes prévenu.

Utilisation d'une configuration personnalisée

Si vous étudiez la construction du noyau Linux dans le but d'apprendre le développement du noyau, voici la voie à suivre.

🚧

style="white-space: pre-wrap;">Il n'y a aucune garantie que s'écarter de la configuration de votre distribution Linux fonctionnera "normalement" sur votre class="italic" style="white-space: pre-wrap;">matériel physiquestyle="white-space: pre-wrap ;">. Le problème peut aller d'un élément matériel particulier qui ne fonctionne pas à un noyau Linux qui ne démarre pas du tout.

Par conséquent, il est recommandé de l'utiliser uniquement dans une VM.

Vous pouvez jeter un œil au résultat de make help pour voir toutes les options disponibles, mais nous nous concentrerons sur trois cibles make :

defconfig : La configuration par défaut.
allmodconfig : en fonction de l'état actuel du système, créez les éléments en tant que modules chargeables (au lieu d'intégrés) lorsque cela est possible.
tinyconfig : Un petit noyau Linux.

Puisque la cible tinyconfig ne construira que quelques éléments, les temps de construction sont naturellement plus rapides. Personnellement, je l'utilise pour les raisons suivantes :

Vérifier si les modifications que j'ai apportées au code/à la chaîne d'outils sont correctes et que le code se compile.
Tester uniquement quelques fonctionnalités sélectionnées dans une VM.

🚧

Lors de la création du noyau Linux pour les machines ARM ou RISC-V, vous aurez probablement besoin de DTB (binaires d'arborescence de périphériques). style="white-space: pre-wrap;">Le tinyconfigstyle=" white-space: pre-wrap;"> target n'activera pas l'option de création de DTB et votre noyau échouera très probablement au démarrage.

Cependant, vous pouvez utiliser QEMU pour démarrez le noyau Linux sans aucun DTB. Mais cet article ne se concentrera pas là-dessus. Peut-être devriez-vous commenter et me le faire savoir pour en parler plus tard ;)

Vous devez utiliser la cible defconfig à moins que vous sachiez exactement ce que vous faites. Voici à quoi cela ressemble sur mon ordinateur :

$ make defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/menu.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'defconfig'
#
# configuration written to .config
#

Modification de la configuration

Vous avez créé un fichier .config en utilisant une méthode. Soit vous avez utilisé celui utilisé par votre distribution Linux et vous l'avez mis à jour, soit vous en avez créé un en utilisant la cible defconfig.

Quoi qu’il en soit, vous cherchez comment le modifier. Le moyen le plus fiable de procéder consiste à utiliser la cible menuconfig ou nconfig.

Les deux cibles font la même chose mais ont une interface différente pour vous. C'est la seule différence entre eux. Je préfère utiliser la cible menuconfig mais dernièrement, je me suis penché vers nconfig car elle est un peu plus intuitive dans la recherche d'options.

Commencez par exécuter la commande make avec la cible menuconfig :

$ make menuconfig
  HOSTCC  scripts/kconfig/mconf.o
  HOSTCC  scripts/kconfig/lxdialog/checklist.o
  HOSTCC  scripts/kconfig/lxdialog/inputbox.o
  HOSTCC  scripts/kconfig/lxdialog/menubox.o
  HOSTCC  scripts/kconfig/lxdialog/textbox.o
  HOSTCC  scripts/kconfig/lxdialog/util.o
  HOSTCC  scripts/kconfig/lxdialog/yesno.o
  HOSTLD  scripts/kconfig/mconf

Maintenant, là-dedans, modifiez les options de configuration pour les modifier en fonction de leur type.

Il existe deux types d'options commutables :

Options d'état booléen : options qui peuvent uniquement être désactivées ([ ]) ou activées, comme celles intégrées ([*]).
Options à trois états : options qui peuvent être désactivées (< >), ou intégrées (<*>), ou construites en tant que module chargeable (< M>).

Pour en savoir plus sur une option, accédez-y à l'aide des touches fléchées haut/bas, puis appuyez sur la touche jusqu'à ce que l'option < Aide > en bas soit choisi. Et puis, appuyez sur la touche pour le sélectionner. Un menu d'aide sur cet élément d'option de configuration s'affichera.

Veuillez être prudent lorsque vous modifiez une option.

Une fois que vous l'avez configuré à votre guise, appuyez sur la touche jusqu'à ce que l'option < Enregistrer > en bas soit sélectionnée. Ensuite, appuyez sur la touche pour le sélectionner. Appuyez à nouveau sur la touche (sans changer le nom du fichier) pour enregistrer la configuration mise à jour dans le fichier .config.

Construire le noyau Linux

Construire le noyau Linux est simple. Mais avant de faire cela, marquons notre version de noyau personnalisée. J'utiliserai la chaîne -pratham comme balise et j'utiliserai la variable LOCALVERSION pour ce faire. Cela peut être configuré à l'aide de la commande suivante :

./scripts/config --file .config --set-str LOCALVERSION "-pratham"

Cela consiste à définir l'option de configuration CONFIG_LOCALVERSION dans le fichier .config sur la chaîne que je spécifie à la fin, qui, dans mon cas, est -pratham . . Ne vous sentez pas obligé d'utiliser mon nom ;)

L'option LOCALVERSION est utilisée pour définir une version "locale" qui est ajoutée au schéma de version habituel x.y.z et signalée lorsque vous exécutez uname -r commande.

Puisque je construis le noyau 6.5.5 avec la chaîne LOCALVERSION définie sur -pratham, pour moi, ce sera 6.5.5-pratham . Ceci est fait pour s'assurer que le noyau personnalisé que j'ai construit n'entre pas en conflit avec le noyau fourni par la distribution.

Maintenant, construisons le noyau lui-même. Voici la commande pour le faire :

make -j$(nproc) 2>&1 | tee log

C'est suffisant pour 99 % des utilisateurs.

L'option -j est utilisée pour spécifier le nombre de tâches de compilation parallèle à créer. Et la commande nproc renvoie un nombre correspondant au nombre d'unités de traitement disponibles (cela inclut les threads). Donc -j$ (nproc) signifie "utiliser autant de tâches de compilation parallèle que de threads CPU dont je dispose".

Le 2>&1 redirigera STDOUT et STDIN vers le même descripteur de fichier et cela sera redirigé vers la commande tee, qui stockera la sortie dans un fichier appelé log et imprimez également le même texte sur la console. C'est au cas où vous rencontreriez une erreur de construction et souhaiteriez consulter le journal pour vérifier ce qui ne va pas. Dans ce cas, vous pouvez simplement créer un journal des erreurs grep.

Cibles « créer » personnalisées

Il existe quelques cibles personnalisées que vous pouvez utiliser avec la commande make pour effectuer diverses opérations dans le répertoire source du noyau Linux. Ce sont une référence pour les développeurs. Si votre seule intention est d'installer un noyau Linux plus récent que celui proposé par votre distribution, vous pouvez ignorer cette partie ;)

Construire des cibles

En tant que développeur, il y aura des moments où vous souhaiterez construire uniquement le noyau Linux, ou uniquement les modules, ou uniquement les DTB. Dans ce cas, vous pouvez spécifier une cible de build et make construira uniquement celle(s) spécifiée(s), et rien d'autre.

Les cibles de build sont les suivantes :

vmlinux : le noyau Linux nu.
modules : Les modules chargeables.
dtbs : binaires d'arborescence de périphériques (principalement destinés aux architectures ARM et RISC-V).
all : construisez tout ce qui est marqué d'un astérisque * (à partir de la sortie de make help)].

De manière générale, vous n'avez pas besoin de spécifier l'une ou l'autre des cibles de build puisqu'elles doivent être automatiquement construites. C'est pour les moments où vous souhaitez tester quelque chose uniquement dans une cible de build, et pas dans d'autres.

En fonction de l'architecture de votre ordinateur, le nom de l'image du noyau Linux construite (qui est stockée dans /boot) variera.

Pour x86_64, le nom de l'image [par défaut] du noyau Linux est bzImage. Ainsi, si vous souhaitez uniquement construire le noyau Linux dans le but de le démarrer, vous pouvez spécifier bzImage comme cible, comme ceci :

## For x86_64
$ make bzImage

"Et comment trouver le nom de la cible avec laquelle appeler make sur mon architecture ?"

Il existe deux méthodes. Soit, vous pouvez faire une make help et rechercher la première option sous "Cibles spécifiques à l'architecture" précédée d'un astérisque *.

Ou, si vous souhaitez l'automatiser, vous pouvez obtenir le chemin complet (relatif) de l'image en utilisant la cible image_name. Eventuellement, ajoutez l'indicateur -s pour que la sortie reste utile.

Voici le résultat de trois ordinateurs que je possède, un x86_64, un autre AArch64 et le troisième étant riscv :

## x86_64
$ make -s image_name
arch/x86/boot/bzImage

## AArch64
$ make -s image_name
arch/arm64/boot/Image.gz

## RISC-V
$ make -s image_name
arch/riscv/boot/Image.gz

Et maintenant, pour créer uniquement l'image du noyau Linux, vous pouvez faire ceci :

make $(make -s image_name | awk -F '/' '{print $4}')

Objectifs de nettoyage

Si vous souhaitez nettoyer les artefacts de build, vous pouvez utiliser l'une des cibles suivantes pour obtenir ce que vous souhaitez :

clean : Supprimez presque tout sauf le fichier .config.
mrproper : tout ce que fait make clean, mais supprime également le fichier .config.
distclean : tout ce que make mrproper fait, mais supprime également tous les fichiers de correctifs.

Installation

Une fois le noyau Linux compilé, il est temps d’installer quelques éléments. "Quelques choses ?" Oui. Nous construisons au moins 2 choses différentes, 3 si vous êtes sur ARM ou RISC-V. Je vous expliquerai au fur et à mesure.

🚧

Bien que je vais vous informer sur les différentes méthodes d'installation, en particulier sur la modification du chemin d'installation par défaut, style="white-space: pre-wrap;">il n'est pas recommandé de le faire à moins que vous sachiez ce que vous êtes. faire ! Veuillez comprendre que si vous empruntez un itinéraire personnalisé, vous êtes seul. Ces valeurs par défaut existent pour une raison ;)

Installer les modules du noyau

Certaines parties du noyau Linux ne sont pas nécessaires au démarrage. Ces pièces sont construites sous forme de modules chargeables (c'est-à-dire chargés et déchargés si nécessaire).

Alors, installons ces modules. Ceci peut être réalisé avec la cible modules_install. L'utilisation de sudo est nécessaire puisque les modules seront installés dans /lib/modules/- et ce répertoire est appartenant à root, pas à votre utilisateur.

Cela installera non seulement les modules du noyau, mais les signera également. Cela prendra donc du temps. La bonne nouvelle est que vous pouvez paralléliser cela en utilisant l'option -j$ (nproc) évoquée précédemment ;)

sudo make modules_install -j$(nproc)

Remarque pour les développeurs : Vous pouvez spécifier un chemin différent où les modules Linux sont stockés (au lieu de /lib/modules/-) à l'aide du INSTALL_MOD_PATH comme suit :

sudo make modules_install INSTALL_MOD_PATH=<path>

Autre remarque pour les développeurs : Vous pouvez utiliser la variable INSTALL_MOD_STRIP pour spécifier si les modules doivent être débarrassés des symboles de débogage ou non. Les symboles de débogage ne sont pas supprimés s'ils ne sont pas définis. Lorsqu'ils sont définis sur 1, ils sont supprimés à l'aide de l'option --strip-debug, qui est ensuite transmise au strip (ou au llvm-strip si Clang est utilisé).

[Facultatif] Installation des fichiers d'en-tête du noyau Linux

Si vous avez l'intention d'utiliser ce noyau avec des modules hors arborescence, comme ZFS ou Nvidia DKMS, ou si vous essayez d'écrire vos propres modules, vous aurez probablement besoin des fichiers d'en-tête fournis par le noyau Linux.

Les en-têtes du noyau Linux peuvent être installés à l'aide de la cible headers_install, comme ceci :

sudo make headers_install

L'utilisation de sudo est nécessaire car les entêtes sont installés dans le répertoire /usr. Les répertoires enfants include/linux sont également créés dans /usr et les en-têtes sont installés dans /usr/include/linux.

Remarque pour les développeurs : Le chemin d'installation des en-têtes du noyau Linux peut être remplacé à l'aide de la variable INSTALL_HDR_PATH.

Installation de DTB (uniquement pour ARM et RISC-V)

Si vous utilisez x86_64, vous pouvez ignorer cette étape !

Si vous avez construit pour ARM ou RISC-V, il est très probable que l'exécution de make ait également généré les binaires de l'arborescence des périphériques. Vous pouvez vérifier cela en recherchant les fichiers .dtb dans arch//boot/dts.

J'ai un hack pour vérifier ceci :

## For AArch32
$ find arch/arm/boot/dts -name "*.dtb" -type f | head -n 1 > /dev/null && echo "DTBs for ARM32 were built"

## For AArch64
$ find arch/arm64/boot/dts -name "*.dtb" -type f | head -n 1 > /dev/null && echo "DTBs for ARM64 were built"

## For RISC-V
$ find arch/riscv/boot/dts -name "*.dtb" -type f | head -n 1 > /dev/null && echo "DTBs for RISC-V were built"

Si vous recevez un message indiquant « Les DTB pour ont été créés », procédez à l'installation des DTB. Cela se fait avec la cible dtbs_install.

L'utilisation de sudo est nécessaire puisque celui-ci sera installé dans /boot/dtb-- qui appartient à racine.

sudo make dtbs_install

Remarque pour les développeurs : tout comme pour l'installation de modules, vous pouvez spécifier un chemin personnalisé pour l'emplacement d'installation des binaires de l'arborescence des périphériques à l'aide de la variable INSTALL_DTBS_PATH.

Installez le noyau Linux

Enfin, nous installons le noyau Linux lui-même ! Cela se fait avec la cible install, comme ceci :

sudo make install

L'utilisation de sudo est nécessaire ici car le noyau Linux est installé dans /boot dans lequel votre utilisateur normal n'a pas la permission d'écrire.

💡

De manière générale, la cible install mettra également à jour le chargeur de démarrage, mais si elle échoue, cela signifie que vous disposez probablement d'un chargeur de démarrage non pris en charge. Si vous n'utilisez pas GRUB comme chargeur de démarrage, veuillez lire le manuel de votre chargeur de démarrage ;)

Remarque pour les développeurs : Pas surprenant cette fois ; La variable INSTALL_PATH est utilisée pour spécifier où le noyau Linux est installé, au lieu du chemin par défaut qui se trouve dans /boot.

Pour les utilisateurs d'Arch Linux

Si vous avez essayé d'exécuter la commande make install, vous avez peut-être remarqué que vous avez eu une erreur. Comme suit :

$ sudo make install
  INSTALL /boot
Cannot find LILO.

Pour installer réellement le noyau Linux sur Arch Linux, nous devons copier l'image du noyau Linux manuellement. Ne vous inquiétez pas, si vous utilisez Arch Linux, vous avez probablement l'habitude de faire les choses manuellement de toute façon. ( ͡° ͜ʖ ͡°)

Cela peut être fait avec la commande suivante :

sudo install -Dm644 "$(make -s image_name)" /boot/vmlinuz-<kernel_release>-<localversion>

Depuis que j'ai compilé le noyau 6.5.5, je vais exécuter la commande suivante, l'ajuster selon vos besoins :

sudo install -Dm644 "$(make -s image_name)" /boot/vmlinuz-6.5.5-pratham

Ce n'est pas nécessaire, mais vous devez également copier un fichier appelé System.map, et pendant que vous y êtes, copiez également le fichier .config ;)

sudo cp -vf System.map /boot/System.map-<kernel_release>-<localversion>
sudo cp -vf .config /boot/config-<kernel_release>-<localversion>

Générer le disque virtuel initial

Vous avez peut-être rencontré un utilitaire appelé mkinitcpio lorsque vous avez installé Arch Linux. Nous allons l'utiliser pour créer le disque virtuel initial.

Pour ce faire, nous avons d’abord besoin d’un préréglage. Pour ce faire, ajoutez le contenu suivant au fichier /etc/mkinitcpio.d/linux-.preset. Remplacez et <localversion> si nécessaire.

ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-<kernel_release>-<localversion>"

PRESETS=('default' 'fallback')

default_image="/boot/initramfs-<kernel_release>-<localversion>.img"
fallback_options="-S autodetect"

Une fois cela fait, exécutez la commande suivante pour générer le disque virtuel initial :

sudo mkinitcpio -p linux-<localversion>

Voici le résultat de mon ordinateur, le vôtre devrait également être similaire !

$ sudo mkinitcpio -p linux-pratham
==> Building image from preset: /etc/mkinitcpio.d/linux-pratham.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-6.5.5-pratham -c /etc/mkinitcpio.conf -g /boot/initramfs-6.5.5-pratham.img
==> Starting build: '6.5.5-pratham'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [kms]
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci'
  -> Running build hook: [keymap]
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating zstd-compressed initcpio image: '/boot/initramfs-6.5.5-pratham.img'
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-pratham.preset: 'fallback'
==> Using configuration file: '/etc/mkinitcpio.conf'
==> WARNING: No image or UKI specified. Skipping image 'fallback'

Le disque virtuel initial a été généré. Il est maintenant temps de passer à la mise à jour du bootloader !

Mettre à jour GRUB

Une fois que tous les fichiers nécessaires sont dans leur destination habituelle, il est maintenant temps de mettre à jour GRUB.

Mettez à jour le chargeur de démarrage GRUB à l'aide de la commande suivante :

sudo grub-mkconfig -o /boot/grub/grub.cfg

💡

Si vous utilisez un autre chargeur de démarrage, veuillez vous référer à sa documentation dans Arch Wiki.

La mise à jour de GRUB ne fera pas du noyau le plus récent le noyau par défaut. Veuillez le sélectionner dans le menu de démarrage lors du démarrage.

Vous pouvez sélectionner la version la plus récente du noyau Linux en accédant à l'élément de menu « Options avancées pour Arch Linux », puis en sélectionnant l'élément de menu indiquant « Arch Linux, avec Linux - ».

Redémarrer

Toutes nos félicitations! Vous avez terminé toutes les étapes pour obtenir les sources du noyau Linux, le configurer, le construire et l'installer. Il est temps de récolter les fruits de votre travail acharné en redémarrant et en démarrant dans le noyau Linux nouvellement construit et installé.

Assurez-vous de sélectionner la bonne version du noyau Linux dans le chargeur de démarrage. Une fois démarré, exécutez la commande uname -r pour vérifier que vous avez démarré en utilisant le noyau Linux prévu.

Ci-dessous le résultat de mon ordinateur :

$ uname -r
6.5.5-pratham

C'est la fête ! 🎉

Désinstallation

🚧

Vous devez d'abord passer à un noyau plus ancien avant de supprimer la version actuelle du noyau.

Soit votre distribution Linux a livré le noyau Linux avec la version que vous avez compilée manuellement, soit vous avez compilé vous-même un autre noyau plus récent et avez remarqué que vous deviez désinstaller l'ancien noyau pour libérer de l'espace pour le(s) nouveau(s).

Et maintenant, vous vous demandez comment annuler cela. Eh bien, il n'existe pas de make uninstall que vous puissiez exécuter, mais cela ne veut pas dire que tout espoir est perdu !

Nous savons où tous les fichiers sont installés, ce qui facilite leur suppression.

## Remove kernel modules
$ rm -rf /lib/modules/<kernel_release>-<localversion>

## Remove device-tree binaries
$ rm -rf /boot/dtb-<kernel_release>-<localversion>

## Remove the Linux kernel itself
$ rm -vf /boot/{config,System,vmlinuz}-<kernel_release>-<localversion>

Conclusion

Toute une aventure, n'est-ce pas ? Mais finalement, c'est conclu. Nous avons examiné l'ensemble du processus nécessaire à la compilation manuelle du noyau Linux. Cela impliquait d'installer les dépendances, de récupérer la source, de la vérifier, de l'extraire, de configurer le noyau Linux, de construire le noyau Linux puis de l'installer.

Si vous avez aimé ce guide détaillé étape par étape, n'hésitez pas à commenter et à me le faire savoir. Si vous rencontrez des problèmes, commentez et faites-le-moi savoir !