Handbook:X86/Installation/Kernel/fr

Facultatif : Installation de micrologiciels

Microcode

Micrologiciel Linux

Sur beaucoup de systèmes, les micrologiciels non libres sont nécessaires pour le fonctionnement de certaines fonctions matérielles. Le paquet sys-kernel/linux-firmware contient des micrologiciels pour beaucoup, mais pas tous, ces périphériques.

Chargement de micrologiciel

Les micrologiciels sont généralement chargés avec le module du noyau (kernel) associé. Cela signifie que le micrologiciel doit être compilé avec le noyau en utilisant « CONFIG_EXTRA_FIRMWARE » si le module est configuré avec « Y » (oui) à la place de « M » (module). Dans la plupart des situations, intégrer un module qui a besoin d’un micrologiciel peut être compliqué ou casser le chargement.

Micrologiciel

Contrairement aux cartes graphiques et des interfaces réseaux, les processeurs peuvent nécessiter une mise à jour du micrologiciel. Typiquement, ce type de micrologiciel est appelé « microcode ». Une version plus récente du microcode est parfois utile pour corriger une instabilité, un problème de sécurité ou d’autres bogues matériels.

Les mises à jour du microcode pour les processeurs AMD sont fournies le paquet susmentionné sys-kernel/linux-firmware . Le microcode pour les processeurs Intel est contenu dans le paquet sys-firmware/intel-microcode , lequel doit être installé séparément. Lisez l’article microcode pour plus d’information sur comment mettre à jour un microcode.

sys-kernel/installkernel

Installkernel peut être utilisé pour automatiser l’installation du noyau parmi la génération d’initramfs, unified kernel image ou la configuration du programme d’amorçage. sys-kernel/installkernel propose deux façons pour installer: le traditionnel installkernel originaire de Debian et kernel-install de systemd. Lequel choisir dépend, parmi d’autres critères, du système d’initialisation et du programme d’amorçage. Par défaut, kernel-install système est utilisé sur des profils systemd, tandis que le traditionnel installkernel est le choix par défaut pour les autres profils.

Programme d’amorçage (bootloader)

Il est temps maintenant de réfléchir au programme d’amorçage voulu par l’utilisateur pour son système. Si vous n’êtes pas sûr, choisir la « voie traditionnelle » ci-dessous.

GRUB

Les utilisateurs de GRUB peuvent utiliser au choix kernel-install de systemd ou le traditionnel installkernel de Debian. Le drapeau (USE) systemd permet de passer d’une implémentation à l’autre. Pour exécuter automatiquement grub-mkconfig lors de l’installation d’un noyau, activer grub USE flag.

sys-kernel/installkernel grub

systemd-boot

En utilisant systemd-boot (anciennement gummiboot) comme programme d’amorçage, kernel-install de systemd doit être utilisé. Conséquemment, assurez-vous que les drapeaux systemd et systemd-boot sont activés pour sys-kernel/installkernel  ; installez ensuite le paquet adéquat pour systemd-boot.

Sur les systèmes OpenRC :

sys-apps/systemd-utils boot kernel-install
sys-kernel/installkernel systemd systemd-boot

Sur les systèmes systemd :

sys-apps/systemd boot
sys-kernel/installkernel systemd-boot

La ligne de commandes à utiliser pour les nouveaux noyaux devrait être précisées dans /etc/kernel/cmdline, par exemple :

quiet splash

Exécutable noyau EFI (EFI stub)

Les systèmes basés sur UEFI n’ont techniquement pas besoin d’un second programme d’amorçage pour lancer un noyau. Le second programme d’amorçage existe pour étendre les fonctionnalités du micro-programme UEFI pendant le processus de démarrage. Ceci étant écrit, utiliser un second programme d’amorçage est typiquement plus facile et plus robuste car il offre une plus grande flexibilité pour une modification rapide des paramètres du noyaux au démarrage. Notez aussi que les implémentations UEFI diffèrent grandement entre les fabricants et selon les modèles ; il n’y a aucune garantie qu’un micro-programme donné suit les spécifications UEFI. De plus, un exécutable noyau EFI n’est pas garanti de fonctionner sur chaque système UEFI. Aussi, le drapeau USE est masqué et les mots-clés doit être acceptés pour utiliser cette fonctionnalité sur installkernel.

