Kernel/Gentoo Kernel Configuration Guide/fr

Le but de ce document est d'introduire les concepts d'une configuration manuelle du noyau, et d'en détailler les pièges les plus courants.

Introduction
Gentoo met à la disposition des utilisateurs deux moyens d'installation, de configuration, et de mise à jour du noyau : automatique (genkernel) et manuel. Bien que la méthode automatique puisse être considérée comme plus facile pour la plupart des utilisateurs, il y a plusieurs raisons pour lesquelles un grand nombre d'utilisateurs de Gentoo choisit de configurer le noyau à la main :


 * 1) Plus grande flexibilité
 * 2) Noyau plus compact
 * 3) Temps de compilation plus court
 * 4) Expérience didactique
 * 5) Ennui sérieux
 * 6) Connaissance absolue de la configuration noyau, et/ou
 * 7) Contrôle complet

Ce guide ne parle pas de la méthode automatique (avec genkernel). Si l'utilisation de genkernel est préférée pour gérer le noyau, reportez-vous à la documentation de Genkernel pour plus de détails.

Ce guide n'a pas l'ambition de documenter la configuration manuelle de A à Z — le processus de configuration s'appuie sur un large degré de bon sens, et un niveau de connaissance technique relativement élevé du système utilisé. Au lieu de cela, il vous présente les concepts de la configuration manuelle et détaille les pièges les plus courants que les utilisateurs se doivent d'éviter.

À ce stade, l'utilisateur est supposé avoir décompressé les sources du noyau Linux sur le disque dur (de façon générale sous ), et devrait savoir comment lancer l'utilitaire de configuration ansi que comment se déplacer dans le système de menus basé sur ncurse. Si l'utilisateur n'en est pas encore là, d'autres documentations sont disponibles. Lisez les articles suivant puis revenez sur ce guide :


 * Le document Noyau/Vue d'ensemble contient des informations sur les différents noyaux disponibles dans l'arbre Portage.
 * La page Noyau/Mise à jour explique comment mettre à jour un noyau ou comment commuter vers un autre noyau.
 * La section Configuration du noyau du manuel gentoo couvre également quelques aspects de l'installation du noyau. Sélectionnez l'architecture appropriée, puis naviguez vers la section intitulée "Configurer le noyau Linux"

Les bases
Le processus général est plutôt simple : une série d'options, sous forme de menus et sous-menus, sont présentées et le support matériel et les fonctionnalités du noyau pertinentes pour le système sont sélectionnées.

Le noyau comprend une configuration par défaut, qui est présentée la première fois que  est exécuté sur un jeu de sources particulier. Les choix par défaut sont en général à large portée et raisonnables, ce qui veut dire qu'une majorité d'utilisateurs n'auront que peu de changements à faire à cette configuration de base. Quand le choix est fait de désactiver une option qui été activée dans la configuration par défaut du noyau, il est important de s'assurer qu'une bonne compréhension de ce que cette option fait exactement est obtenue, et des conséquence de sa déactivation.

Lors d'une première configuration d'un noyau Linux, tentez de rester conservateur ; ne soyez pas trop aventurier, et contentez-vous de faire aussi peu de modification aux réglages par défaut que possible. En même temps, pensez bien qu'il y a une partie de la configuration qui se doit absolument d'être adaptée au système pour que ce dernier ne démarre !

Compilé en dur ou compilé en tant que module
Majoritairement, les options de configuration sont à trois état : elles peuvent être non compilées du tout, compilées en dur dans le noyau   ou compilées sous forme de module. Les modules sont stockés en externe sur le système de fichiers, alors que les options compilées en dur sont incluses dans l'image du noyau elle-même.

