10.3.1. Installation du noyau
Construire le noyau implique un certain nombre d'étapes
— configuration, compilation et installation. Pour connaître
les autres méthodes que celle employée par ce livre pour configurer
le noyau, lisez le fichier README
contenu dans les sources du noyau.
Important
Construire le noyau linux pour la première fois est l'une des
tâches les plus difficiles de LFS. La bonne exécution de cette
tâche dépend du matériel spécifique pour le système cible et de
vos besoins spécifiques. Il y a plus de 12 000 entrées de
configuration disponibles pour le noyau bien que seul un tiers
d'entre elles soient requises pour la plupart des ordinateurs. Si
vous n'êtes pas familiers de ce processus, les rédacteurs de LFS
recommandent de suivre les procédure ci-dessous sans trop vous en
écarter. L'objectif est d'avoir un premier système auquel vous
pourrez vous connecter depuis la ligne de commande lorsque vous
redémarrerez plus tard au Section 11.3,
« Redémarrer le système. » Pour le moment,
l'optimisation et la personnalisation ne sont pas des objectifs
prioritaires.
Pour des informations d'ordre général sur la configuration du
noyau, consultez
http://www.fr.linuxfromscratch.org/view/astuces/kernel-configuration-fr.txt.
Vous pouvez trouver des informations supplémentaires sur la
configuration et la construction du noyau sur http://www.kroah.com/lkn/.
Ces références sont un peu vieilles, mais donnent toujours un bon
aperçu du processus.
Si tout le reste échoue, vous pouvez demander de l'aide sur la
liste de diffusion lfs-support.
Remarquez qu'il est nécessaire de s'enregistrer sur la liste.
Cela permet d'éviter le spam.
Préparez la compilation en exécutant la commande suivante :
make mrproper
Ceci nous assure que le répertoire du noyau est propre. L'équipe du
noyau recommande le lancement de cette commande avant chaque
compilation du noyau. Vous ne devez pas supposer que le répertoire
des sources est propre juste après avoir été déballé.
Il y a plusieurs manière de configurer les options du noyau.
Habituellement, à travers une interface à menus, par exemple :
make menuconfig
Voici la signification des variables d’environnement
facultatives de make :
-
LANG=<valeur_LANG_de_l_hote>
LC_ALL=
-
Ceci rend identique les paramétrages régionaux à ceux
utilisés sur l'hôte. C'est indispensable pour que l’interface
ncurses de menuconfig soit correctement dessinée sur la
console texte de Linux en UTF-8.
Assurez-vous si besoin de remplacer <valeur_LANG_de_l_hote>
par la valeur de la variable $LANG
de votre hôte. Vous pouvez utiliser à la place les valeurs
$LC_ALL
ou $LC_CTYPE
de l'hôte.
-
make
menuconfig
-
Cela lance une interface à menus en ncurses. Pour d'autres
interfaces (graphiques), tapez make help.
Note
Un bon point de départ pour effectuer la configuration du noyau
est de lancer make
defconfig. Cela opérera une configuration de base
de bonne qualité en prenant en compte l'architecture actuelle de
votre système.
Assurez-vous d'activer, désactiver ou indiquer les
fonctionnalités suivantes ou le système ne démarrera pas
correctement voir pas du tout :
General setup --->
[ ] Compile the kernel with warnings as errors [WERROR]
CPU/Task time and stats accounting --->
[*] Pressure stall information tracking [PSI]
[ ] Require boot parameter to enable pressure stall information tracking
... [PSI_DEFAULT_DISABLED]
< > Enable kernel headers through /sys/kernel/kheaders.tar.xz [IKHEADERS]
[*] Control Group support ---> [CGROUPS]
[*] Memory controller [MEMCG]
[ ] Configure standard kernel features (expert users) ---> [EXPERT]
Processor type and features --->
[*] Build a relocatable kernel [RELOCATABLE]
[*] Randomize the address of the kernel image (KASLR) [RANDOMIZE_BASE]
General architecture-dependent options --->
[*] Stack Protector buffer overflow detection [STACKPROTECTOR]
[*] Strong Stack Protector [STACKPROTECTOR_STRONG]
Device Drivers --->
Generic Driver Options --->
[ ] Support for uevent helper [UEVENT_HELPER]
[*] Maintain a devtmpfs filesystem to mount at /dev [DEVTMPFS]
[*] Automount devtmpfs at /dev, after the kernel mounted the rootfs
... [DEVTMPFS_MOUNT]
Firmware Drivers --->
[*] Mark VGA/VBE/EFI FB as generic system framebuffer [SYSFB_SIMPLEFB]
Graphics support --->
<*> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) --->
... [DRM]
[*] Display a user-friendly message when a kernel panic occurs
... [DRM_PANIC]
(kmsg) Panic screen formatter [DRM_PANIC_SCREEN]
Supported DRM clients --->
[*] Enable legacy fbdev support for your modesetting driver
... [DRM_FBDEV_EMULATION]
<*> Simple framebuffer driver [DRM_SIMPLEDRM]
Console display driver support --->
[*] Framebuffer Console support [FRAMEBUFFER_CONSOLE]
Activez certaines fonctionnalités supplémentaires si vous
construisez un système 64 bits. Si vous utilisez menuconfig,
activez-les dans l'ordre : d'abord CONFIG_PCI_MSI
, puis CONFIG_IRQ_REMAP
et enfin
CONFIG_X86_X2APIC
car une
option ne s'affiche qu'après avoir sélectionné ses dépendances.
Processor type and features --->
[*] Support x2apic [X86_X2APIC]
Device Drivers --->
[*] PCI support ---> [PCI]
[*] Message Signaled Interrupts (MSI and MSI-X) [PCI_MSI]
[*] IOMMU Hardware Support ---> [IOMMU_SUPPORT]
[*] Support for Interrupt Remapping [IRQ_REMAP]
Si vous construisez un système 32 bits sur du matériel qui a
plus de 4 Go de RAM, ajustez la configuration pour que le
noyau puisse utiliser jusqu'à 64 Go de RAM physique :
Processor type and features --->
High Memory Support --->
(X) 64GB [HIGHMEM64G]
Si la partition du système LFS est un SSD NVME (c.-à-d. que le
nœud de périphérique de la partition est /dev/nvme*
au lieu de /dev/sd*
), activez la prise en charge NVME ou
le système LFS ne démarrera pas :
Device Drivers --->
NVME Support --->
<*> NVM Express block device [BLK_DEV_NVME]
Vous pourriez souhaiter d'autres options selon les besoins de votre
système. Pour une liste des options nécessaires pour les paquets
BLFS, voir
L'index des options du noyau pour BLFS.
Note
Si votre matériel hôte utilise UEFI et que vous souhaitez
démarrer LFS sans, vous devrez ajuster certaines configurations
du noyau en suivant
la page BLFS même si vous allez
utiliser le chargeur d'amorçage UEFI de la distribution
hôte.
Voici pourquoi on vise les éléments de configuration
ci-dessus :
-
Randomize the
address of the kernel image (KASLR)
-
Active l'ASLR pour l'image du noyau, pour éviter certaines
attaques basées sur les adresses fixes de données sensible ou
de code dans le noyau.
-
Compile the
kernel with warnings as errors
-
Cela peut causer un échec à la construction si le compilateur
ou la configuration diffère de ceux des développeurs du
noyau.
-
Enable kernel
headers through /sys/kernel/kheaders.tar.xz
-
Cela demandera cpio pour construire le
noyau. cpio
n'est pas installé par LFS.
-
Configure
standard kernel features (expert users)
-
Cette option affichera des options dans l'interface mais les
changer peut s'avérer dangereux. N'utilisez pas cette option
sauf si vous savez ce que vous faites.
-
Strong Stack
Protector
-
Active SSP pour le noyau. Nous l'avons activée pour
l'intégralité de l'espace utilisateur avec --enable-default-ssp
en
configurant GCC, mais le noyau n'utilise pas le paramètre GCC
par défaut pour SSP. Nous l'activons ici explicitement.
-
Support for
uevent helper
-
L'activation de cette option peut interférer avec la gestion
de périphériques quand on utilise Udev.
-
Maintain a
devtmpfs
-
Ceci créera des nœuds de périphérique automatiquement,
générés par le noyau même sans Udev. Udev fonctionne alors
sur cette base pour gérer les droits et l'ajout de liens
symboliques. Cet élément de configuration est nécessaire pour
tous les utilisateurs d'udev.
-
Automount
devtmpfs at /dev
-
Cela montera la vue des périphériques du noyau sur /dev au
changement de système de fichiers racine juste avant de
charger l'init.
-
Display a
user-friendly message when a kernel panic
occurs
-
Cela fera afficher le message correctement dans le cas d'une
panique du noyau et que le pilote DRM le prend en charge.
Sans cela, il serait plus difficile de diagnostiquer les
paniques : si aucun pilote DRM n'est utilisé, on est sur
la console VGA qui ne peut contenir que 24 lignes et le
message pertinent du noyau est souvent remplacé par le texte
suivant. Si un pilote DRM est utilisé, l'affichage est
souvent complètement désordonné lors d'une panique. Depuis
Linux-6.12, aucun des pilote dédiés aux modèles de GPU
courants ne le prennent vraiment en charge, mais c'est pris
en charge par le « pilote framebuffer simple » qui
tourne sur le framebuffer VESA (ou EFI) avant le chargement
du pilote GPU dédié. Si le pilote GPU dédié est construit en
tant que module (au lieu de faire partie de l'image du noyau)
et qu'aucun initramfs n'est utilisé, cette fonctionnalité
fonctionnera correctement avant le montage du système de
fichiers racine et c'est déjà suffisant pour fournir des
informations sur les erreurs de configuration LFS qui causent
une panique (par exemple un mauvais paramètre root=
dans
Section 10.4, « Utiliser GRUB pour paramétrer le
processus de démarrage »).
-
Panic screen
formatter
-
Indiquez kmsg
pour vous assurer
que les dernières lignes des messages du noyau sont affichées
dans le cas d'une panique du noyau. La valeur par défaut,
user
, ne lui ferait afficher
qu'un message de panique « convivial » qui n'est pas utile
pour le diagnostic. La troisième possibilité, qr_code
, ferait compresser les dernières
lignes de messages en un code QR et l'afficher. Le code QR
peut contenir plus de lignes que le texte brut et il peut
être décodé par un appareil externe (comme un smartphone).
Mais il nécessite le compilateur Rust que LFS ne fournit pas.
-
Mark VGA/VBE/EFI
FB as generic system framebuffer
et Simple framebuffer driver
-
Ils permettent d'utiliser le framebuffer VESA (ou le
framebuffer EFI si vous démarrez le système LFS via UEFI)
comme un périphérique DRM. Le framebuffer VESA sera configuré
par GRUB (ou le framebuffer EFI sera configuré par le
micrologiciel UEFI), donc le gestionnaire de panique DRM peut
fonctionner avant que le pilote DRM spécifique au GPU ne soit
chargé.
-
Enable legacy
fbdev support for your modesetting driver
et
Framebuffer Console
support
-
Ces options sont requises pour afficher la console Linux sur
un GPU piloté par un pilote DRI (Infrastructure de Rendu
Direct). Comme CONFIG_DRM
(Gestionnaire de Rendu Direct) est activé, vous devriez
également activer ces deux options ou vous verrez un écran
noir une fois le pilote DRI chargé.
-
Support
x2apic
-
Prend en charge le contrôleur d'interruption des processeurs
x86 64 bits dans le mode x2APIC. x2APIC peut être activé
par le micrologiciel sur les systèmes x86 64 bits, et un
noyau sans cette option paniquera au démarrage si x2APIC est
activé par le micrologiciel. Cette option n'a aucun effet
mais ne cause aucun problème non plus si x2APIC est désactivé
par le micrologiciel.
Sinon, make oldconfig
peut être plus approprié dans certaines situations. Voir le fichier
README
pour plus d'informations.
Si vous le désirez, vous pouvez sauter la configuration du noyau en
copiant le fichier de configuration, .config
, du système hôte (en supposant qu'il est
disponible) dans le répertoire linux-6.13.4
tout juste déballé. Néanmoins, nous
ne recommandons pas cette option. Il est souvent meilleur
d'explorer tous les menus de configuration et de créer la
configuration du noyau à partir de zéro.
Compilez l'image du noyau et les modules :
make
Si vous utilisez des modules du noyau, il peut être nécessaire de
les configurer dans le fichier /etc/modprobe.d
. Des informations au sujet de la
configuration du noyau et des modules se trouvent à la Section 9.3,
« Manipulation des périphériques et modules » et dans
le répertoire linux-6.13.4/Documentation
de la documentation du
noyau. Enfin, modprobe.d(5)
pourrait aussi être intéressant.
À moins d'avoir désactivé la prise en charge des modules dans la
configuration du noyau, installez les modules :
make modules_install
Une fois la compilation du noyau terminée, des étapes
supplémentaires sont encore nécessaires pour terminer
l'installation. Certains fichiers ont besoin d'être copiés dans le
répertoire /boot
.
Attention
Si vous avez décidé d'utliiser une partition /boot
séparée pour le système LFS (en
partageant éventuellement une partition /boot
avec la distribution hôte), les fichiers
copiés ci-dessous devraient aller là. La manière la plus simple
de procéder est de lier /boot sur l’hôte (en dehors du chroot) à
/mnt/lfs/boot avant de continuer. En tant qu'utilisateur
root
sur le système hôte :
mount /boot
Le chemin vers le nœud de périphérique est omis dans la commande
car mount peut le
lire dans /etc/fstab
.
Le chemin vers l'image du noyau pourrait varier suivant la
plateforme utilisée. Vous pouvez changer le nom du fichier
ci-dessous selon votre goût, mais la nomenclature du nom de fichier
devrait ressembler à vmlinuz
pour être compatible avec le paramétrage automatique du processus
de démarrage décrit dans la section à venir. La commande suivante
présuppose une architecture x86 :
cp -iv arch/x86/boot/bzImage /boot/vmlinuz-6.13.4-lfs-12.3
System.map
est un fichier de symboles
pour le noyau. Il cartographie les points d'entrée de chaque
fonction dans l'API du noyau, ainsi que les adresses de ses
structures de données pendant l'exécution. Il sert de référence
lors des investigations sur les problèmes de noyau. Lancez la
commande suivante pour installer le fichier de symboles :
cp -iv System.map /boot/System.map-6.13.4
Le fichier de configuration du noyau .config
produit à l'étape make menuconfig ci-dessus
contient toutes les options de configuration choisies pour le noyau
qui vient d'être compilé. Conserver ce fichier est une bonne idée
pour pouvoir s'y référer plus tard :
cp -iv .config /boot/config-6.13.4
Installez la documentation du noyau Linux :
cp -r Documentation -T /usr/share/doc/linux-6.13.4
Il est important de noter que les fichiers dans le répertoire des
sources du noyau n'appartiennent pas à root. Chaque fois qu'un paquet est
déballé par l'utilisateur root (comme on a fait dans chroot), les
fichiers ont les ID de l'utilisateur et du groupe de l'empaqueteur
sur son système hôte. En principe ce n'est pas un problème car
l'arborescence des sources est supprimée après l'installation. En
revanche, l'arborescence de Linux est souvent conservée longtemps.
Du coup, il y a des chances que tout ce que l'ID de l'utilisateur
ayant déballé le paquet a utilisé ne soit affecté à quelqu'un
d'autre sur la machine. Cette personne pourrait alors avoir un
droit d'écriture sur les sources du noyau.
Note
Dans de nombreux cas, la configuration du noyau aura besoin
d'être mise à jour pour les paquets qui serojnt installés plutard
dans BLFS. Contrairement aux autres paquets, il n'est pas
nécessaire de supprimer les sources du noyau après l'installation
du noyau nouvellement construit.
Si vous conservez l'arborescence des sources du noyau, lancez
chown -R 0:0 sur le
répertoire linux-6.13.4
pour vous
assurer que tous les fichiers appartiennent à root.
Si vous mettez à jour la configuration et reconstruisez le noyau
à partir d'une arborescence des sources résultant d'une
précédente compilation, vous ne devriez normalement pas avoir à lancer la commande
make mrproper. La
commande supprimerait le fichier .config
et tous les fichiers .o
de la construction précédente. Bien qu'il
soit facile de restaurer un .config
à partir de la copie dans /boot
,
supprimer tous les fichiers .o
est
une pure perte : pour un changement de configuration simple,
souvent seuls quelques fichiers .o
devront être reconstruits et le système de construction du noyau
passera correctement les autres fichiers .o
s'ils ne sont pas supprimés.
D'un autre côté, si vous avez mis à jour GCC, vous devriez
exécuter make clean
pour nettoyer tous les fichiers .o
de la construction précédente, ou la nouvelle construction
pourrait échouer.
Avertissement
Certaines documentations du noyau recommandent de créer un lien
symbolique à partir de /usr/src/linux
pointant vers le répertoire des
sources du noyau. Ceci est spécifique aux noyaux antérieurs à la
série 2.6 et ne doit pas
être réalisé sur un système LFS car il peut poser des problèmes
pour les paquets que vous souhaitez construire une fois votre
système LFS de base complet.