sys-kernel/installkernel
sys-boot/uefi-mkconfig
app-emulation/virt-firmware

sys-kernel/installkernel efistub

Choix traditionnel et autres programmes d’amorçage ((e)lilo, syslinux, etc.)

Le traditionnel chemin /boot (pour LILO, syslinux, etc.) est utilisé par défaut si les drapeaux USE grub , systemd-boot , efistub et uki ne sont pas activés. Aucune action supplémentaire n’est nécessaire.

Initramfs

Un système de fichiers basés sur la RAM pour l’initialisation, ou initramfs, peut être nécessaire pour démarrer un système. Un large panel de cas en ont besoin, les cas courants incluent :

• noyaux où les pilotes pour le système de fichiers ou le stockage sont des modules ;
• un partitionnement séparés de /usr/ ou /var/ ;
• un système de fichiers racine chiffré.

En plus de monter une partition racine, initramfs peut accomplir d’autres missions, comme :

• lancer une vérifier de la consistance d’un système de fichiers fsck, dans le cas d’un arrêt brutal du système ;
• fournir un environnement de secours en cas d’erreur au démarrage.

Installkernel peut générer automatiquement un initramfs en installant le noyau si les drapeaux USE dracut ou ugrd sont activés :

sys-kernel/installkernel dracut

Facultatif : image noyau unifiée

Une image noyau unifiée (Unified Kernel Image, UKI) combine, entre autres, le noyau, l’initramfs et la ligne de commande du noyau dans un seul exécutable. Comme la ligne de commande est embarquée dans une image noyau unifiée, elle doit être spécifiée avant la génération de cette image (voir plus bas). Notez que les arguments ajoutés par le programme d’amorçage ou un microprogramme sont ignorés lors du démarrage en mode démarrage sécurisé (secure boot).

Une image noyau unifiée nécessite un exécuteur de noyau. Actuellement, le seul disponible est systemd-stub. Pour l’activer :

Pour les systèmes systemd :

sys-apps/systemd boot

Pour les systèmes OpenRC :

sys-apps/systemd-utils boot kernel-install

Installkernel peut automatiquement générer une image noyau unifiée en utilisant soit dracut ou ukify pour activer les drapeaux USE respectifs.

Pour dracut :

sys-kernel/installkernel dracut uki

uefi="yes"
kernel_cmdline="arguments-pour-le-noyau"

Pour ukify :

sys-apps/systemd boot ukify # systemd
sys-apps/systemd-utils kernel-install boot ukify # OpenRC
sys-kernel/installkernel dracut ukify uki

arguments-pour-le-noyau

Notez que dracut peut générer à la fois une initramfs et une image noyau unifiée, ukify peut seulement générer le 2e et de plus l’initramfs doit être généré séparément avec dracut.

Image noyau générique unifiée (systemd seulement)

Le paquet pré-compilé sys-kernel/gentoo-kernel-bin peut éventuellement installer une image noyau générique pré-compilée initramfs capable de démarrer la plupart des systèmes basés sur systemd. Il peut être installé en activant le drapeau USE generic-uki et en configurant installkernel pour ne pas généré un initramfs personnalisé ou une image noyau unifiée :

sys-kernel/gentoo-kernel-bin generic-uki
sys-kernel/installkernel -dracut -ukify -ugrd uki

Démarrage sécurisé (Secure Boot)

L’image noyau générique unifiée peut être distribuée avec sys-kernel/gentoo-kernel-bin qui est déjà pré-signée. Comment signer une image noyau générique unifiée dépend de dracut ou ukify utilisé. Notez que le répertoire de destination de la clé et du certificat devront être le même que les variables SECUREBOOT_SIGN_KEY et SECUREBOOT_SIGN_CERT tels que spécifié dans /etc/portage/make.conf.

Pour dracut :

uefi="yes"
kernel_cmdline="some-kernel-command-line-arguments"
uefi_secureboot_key="/path/to/kernel_key.pem"
uefi_secureboot_cert="/path/to/kernel_key.pem"