Il y a une différence importante entre compilé en dur et sous forme de modules : sauf quelques exceptions, le noyau n'essaye pas de charger un module externe quand le système pourrait en avoir besoin ; ceci est laissé à l'initiative de l'utilisateur. Alors que certaines autres parties du système peuvent disposer de mécanismes de chargement à la demande, et qu'il y ait quelques mécanismes de chargement automatique de module, il est recommandé de compiler la prise en charge du matériel et les fonctionnalités du noyau directement dans le noyau. Le noyau est ainsi assuré de disposer des fonctionnalités et de la prise en charge du matériel quand il en a besoin. Cela se fait en configurant chaque fonctionnalité du kernel à. Pour que cette configuration soit cohérente, il est également nécessaire d'inclure le support des firmware directement dans le noyau. Cela se fait en configurant les options  et   dans le fichier  du noyau ou par les choix suivants :

Pour d'autres parties de la configuration, compilée en dur est une absolue nécessité. Par exemple, si la partition root comporte un système de fichiers btrfs, le système ne démarrera pas si la prise en charge de brtfs a été compilée en tant que module. Le système devrait alors regarder dans la partition root pour trouver le module btrs (vu que les modules sont stockés dans la partition root), mais il ne peut pas lire la partition root à moins d'avoir déjà chargé le support pour btrfs! Si btrfs n'a pas été compilé en dur, le processus de démarrage n'arrivera pas à trouver la partition root.

Prise en charge du matériel
Au delà de détecter le type d'architecture du système, l'utilitaire de configuration ne cherche pas à identifier quel matériel est réellement présent sur le système. Bien qu'il existe des réglages par défaut pour la prise en charge de quelques matériels, il reviendra aux utilisateurs de trouver et sélectionner les options pertinentes pour chaque configuration matérielle.

Sélectionner les options de configuration correctes nécessite une connaissance des composants à l'intérieur de, et connectés à, l'ordinateur. La plupart du temps, ces composants peuvent être identifiés sans avoir beoin de soulever le capot. Pour la plupart des composants, l'utilisateur doit identifier le jeu de circuits (chipset) utilisé par chacun d'entre-eux, plutôt que leur nom commercial. Beaucoup de cartes d'extension sont commercialisées avec une certaine marque, mais utilisent le chipset d'un autre fabricant.

Quelques utilitaires sont là pour aider les utilisateurs à déterminer quelles configurations du noyau utiliser. (du paquet ) identifiera votre matériel PCI et AGP, ce qui inclut les composants construits sur la carte mère elle-même. (du paquet ) identifiera divers périphériques raccordés aux ports USB du système.

La situation est quelque peu confuse à cause des degrés variables de normalisation dans le monde des fabricants de matériel. A moins que l'utilisateur ne s'écarte réellement des paramétrages par défaut, les disques IDE, le clavier PS/2 ou USB et la souris devraient simplement fonctionner. Une prise en charge VGA de base pour l'écran est également incluse. Néanmoins, certains périphériques tels que les les adaptateurs Ethernet sont à peine normalisés ; pour ces périphériques les utilisateurs devront identifier leur chipset et sélectionner la prise en charge matérielle appropriée pour la carte spécifique pour disposer d'un accès au réseau.

De plus, alors que certains matériels fonctionnent tout simplement avec les réglages par défaut, des options plus spécialisées peuvent être sélectionnées pour tirer le meilleur du système. Par exemple, si le support pour le chipset IDE approprié n'a pas été activé, le disque sera très lent en accès.

Fonctionnalités du noyau
En plus de la prise en charge du matériel, les utilisateurs doivent penser aux fonctionnalités logicielles qui seront requises dans le noyau. Un exemple important d'une telle fonctionnalité est la prise en charge des systèmes de fichiers : les utilisateurs doivent sélectionner la prise en charge des systèmes de fichiers utilisés sur leurs disques durs, ainsi que pour chaque système de fichiers qu'ils pourraient utiliser sur des supports amovibles (par exemple VFAT pour des disques USB flash).

