Kernel (Français)
Arch Linux est basé sur le noyau Linux. Il existe plusieurs noyaux Linux alternatifs disponibles pour Arch Linux en plus du dernier noyau stable. Cet article liste certaines des options disponibles dans les dépôts avec une brève description de chacune. Il y a également une description des correctifs qui peuvent être appliqués au noyau du système. L'article se termine par un aperçu de la compilation personnalisée du noyau avec des liens vers différentes méthodes.
D'après Wikipédia :
- Le noyau Linux est un noyau de système d'exploitation monolithique open-source de type Unix.
Les paquets du noyau sont installés dans le répertoire /usr/lib/modules/
et ensuite utilisés pour générer des images exécutables qui sont stockées dans /boot/
. Pour pouvoir démarrer sur des noyaux, le chargeur d'amorçage doit être configuré de manière appropriée.
Noyaux officiellement pris en charge
Une assistance communautaire sur forum et bug reporting est disponible pour les noyaux officiellement pris en charge.
- Stable — Noyau et modules Linux «vanilla», avec quelques correctifs appliqués.
- Hardened — Noyau Linux axé sur la sécurité, appliquant un ensemble de correctifs de renforcement pour atténuer les exploits du noyau et de l'espace utilisateur. Il permet également d'activer plus de fonctionnalités de renforcement du noyau en amont que linux.
- Longterm — Noyau et modules Linux avec prise en charge au long terme (LTS).
Compilation
Les méthodes suivantes peuvent être utilisées pour compiler votre propre noyau :
- Avec Arch Build System (en)
- Tire profit de la haute qualité du PKGBUILD existant et des avantages de la gestion des paquets.
- Avec une compilation traditionnelle (en)
- Implique le téléchargement manuel d'une archive tar source, et la compilation dans votre répertoire personnel en tant qu'utilisateur normal.
- La meilleure façon d'augmenter la vitesse de votre système est d'adapter la configuration de votre noyau à votre architecture et à votre type de processeur.
- Vous pouvez réduire la taille de votre noyau (et donc le temps de construction) en n'incluant pas la prise en charge des éléments que vous n'avez pas ou n'utilisez pas. Par exemple la gestion des choses comme le Bluetooth, video4linux, Ethernet gigabit, etc...
config
des paquets du noyau Arch sont dans les fichiers sources des paquets Arch (par exemple, lié à linux). Le fichier de configuration de votre noyau en cours d'exécution peut également être disponible dans votre système de fichiers à /proc/config.gz
si l'option CONFIG_IKCONFIG_PROC
est activée.Certains des paquets listés peuvent également être disponibles sous forme de paquets binaires via des Dépôts utilisateurs non officiels.
Noyaux de kernel.org
- Git — Noyau Linux et modules construits à partir des sources du dépôt Git de Linus Torvalds
Noyaux non officiels
- Ck — Contenant des correctifs de Con Kolivas (y compris l'ordonnanceur MuQSS) conçus pour améliorer la réactivité du système en mettant l'accent sur le bureau, mais ils sont adaptés à toute charge de travail.
- GalliumOS — Le noyau et les modules Linux avec les correctifs GalliumOS pour les Chromebooks.
- Dépôt par le développeur de pf-kernel post-factum
- Dépôt, par le développeur de pf-kernel fork Thaodan
- par yurikoles
- XanMod — Il vise à tirer pleinement parti des stations de travail hautes performances, des ordinateurs de jeu, des centres multimédias et autres, et est conçu pour offrir une expérience de bureau plus solide comme le roc, plus réactive et plus fluide. Ce noyau utilise l'ordonnanceur MuQSS ou Task Type, l'ordonnanceur d'E/S BFQ, la déduplication des données en mémoire en temps réel UKSM, le contrôle de congestion TCP BBR, la prise en charge du jeu d'instructions avancé x86_64 et d'autres changements par défaut.
- https://xanmod.org/ || linux-xanmodAUR, linux-xanmod-ttAUR
Dépannage
Panique du noyau
Une panique du noyau se produit lorsque le noyau Linux entre dans un état de défaillance irrécupérable. Cet état provient généralement de pilotes matériels défectueux, ce qui entraîne un blocage de la machine, une absence de réponse et la nécessité d'un redémarrage. Juste avant le blocage, un message de diagnostic est généré, comprenant : l'état de la machine au moment où la défaillance s'est produite, une trace d'appel menant à la fonction du noyau qui a reconnu la défaillance, et une liste des modules actuellement chargés. Heureusement, les paniques du noyau ne se produisent pas très souvent avec les versions mainline du noyau - telles que celles fournies par les dépôts officiels - mais lorsqu'elles se produisent, vous devez savoir comment y faire face.
Examiner le message de panique
Si une panique du noyau se produit très tôt dans le processus de démarrage, vous pouvez voir un message sur la console contenant "Kernel panic - not syncing :", mais une fois que systemd est en cours d'exécution, les messages du noyau seront généralement capturés et écrits dans le journal du système. Cependant, lorsqu'une panique se produit, le message de diagnostic émis par le noyau n'est presque jamais écrit dans le fichier journal sur le disque car la machine se bloque avant que n'en ait la possibilité. Par conséquent, la seule façon d'examiner le message de panique est de l'afficher sur la console au moment où il se produit (sans avoir recours à la configuration d'un kdump crashkernel). Vous pouvez le faire en démarrant avec les paramètres de noyau suivants et en essayant de reproduire la panique sur tty1 :
systemd.journald.forward_to_console=1 console=tty1
Exemple de scénario : mauvais module
Il est possible de deviner quel sous-système ou module est à l'origine de la panique à l'aide des informations contenues dans le message de diagnostic. Dans ce scénario, nous avons une panique sur une machine imaginaire pendant le démarrage. Faites attention aux lignes mises en gras :
- Indique le type d'erreur qui a provoqué la panique. Dans ce cas, il s'agit d'un bogue de programmeur.
- Indique que la panique s'est produite dans une fonction appelée fw_core_init dans le module firewire_core.
- Indique que firewire_core était le dernier module à être chargé.
- Indique que la fonction qui a appelé la fonction fw_core_init était do_one_initcall.
- Indique que ce message oops est, en fait, une panique du noyau et que le système est maintenant bloqué.
Nous pouvons donc supposer que la panique s'est produite pendant la routine d'initialisation du module firewire_core lors de son chargement. (Nous pourrions alors supposer que le matériel firewire de la machine est incompatible avec cette version du module pilote firewire en raison d'une erreur du programmeur, et qu'il faudra attendre une nouvelle version). En attendant, le moyen le plus simple de faire fonctionner à nouveau la machine est d'empêcher le chargement du module. Nous pouvons le faire de deux façons :
- Si le module est chargé pendant l'exécution de initramfs, redémarrez avec le paramètre kernel .
- Sinon, redémarrez avec le paramètre du noyau .
Redémarrez dans le shell root et corrigez le problème
Vous aurez besoin d'un shell root pour apporter des modifications au système afin que la panique ne se produise plus. Si la panique se produit au démarrage, il existe plusieurs stratégies pour obtenir un shell root avant que la machine ne se bloque :
- Redémarrer avec le paramètre noyau
emergency
, , ou-b
pour recevoir une invitation à se connecter juste après que le système de fichiers racine soit monté et que soit lancé.
- Redémarrez avec le paramètre du noyau , , , , , ou pour recevoir une invitation à se connecter juste après le montage des systèmes de fichiers locaux.
- Redémarrez avec le paramètre noyau
systemd.debug_shell
pour obtenir un shell root très précoce sur tty9. Basculez dessus en appuyant surCtrl+Alt+F9
. - Expérimentez en redémarrant avec différents jeux de paramètres du noyau pour éventuellement désactiver la fonctionnalité du noyau qui cause la panique. Essayez les "vieux trucs" et .
- En dernier recours, démarrez avec le support d'installation d'Arch Linux et montez le système de fichiers racine sur puis exécutez en tant qu'utilisateur racine.
- Désactivez le service ou le programme à l'origine de la panique, annulez une mise à jour défectueuse ou corrigez un problème de configuration.
Déboguer les régressions
Consultez General troubleshooting (Français)#Débogage des régressions.
Essayez pour vérifier si le problème est déjà corrigé en amont. Le commentaire épinglé mentionne également un dépôt qui contient des noyaux déjà construits, il n'est donc peut-être pas nécessaire de le construire manuellement, ce qui peut prendre un certain temps.
Il peut également être utile d'essayer le noyau LTS () pour déboguer les problèmes qui ne sont pas apparus récemment. Des versions plus anciennes du noyau LTS peuvent être trouvées dans les Archives Arch Linux.
Si le problème persiste, faites une bisection avec et signalez le bogue sur le bugzilla du noyau. Il est important d'essayer la version «vanilla» sans aucun correctif pour s'assurer que le problème n'est pas lié à ceux-ci. Si un patch cause le problème, signalez-le à l'auteur du patch.
Voir aussi
- O'Reilly - Linux Kernel in a Nutshell (livre électronique gratuit)
- Quel noyau stable dois-je utiliser ? par Greg Kroah-Hartman
- Documentation du noyau Linux (en anglais)