Pour ukify :

[UKI]
SecureBootPrivateKey=/path/to/kernel_key.pem
SecureBootCertificate=/path/to/kernel_key.pem

Configuration et compilation du noyau

Il est maintenant temps de configurer et de compiler les sources du noyau. Pour l'installation d'un système, trois approches pour la gestion du kernel vont être présentées, mais une approche différente pourra être utilisée une fois l'installation terminée.

Classés du moins fréquent au plus courant :

Approche automatique complète : les noyaux distribués

Un noyau distribué est utilisé pour configurer automatiquement la compilation, installer le noyau Linux, ses modules associés, et (optionnellement, pas activé par défaut) un fichier initramfs. Les mises à jour du noyau sont totalement automatisées car elles sont gérés par le gestionnaire de paquets, comme pour n’importe quel autre paquet. Il est possible de fournir un fichier de configuration personnalisé si un paramètre est nécessaire. C’est la procédure la plus facile et elle est parfaite pour de nouveaux utilisateurs de Gentoo car elle est prête à l’emploi.

Approche manuelle 

les nouvelles sources du noyau sont installées par le gestionnaire de paquets. Le noyau est manuellement configuré, compilé, installé en utilisant eselect kernel et un tas de commande make. Les mises à jour futures du noyau répéteront la même procédure de configuration, compilation et installation. Cette façon de faire implique le plus d‘opérations, mais offre un contrôle maximal sur la mise à jour du noyau.

Approche hybride : Genkernel 

nous utilisons le terme « hybride » ici, mais notons que les noyaux distribués et la procédure manuelle partagent le même but. Les nouveaux noyaux sont installés via le gestionnaire de paquets. Les administrateurs systèmes peuvent utiliser le genkernel de Gentoo pour configurer, compiler et installer le noyau, ses modules associés, et (optionnellement, pas activé par défaut) un fichier initramfs. Il est possible de fournir un fichier de configuration du noyau si nécessaire. Les mises à jour futures du noyau auront besoin d’une implication de l’administrateur pour lancer eselect kernel, genkernel et potentiellement d’autres commandes à chaque mise à jour. Cette option ne devrait être choisie que par les utilisateurs qui ont besoin de genkernel

Le cœur de toute distribution est le noyau Linux. C’est la couche située entre les programmes de l’utilisateur et le matériel du système. Même si le guide d’installation propose à ses utilisateurs plusieurs sources du noyau possibles, une liste complète des sources, avec description, est disponible sur la page Vue d’ensemble des noyaux.

Distribution Alternative : utiliser un noyau distribué

Les noyaux distribués sont des ebuilds qui couvrent le processus complet de décompression, configuration, compilation et d’installation du noyau. L’avantage principal de cette méthode est que les noyaux sont mise à jour vers les nouvelles versions par le gestionnaire de paquet lors de la mise à jour de @world. Cela n’implique aucune autre action que le lancement de emerge. Les noyaux distribués sont confiogurer pour supporter la majeure partie du matériel, cependant, deux mécanismes offrent une personnalisation : savedconfig et les codes de configuration. Consultez pour plus de détails sur la configuration.

Facultatif : modules de noyau signés

Les modules noyaux du noyau précompilé (sys-kernel/gentoo-kernel-bin ) sont déjà signés. Pour signer les modules compilés depuis le code source, activer le drapeau modules-sign et éventuellement indiquer quelle clé utiliser pour signer dans /etc/portage/make.conf :

USE="modules-sign"
# Facultatif, pour utiliser les signatures personnelles.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem"# Seulement si MODULES_SIGN_KEY ne contient pas le certificat.
MODULES_SIGN_HASH="sha512"# sha512 par défaut.

Si MODULES_SIGN_KEY n’est pas précisé, le système de compilation du noyau va générer une clé qui sera sauvegardée dans /usr/src/linux-x.y.z/certs. Il est recommandé de générer manuellement une clé pour s’assurer qu’elle sera la même pour chaque nouveau noyau. Une clé peut-être générée avec :

.

OpenSSL va poser des questions à propos de la génération de la clé, il est recommandé de remplir de manière aussi détaillée que possible.