Un autre exemple courant est la fonctionnalité avancé de réseau. Pour effectuer du routage ou du pare-feu, les items pertinents de la configuration doivent être inclus dans la configuration du noyau.

Prêt ?
Maintenant que les concepts ont été présentés, il devrait être facile d'identifier la matériel du système, de naviguer dans l'interface de menuconfig, et de sélectionner les options requises du noyau pour le système.

La suite de ce guide vise à éclaircir certaines zones de confusion fréquente, et à fournir des conseils sur la manière d'éviter les problèmes les plus couramment rencontrés par les utilisateurs. Bonne chance !

Les disques SATA sont SCSI
La plupart des ordinateurs de bureau modernes sont livrés avec des unités de stockage (disques durs et lecteurs de CD/DVD) sur un bus Serial ATA, plutôt que sur l'ancien bus Parallel_ATA(câble en ruban).

La prise en charge de SATA dans Linux est mise en œuvre dans une couche connue sous le nom de libata, qui siège en dessous du sous-système SCSI. Pour cette raison, les pilotes SATA sont trouvés dans la section des pilotes SCSI de la configuration. En outre, les périphériques de stockage seront traités comme des périphériques SCSI, ce qui veut dire que la prise en charge des disques/CDROM SCSI sera également requise. Le premier disque SATA sera nommé et le premier lecteur CD/DVD SATA sera nommé.

Bien que la majorité de ces pilotes soit pour les contrôleurs SATA, libata n'a pas été conçue pour être spécifique à SATA. Tous les pilotes courants IDE seront aussi portés dans libata dans un futur proche, et après cela, les considérations évoquées plus haut, s'appliqueront aussi aux utilisateurs d'IDE.

Jeux de circuits IDE et DMA
Malgré l'introduction de SATA, les périphériques IDE sont encore courants et beaucoup de systèmes en dépendent. IDE est une technologie parfaitement générique et, grâce à cela, Linux prend en charge presque tous les contrôleurs IDE directement à l'installation sans qu'aucune option spécifique au contrôleur ait besoin d'être activée.

Cependant, IDE est une technologie ancienne, et dans son implémentation originale entrées/sorties programmées, elle est incapable de procurer les débits requis pars les accès rapides aux périphériques des stockage modernes. Le pilote IDE générique est limité à ces modes de transfert PIO, qui conduisent à des débits de transfert bas, et à une utilisation significative de CPU lors du transfert de données vers/du disque.

Sauf si un utilisateur a affaire à un système pré-1995, le contrôleur IDE prend également en charge un mode de transfert alternatif, connu sous le nom de Direct Memory Access (accès direct à la mémoire - DMA). DMA est beaucoup plus rapide, et l'utilisation du CPU est à peine affectée lors des transferts de données. Si le système souffre d'une performance générale faible qlors qu'il utilise un disque IDE, il est fort probable que le mode DMA ne soit pas utilisé et doit être activé.

Si libata n'est pas utilisé pour les disques IDE, il est nécessaire de vérifier que DMA est activé. La commande suivante peut être utilisée pour déterminer si DMA est utilisé :

Pour activer DMA pour d'anciens disques IDE (qui est une fonctionnalité dépréciée), activer les options de configuration du noyau suivantes.

Contrôleurs des hôtes USB
USB est un bus largement utilisé pour la connexion de périphériques externes à un ordinateur. Une des raisons du succès de USB est qu'il s'agit d'un protocole standard. Néanmoins, les périphériques de contrôle des hôtes (host contrôleur devices ou HCD) USB mis en œuvre sur l'ordinateur hôte varient un peu. Il y en a quatre types :


 * , le Universal Host Controller Interface (Interface de contrôleur d'hôte USB universel). Il prend en charge l'USB 1.1, et se trouve ordinairement sur les cartes mères basées sur un chipset VIA ou Intel.
 * , l'Open Host Controller Interface (l'interface de contrôleur d'hôte ouverte) . Elle prend en charge l'USB 1.1 et se trouve ordinairement sur les cartes mères basées un chipset Nvidia ou SiS.
 * , l'Extended Host Controller Interface (interface de contrôleur d'hôte étendue). C'est le seul contrôleur d'hôte courant à prendre en charge l'USB 2.0. Il se trouve ordinairement sur tous les ordinateurs disposant de ports USB 2.0.
 * 1)   l'eXtensible Host Controller Interface. C'est le contrôleur hôte pour USB 3.0 et il est compatible avec USB 1.0, 1.1, 2.0, 3.0 et les vitesses futures. Activez cette fonctionnalité si la carte mère supporte USB 3.0.