Sauvegarder la clé dans un endroit sûr, au maximum, cette clé devrait être lisible que par l’utilisateur root. Vérifer avec :

 -r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem 

Si la sortie ne ressemble pas à celle ci-dessus, corriger les permissions avec :

Facultatif : signer l’image du noyau (SecureBoot)

L’image du noyau distribué (sys-kernel/gentoo-kernel-bin ) est précompilé et signée pour un usage avec Secure Boot. Pour signer l’image noyau des noyaux produits depuis le code source, activer le drapeau secureboot et éventuellement indiquer la clé à utiliser pour signer dans /etc/portage/make.conf. Notez que signer l’image noyau pour SecureBoot nécessite que les modules du noyau soient également signés. La même clé peut être utilisée pour signer à la fois le noyau et ses modules :

USE="modules-sign secureboot"
# Facultatif, pour utiliser les signatures personnelles.
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem"# Seulement si MODULES_SIGN_KEY ne contient pas le certificat.
MODULES_SIGN_HASH="sha512"# sha512 par défaut.
# Facultatif : démarrer avec SecureBoot activé, peut être la même clé ou une différente.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"

Voyez la section ci-dessous sur les instructions pour générer une nouvelle clé, les étapes peuvent être répétées si une clé séparée est souhaitée pour signer l’image du noyau.

Pour démarrer avec SecureBoot activé, le programme d’amorçage doit également être signé et le certificat accepté par UEFI ou Shim. Cela sera expliqué plus tard dans le manuel.

Installer un noyau distribué

Pour compiler un noyau avec les correctifs Gentoo depuis le code source, tapez :

Les administrateurs systèmes qui veulent éviter de compiler le code source du noyau localement peuvent à la place utiliser des images précompilées :

Mettre à jour et nettoyer

Une fois le noyau installé, le gestionnaire de paquets va automatiquement faire la mise à jour vers une version plus récente. Les versions précédentes seront conservées jusqu’à ce que le gestionnaire de paquets soit sollicité pour nettoyer les anciens paquets. Pour récupérer l’espace disque, les anciens paquets peuvent être supprimés périodiquement avec l’option --depclean lors du lancement d’emerge :

Alternativement, pour supprimer une ancienne version du noyau spécifique :

Tâches post-installation

La mise à jour du noyau distribué est capable de lancer une recompilation automatique pour les modules externes installés par d’autres paquets (par exemple : sys-fs/zfs-kmod ou x11-drivers/nvidia-drivers ). Ce comportement automatique est activé avec dist-kernel . Si nécessaire, ce même drapeau peut aussi lancer la regénération du initramfs.

Il est hautement recommandé d’activé ce drapeau par défaut globalement via /etc/portage/make.conf lors de l’utilisation d’un noyau distribué :

USE="dist-kernel"

Recompiler manuellement un initramfs ou une image unifiée du noyau

Si nécessaire, lancer manuellement cette recompilation après la mise à jour du noyau en lançant :

Si un module du noyau (ie. ZFS) est nécessaire tôt dans le démarrage, recompiler initramfs via :

Après avoir installé le noyau distribué avec succès, il est maintenant possible de continuer dans la prochaine section : Configurer le système.

Installer les sources du noyau

Lors de l’installation et la compilation du noyau pour les systèmes basés sur x86, Gentoo recommande le paquet sys-kernel/gentoo-sources .

Choisissez les sources du noyau appropriées et installez les en utilisant emerge :

Cela installera les sources du noyau Linux dans le répertoire /usr/src/ dans un répertoire versionné. Un lien symbolique /usr/src/linux ne sera pas créé sans le drapeau USE symlink activé pour le paquet de sources du noyau choisi.

Il est usuelle d’avoir un lien symbolique /usr/src/linux pour pointer vers les sources du noyau actuel. Cependant, ce lien n’est pas créé par défaut. Un autre façon de créer ce lien est d’utiliser le module eselect kernel.

Pour davantage d’informations concernant le but du lien symbolique et comment le gérer, consultez Kernel/Upgrade/fr.

Premièrement, listons les noyaux installés :