La plupart des systèmes arrivent avec deux des types d'interface cités ci-dessus : XHCI (USB 3.0) et EHCI(USB 2.0). Pour utiliser des périphériques USB, il n'est plus nécessaire de sélectionner les deux options étant donné que XHCI est compatible avec les versions antérieures. Les utilisateurs peuvent cependant activer EHCI pour etre vraiment surs mais cela ne pose aucun problème si les contrôleurs USB 2.0 ne sont pas disponibles.

Si les options pertinentes correspondant aux types de ports USB présents sur le sytème ne sont pas sélectionnées, des cas de ports USB morts peuvent être rencontrés. Ces cas peuvent être déterminés quand un périphérique fonctionnel est connecté, mais n'est pas alimenté ou ne répond pas.

L'utilisation de la commande (du paquet  ) fait qu'il est relativement facile de détecter quels HCDs sont présents sur le système. Ignorant le contrôleur SATA qui est aussi détecté, il est facile d'identifier si le système nécessite la prise en charge de EHCI et de XHCI :

Sélectionnez les HCDs présents sur le système. En général, sélectionnez les trois options pour un support maximal, ou si la configuration correcte est incertaine :

Dans le noyau Linux 3.12.13 et suivants, la prise en charge de OHCI pour les contrôleurs USB du bus PCI  doit être activée si le contrôleur USB est OHCI et  qu'une souris ou un clavier USB est utilisé.

Systèmes à multiprocesseur, Hyper-Threading et multi-cœur
Beaucoup d'ordinateurs ont recours à des processeurs multiples mais pas toujours d'une manière immédiatement évidente.


 * Beaucoup des CPUs d'Intel prennent en charge une technologie appelée hyper-threading. Cette technologie autorise un seul CPU à être vu par le système comme deux processeurs logiques.
 * La plupart des CPUs Intel/AMD consiste réellement en des processeurs physiques multiples dans un boîtier unique, ils sont connus sous le nom de processeurs multi-cœurs.
 * Quelques ordinateurs haut de gamme ont réellement plusieurs processeurs physiques installés sur des cartes mères spécialisées pour procurer une augmentation de performance significative par rapport à un système à processeur unique. Les utilisateurs sauront probablement si ils utilisent un tel système car ils ne sont pas bon marché.

Dans tous ces cas, les options du noyau appropriées doivent être sélectionnées pour tirer la performance optimale de ces réglages.

La prochaine option n'active pas seulement les fonctionnalités de gestion de l'énergie, mais peut également être nécessaire pour que tous les processeurs soit accessible au système :

Prise en charge de la mémoire x86 haute
À cause des limitations de l'adressage sur 32 bits des architectures, un noyau compilé avec les options par défaut ne prendra en charge que 896 MO de mémoire RAM. Si le système dispose de plus de mémoire, seuls les premiers 896 MO seront visibles, sauf si la prise en charge de la mémoire haute est activée.

La prise en charge de la mémoire haute n'est pas activée par défaut, parce qu'elle introduit une légère surcharge. Cela ne doit pas être une distraction, la surcharge est insignifiante comparée au gain de performance procuré par une augmentation de la taille de la mémoire !

Choisir l'option 4GB, à moins que le système ne dispose de plus de 4GB de RAM :