Available kernel symlink targets:
 [1] linux-6.6.21-gentoo

Pour créer un lien symbolique linux, copier :

lrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-6.6.21-gentoo

Approche manuelle

Configurer manuellement un noyau est couramment vu comme la procédure la plus difficile pour un administrateur système. Rien n’est moins vrai... mais après avoir configuré quelques noyaux, plus personne ne se souvient que c’était difficile ! Il y a deux manières pour un utilisateur Gentoo de gérer un noyau manuellement, les deux sont listées ci-dessous :

Procédure modprobed-db

Une manière très simple pour gérer le noyau est d’installer d’abord sys-kernel/gentoo-kernel-bin puis d’utiliser sys-kernel/modprobed-db pour réunir les informations à propos des besoins du système. modprobed-db est un outil qui supervise le système via crontab et ajoute tous les modules de tous les périphériques branchés une fois sur le système pour s‘assurer que tous les besoins de l’utilisateur sont supportés. Par exemple, si un contrôleur Xbox est branché après l’installation, modprobed-db va ajouter les modules pour être compilés la prochaine fois que le noyau est reconstruit. Ce sujet est détaillé dans l’article Modprobed-db.

Procédure manuelle

Cette procédure permet à l’utilisateur d’avoir un contrôle total sur ses noyaux avec un minimum d’outils aidant comme il le désire. Certains considère que cela a un intérêt de rendre cela difficile.

Cependant, avec ce choix, une chose est vraie : c est vital de connaître le système quand un noyau est configuré manuellement. La plupart des informations nécessaires peuvent être recueillies en installant le paquet sys-apps/pciutils qui contient la commande lspci :

Une autre source d’information est d’exécuter la commande lsmod pour voir quels modules du noyau sont utilisés par le média d’installation afin de savoir quoi activer plus tard.

Il est maintenant temps d’accéder au répertoire source du noyau.

Le noyau a une auto-détection de modules utilisé par l’installcd qui permet un bon point de départ afin de configurer son propre noyau. Il peut être appelé avec :

Il est maintenant temps de configurer avec nconfig :

La configuration du noyau Linux comporte beaucoup, beaucoup de sections. Voici une liste des options qui doivent être activées (sinon Gentoo ne fonctionnera pas ou incorrectement, sans modifications supplémentaires). Il existe également un Guide de configuration du noyau de Gentoo sur le wiki pouvant apporter plus d’informations.

Activer les options nécessaires

Pour utiliser sys-kernel/gentoo-sources , il est vivement recommandé de laisser les configurations spécifiques à Gentoo activées. Cela assure que les fonctions minimales requises pour un noyau qui fonctionne sont disponibles :

Gentoo Linux --->
 [*] Gentoo Linux support
 [*] Linux dynamic and persistent device naming (userspace devfs) support
 [*] Select options required by Portage features
 Support for init systems, system and service managers --->
 [*] OpenRC, runit and other script based systems and managers
 [*] systemd

Naturellement, le choix des deux dernières lignes dépend du programme d’initialisation (OpenRC vs systemd). Il est possible d’avoir les deux supports activés.

Pour utiliser sys-kernel/vanilla-sources , les sélections pour le programme d’initialisation ne sont pas disponibles. Activer le support est possible, mais soit du périmètre de ce manuel.

Activer le support des composants usuels

Bien s’assurer que tous les pilotes indispensables au démarrage du système (comme le contrôleur SATA, les périphériques NVMe, les systèmes de fichiers) soient compilés dans le noyau et non en tant que module, sinon le système pourrait ne pas démarrer correctement.

Ensuite, sélectionner le type exact du processeur. Il est également recommandé d’activeer les fonctionnalités MCE (si disponibles) afin que les utilisateurs puissent être notifiés de tout problème matériel. Sur certaines architectures (telles que x86_64), ces erreurs se sont pas affichées dans dmesg, mais dans /dev/mcelog. Cela nécessite le paquet app-admin/mcelog .

Aussi, sélectionner Maintain a devtmpfs file system to mount at /dev afin que le fichiers critiques des périphériques soient disponible au début du processus de démarrage. (CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT) :

Device Drivers --->
 Generic Driver Options --->
 [*] Maintain a devtmpfs filesystem to mount at /dev
 [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs

Vérifier que le support pour les disques SCSI soit activé (CONFIG_BLK_DEV_SD) :

Device Drivers --->
 SCSI device support ---> 
 <*> SCSI device support
 <*> SCSI disk support

Device Drivers --->
 <*> Serial ATA and Parallel ATA drivers (libata) --->
 [*] ATA ACPI Support
 [*] SATA Port Multiplier support
 <*> AHCI SATA support (ahci)
 [*] ATA BMDMA support
 [*] ATA SFF support (for legacy IDE and PATA)
 <*> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support (ata_piix)

Vérifiez que le support des NVMe a bien été activé :

Device Drivers --->
 <*> NVM Express block device

Device Drivers --->
 NVME Support --->
 <*> NVM Express block device

Cela ne coûte rien d’activer le support additionnel NVMe :

[*] NVMe multipath support
[*] NVMe hardware monitoring
<M> NVM Express over Fabrics FC host driver
<M> NVM Express over Fabrics TCP host driver
<M> NVMe Target support
 [*] NVMe Target Passthrough support
 <M> NVMe loopback device support
 <M> NVMe over Fabrics FC target driver
 < > NVMe over Fabrics FC Transport Loopback Test driver (NEW)
 <M> NVMe over Fabrics TCP target support

Maintenant, aller dans « File Systems » et sélectionner la prise en charge des systèmes de fichiers qui seront utilisés. Attention, ne pas compiler le système de fichier utilisé par le système de fichier racine an tant que module, sinon le système pourrait ne pas savoir monter la partition. Aussi, sélectionner « Virtual memory » et « /proc file system ». Sélectionner également une ou plusieurs des options suivantes selon le système :

File systems --->
 <*> Second extended fs support
 <*> The Extended 3 (ext3) filesystem
 <*> The Extended 4 (ext4) filesystem
 <*> JFS filesystem support
 <*> XFS filesystem support
 <*> Btrfs filesystem support
 DOS/FAT/NT Filesystems --->
 <*> MSDOS fs support
 <*> VFAT (Windows-95) fs support
 
 Pseudo Filesystems --->
 [*] /proc file system support
 [*] Tmpfs virtual memory file system support (former shm fs)

Si PPPoE, ou un modem analogique, est utilisé pour se connecter à Internet, activer les options suivantes(CONFIG_PPP, CONFIG_PPP_ASYNC, and CONFIG_PPP_SYNC_TTY) :

Device Drivers --->
 Network device support --->
 <*> PPP (point-to-point protocol) support
 <*> PPP over Ethernet
 <*> PPP support for async serial ports
 <*> PPP support for sync tty ports

Les deux options de compression ne poseront pas de problème mais elles ne sont définitivement pas indispensables, pas plus que l’option de PPP sur Ethernet qui ne sera probablement utilisée que si configurée pour faire du mode PPPoE via le noyau.

Ne pas oublier d’inclure dans le noyau le support pour les cartes réseau (Ethernet ou sans fil).

La plupart des système possèdent également plusieurs cœurs à leur disposition, il est donc important d’activer l’option « Symmetric multi-processing support » (CONFIG_SMP) :

Processor type and features --->
 [*] Symmetric multi-processing support

Si des périphériques d’entrée USB (comme un clavier ou une souris), ou d’autres périphériques USB seront utilisés, ne pas oublier d’en activer le support :

Device Drivers --->
 HID support --->
 -*- HID bus support
 <*> Generic HID driver
 [*] Battery level reporting for HID devices
 USB HID support --->
 <*> USB HID transport layer
 [*] USB support --->
 <*> xHCI HCD (USB 3.0) support
 <*> EHCI HCD (USB 2.0) support
 <*> OHCI HCD (USB 1.1) support
 <*> Unified support for USB4 and Thunderbolt --->

Optionnel : modules noyaux signés

Pour automatiquement signer les modules noyaux, activez l’option CONFIG_MODULE_SIG_ALL :

[*] Enable loadable module support 
 -*- Module signature verification 
 [*] Automatically sign all modules 
 Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->

Vous pouvez changer l’algorithme de signature (hash) si vous le désirez.

Pour s’assurer que tous les modules signés le sont avec une signature valide, activez également l’option CONFIG_MODULE_SIG_FORCE :

[*] Enable loadable module support 
 -*- Module signature verification 
 [*] Require modules to be validly signed
 [*] Automatically sign all modules
 Which hash algorithm should modules be signed with? (Sign modules with SHA-512) --->

Pour utiliser une clé personnalisée, spécifiez le chemin d’accès dans CONFIG_MODULE_SIG_KEY. Si non spécifié, le système de compilation du noyau générera une clé. Il est recommandé de la générer manuellement. Cela peut être fait avec :

OpenSSL vous posera quelques questions pour générer la clé, il est recommandé de donner des réponses aussi précises que possible.

Conservez la clé dans un répertoire sûr ; au plus, la clé devrait être lisible par l’utilisateur root. Vérifiez avec :

 -r-------- 1 root root 3164 Jan 4 10:38 kernel_key.pem 

Si la sortie est différente comparé à celle du dessus, corrigez les permissions avec :

-*- Cryptographic API ---> 
 Certificates for signature checking ---> 
 (/path/to/kernel_key.pem) File name or PKCS#11 URI of module signing key

Pour signer également des modules noyaux installés par d’autres paquets via linux-mod-r1.eclass, acitivez le drapeau USE modules-sign globalement :

USE="modules-sign"
# Optionnellement, en utilisant des clés de signatures personnalisées
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem"# Nécessaire seulement si « MODULES_SIGN_KEY » ne contient pas également le certificat
MODULES_SIGN_HASH="sha512"# sha512 par défaut

{{#switch: x86 | amd64 | arm64 | riscv | x86 = Optionnel : Signez l’image noyau (Secure Boot) ====

Lors de la signature d’une image noyau (pour les systèmes avec Secure Boot activé), il est recommandé d’activer les options suivantes dans la configuration du noyau :

General setup --->
 Kexec and crash features ---> 
 [*] Enable kexec system call 
 [*] Enable kexec file based system call 
 [*] Verify kernel signature during kexec_file_load() syscall 
 [*] Require a valid signature in kexec_file_load() syscall 
 [*] Enable ""image"" signature verification support 
[*] Enable loadable module support 
 -*- Module signature verification 
 [*] Require modules to be validly signed
 [*] Automatically sign all modules
 Which hash algorithm should modules be signed with? (Sign modules with SHA-512) ---> 
Security options ---> 
[*] Integrity subsystem 
 [*] Basic module for enforcing kernel lockdown 
 [*] Enable lockdown LSM early in init 
 Kernel default lockdown mode (Integrity) ---> 
 [*] Digital signature verification using multiple keyrings 
 [*] Enable asymmetric keys support 
 -*- Require all keys on the integrity keyrings be signed 
 [*] Provide keyring for platform/firmware trusted keys 
 [*] Provide a keyring to which Machine Owner Keys may be added 
 [ ] Enforce Machine Keyring CA Restrictions

Où « image » est un paramètre pour le nom spécifique de l’image de l’architecture. Ces options, du haut vers le bas : forcent que l’image du noyau est lancée dans un appel kexec doit être signée (kexec autorise le remplacement du noyau), forcent que les modules du noyau sont signés, active le verrouillage d’intégrité (pour empêcher la modification du noyau lors de l’exécution) et activent plusieurs chaînes.

Pour les architectures qui ne supportent pas nativement la décompression du noyau (i.e. arm64 et riscv), le noyau doit être compilé avec son propre décompresseur (zboot) :

Device Drivers ---> 
 Firmware Drivers ---> 
 EFI (Extensible Firmware Interface) Support ---> 
 [*] Enable the generic EFI decompressor

Après avoir compilé le noyau, comme expliqué dans la section suivante, l’image du noyau doit être signée. Premièrement, installez app-crypt/sbsigntools et signer l’image du noyau :

Continuez avec l’installation.

Pour signer automatiquement les exécutables EFI installés par d’autres paquets, activez globalement le drapeau secureboot  :

USE="modules-sign secureboot"
# Optionnellment, pour utiliser des clés de signatures personnalisées
MODULES_SIGN_KEY="/path/to/kernel_key.pem"
MODULES_SIGN_CERT="/path/to/kernel_key.pem"# Seulement nécessaire si le module MODULES_SIGN_KEY ne contient pas le certificat.
MODULES_SIGN_HASH="sha512"# sha512 par défaut
# Optionnellement, pour démarrer avec secureboot activé, avec la même clé ou une différente.
SECUREBOOT_SIGN_KEY="/path/to/kernel_key.pem"
SECUREBOOT_SIGN_CERT="/path/to/kernel_key.pem"

For x86 architectures, verify the 64-bit kernel option is unset/deactivated (CONFIG_64BIT=N), and then select the processor family as appropriate for the system's processor(s).

La famille de processeur peut être déterminée en examinant le résultat des deux commandes suivantes :

[ ] 64-bit kernel
Processor type and features --->
 Processor family (Core 2/newer Xeon) --->
 ( ) 486
 ( ) 586/K5/5x86/6x86/6x86MX
 ( ) Pentium-Classic
 ( ) Pentium-MMX
 ( ) Pentium-Pro
 ( ) Pentium-II/Celeron(pre-Coppermine)
 ( ) Pentium-III/Celeron(Coppermine)/Pentium-III Xeon
 ( ) Pentium M
 ( ) Pentium-4/Celeron(P4-based)/Pentium-4 M/Xeon
 ( ) K6/K6-II/K6-III
 ( ) Athlon/Duron/K7
 ( ) Opteron/Athlon64/Hammer/K8
 ( ) Crusoe
 ( ) Efficeon
 ( ) Winchip-C6
 ( ) Winchip-2/Winchip-2A/Winchip-3
 ( ) AMD Elan
 ( ) GeodeGX1
 ( ) Geode GX/LX
 ( ) CyrixIII/VIA-C3
 ( ) VIA C3-2 (Nehemiah)
 ( ) VIA C7
 (*) Core 2/newer Xeon
 ( ) Intel Atom

With the configuration now done, it is time to compile and install the kernel. Exit the configuration and start the compilation process:

When the kernel has finished compiling, copy the kernel image to /boot/. This is handled by the make install command:

This will copy the kernel image into /boot/ together with the System.map file and the kernel configuration file.

Déprécié : Genkernel

Genkernel devrait être utilisée par les utilisateurs ayant un besoin que seul Genkernel peut apporter. Pour les autres, il est recommandé le noyau de la distribution ou de compiler le sien manuellement car cela rend la maintenance de Gentoo plus simple. Un exemple de pourquoi genkernel est plus complexe à gérer est le manque d’intégration avec sys-kernel/installkernel . Cela signifie que l’utilisateur n’aura pas le même niveau d’automatisation comparé aux autres méthodes ; par exemple les images unifiées du noyau devront être crées manuellement avec Genkernel.

Les utilisateurs souhaitant toujours utiliser Genkernel devront lire Genkernel pour plus d’informations.

Les modules du noyau

Lister les modules noyau disponibles

Les modules qui doivent être chargés automatiquement à chaque démarrage sont définis dans les fichiers /etc/modules-load.d/*.conf, un module par ligne. Cependant, lorsque des options supplémentaires doivent être ajoutées, elles doivent être ajoutés dans les fichiers /etc/modprobe.d/*.conf.

Pour voir tous les modules disponibles pour une version de noyau spécifique, exécuter la commande find suivante. N’oubliez pas de remplacer « <version noyau> » par la version du noyau venant que vous souhaitez utiliser :

Forcer le chargement d’un module noyau en particulier

Pour forcer le chargement du module 3c59x.ko (correspondant au pilote pour une carte réseau de la famille 3Com), éditez le fichier /etc/modules-load.d/network.conf et ajoutez-y le nom du module.

Notez que le suffixe .ko des modules est insignifiant pour le mécanisme de chargement et n’apparaît pas dans le fichier de configuration

3c59x

Continuer l’installation avec Configurer le système.

• Handbook