Modules du noyau compressés
A partir la version du noyau 3.18.x, la compression des modules du noyau est possible. Les formats de compression gzip et xz sont disponibles. Il est important d'installer le paquet avec les bonnes options de la variable USE avant de compiler un kernel avec des modules compressés.

Re-installer :

Activez la compression des modules et sélectionnez une méthode de compression favorite :

Normalement lance. Si n'a pas les options de la variable USE correctement configurées (voir l'étape  ci-dessus) la première fois qu'elle sera éxecutée, la liste des dépendences sera vide. Le système ne sera alors pas en mesure de charger les modules qui avaient été compressés.

Après avoir recompilé kmod, re-lancer pour résoudre le problème :

Introduction
En lisant à propos de la configuration du noyau, souvent les paramètres sont notés CONFIG_. Cette notation abrégée est ce que la configuration du noyau utilse réellement en interne, et est aussi ce qui sera retrouvé dans le fichier de configuration du noyau (soit ou dans le fichier auto-généré  ). Bien sûr, l'utilisation de cette notation abrégée ne servirait pas à grand chose s'il était impossible de la traduire en son emplacement réel dans les menus de configuration du noyau. Heureusement, l'outil lancé par  rend cela possible.

Traduire CONFIG_FOO en un emplacement réel dans les menus de configuration
Supposons que la variable CONFIG_TMPFS_XATTR doit être activée. Lancez le menu de configuration du noyau et tapez. Cela ouvrira une boîte de recherche. Dans la boîte de recherce, tapez CONFIG_TMPFS_XATTR.

Ce qui suit est le résultat de cette recherche :

Cette sortie nous fournit une multitude d'informations intéressantes.

Grâce à ces informations, il est possible de traduire toutes les variables CONFIG_* nécessaires assez facilement. En bref, cela signifie que l'utilisateur doit


 * 1) Activer les paramètres décrits dans le champ Depends on (dépend de) ;
 * 2) Naviguer là où le champ Location: (emplacement :) dirige
 * 3) Basculer la valeur référencée par Prompt: (invite de commande:)

Autres documentations sur la configuration du noyau
Jusqu'à maintenant, seuls les concepts généraux et les problèmes spécifiques relatifs à la configuration du noyau ont été introduits; l'utilisateur se chargera de découvrir les détails. Néanmoins, d'autres parties de la documentation de Gentoo fournissent des détails spécialisés selon le thème abordé.

Ces documents peuvent être fort utiles lors de la configuration de domaines spécifiques du noyau. Même si cet avertissement a déjà été mentionné, souvenez-vous : les utilisateurs qui débutent avec la configuration du noyau ne devraient pas être trop téméraires. Commencez par un système de base qui fonctionne. La prise en charge audio, de l'impression, etc pourront toujours être ajouté par la suite.

Obtenir les bases d'un noyau opérationnel aidera les utilisateurs dans les étapes de configuration ultérieures, car l'utilisateur saura ce qui casse le système et ce qui fonctionne. Il est toujours judicieux d'enregistrer la configuration du noyau de base (qui marche) dans un dossier autre que le dossier des sources du noyau avant d'essayer d'ajouter de nouvelles fonctionnalités ou le support de nouveau matériel.


 * L'article ALSA fournit des détails sur les options de configuration requises pour la prise en charge des cartes son. Notez qu'ALSA est une exception au schéma suggéré de ne pas construire les choses en tant que modules : ALSA est réellement plus facile à configurer lorsque les composants sont modulaires.


 * L'article Bluetooth fournit les détails sur les options requises pour l'utilisation des périphériques bluetooth.


 * Le  Guide du routage IPV6 explique comment configurer le noyau pour le routage qui utilise le schéma d'adressage réseau de la nouvelle génération.


 * Si les pilotes graphiques propriétaires nVidia sont utilisés pour une performance graphique 3D améliorée, le guide nVidia  présente les options qui doivent et ne doivent pas être activées sur un tel système.


 * Entre autres choses, le Guide de gestion de l'énergie explique comment configurer le noyau pour l'adaptation des fréquences du CPU, et pour les fonctionnalités de mise en veille et d'hibernation.


 * Si un système PowerPC est utilisé, la FAQ PPC dispose de quelques sections relatives à la configuration d'un noyau PPC.


 * Le Guide d'impression présente les options du noyau requises pour la prise en charge de l'impression dans Linux.


 * Le Guide USB détaille les options de  configuration requises pour utiliser les périphériques USB courants tels que clavier, souris, périphériques de stockage, et imprimantes USB.

Les changements apportés à la configuration restent sans effet
Il est très courant pour les utilisateurs d'effectuer un changement dans la configuration du noyau, mais de faire une petite erreur dans le processus de redémarrer sur le nouveau noyau. Ils redémarrent sur une image qui n'est pas celle qu'ils viennent de reconfigurer, se rendent compte que le problème qu'ils voulaient résoudre est toujours présent, et en concluent que le changement n'est pas en mesure de résoudre leur problème.

The process of compiling and installing kernels is outside the scope of this document; refer to the Kernel Upgrade Guide for general guidance. In short, the process to get a modified kernel is the following: 1) configure, 2) compile, 3) mount (if not already mounted), 4) copy new kernel image to, 5) Make sure the bootloader will reference the new kernel, 6) reboot. If one of those final stages has been missed, then the changes will not properly take effect.

Il est possible de vérifier si le noyau qui a démarré correspond au nouveau noyau compilé sur le disque dur. Pour ce faire, examinez la date et l'heure de compilation du noyau. En supposant que l'architecture du système est et que les sources du noyau sont installées dans, la commande suivante peut être utilisée :

La commande ci-dessus affichera la date et l'heure de compilation du noyau qui a été démarré.

La commande ci-dessus affiche la date et l'heure de la dernière compilation de l'image du noyau sur le disque dur.

Si les deux horodatages issus des commandes précédentes sont différents de plus de 2 minutes, cela indique q'un erreur à été faite lors de la réinstallation du noyau et que le système pas démarré sur l'image du noyau nouvellement modifiée.

Les modules ne sont pas chargés automatiquement
Comme mentionné précédemment, le système de configuration du noyau cache un grand changement de comportement lorsque vous sélectionnez un composant du noyau pour une compilation en tant que module (M) plutôt que pour une compilation en dur dans le noyau. Cela mérite d'être répété parce que de nombreux utilisateurs tombent dans ce piège.

Lorsque un composant est selectionné pour une compilation en dur dans le noyau, le code est inclus dans l'image du noyau (bzImage). Lorsque le noyau a besoin de ce composant, il peut l'initialiser et le charger automatiquement, sans intervention de l'utilisateur.

Lorsque un composant est sélectionné pour une compilation en tant que module, le code est placé dans un module du noyau et installé sur le système de fichiers. En général, lorsque le noyau a besoin de ce composant, il ne pourra pas le trouver. Sauf quelques exceptions, le noyau ne fait aucun effort pour charger les modules — cette tâche est dévolue à l'utilisateur.

Si la prise en charge du réseau est construite en tant que module, et que le réseau n'est pas accessible, c'est probablement parce que le module n'est pas chargé — ce la doit être fait soit à la main ou en configurant le système pour charger automatiquement le module au démarrage.

Sauf si un utilisateur a des raisons de faire autrement, du temps peut être économisé en construisant ces composants en dur dans le noyau, de manière à ce que le noyau puisse configurer tous ces petits détails lui-même.

Voir aussi

 * genkernel - Un outil pour automatiser l'installation d'un noyau et du fichier initramfs.
 * proc filesystem (Security Handbook) - Changer les variables et paramètres du noyau à la volée (En anglais).