Kernel (Français)

État de la traduction: Cet article est la version francophone de Kernel. Date de la dernière traduction: 2022-04-06. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

D'après Wikipédia :

Le noyau Linux est un noyau de système d'exploitation monolithique open-source de type Unix.

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.

Les paquets du noyau sont installés sur le système de fichiers sous /boot/. Pour pouvoir démarrer dans les 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.

https://www.kernel.org/ || linux

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.

https://github.com/anthraxx/linux-hardened || linux-hardened

Longterm — Noyau et modules Linux avec prise en charge au long terme (LTS).

https://www.kernel.org/ || linux-lts

Zen Kernel — Résultat d'un effort collaboratif de hackers du noyau pour fournir le meilleur noyau Linux possible pour les systèmes du quotidien. Vous trouverez plus de détails sur https://liquorix.net (qui fournit des binaires de noyau basés sur Zen pour Debian).

https://github.com/zen-kernel/zen-kernel || linux-zen

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 linux 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.

Attention:

L'utilisation de noyaux personnalisés peut causer toutes sortes de problèmes de stabilité et de fiabilité, y compris des pertes de données. Il est fortement conseillé d'avoir des sauvegardes.
Arch Linux n'apporte une assistance officiel que pour les #Noyaux officiellement pris en charge. Si vous utilisez un autre noyau, veuillez le mentionner dans vos demandes d'aide.

Astuce:

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...

Les fichiers config des paquets du noyau Arch sont dans les fichiers sources des paquets Arch (par exemple, [1] 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

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git || linux-git^AUR

Mainline — Noyaux où toutes les nouvelles fonctionnalités sont introduites, publiés tous les 2 ou 3 mois

https://www.kernel.org/ || linux-mainline^AUR

Next — Noyaux de pointe avec des fonctionnalités en attente de fusion dans la prochaine version mainline.

https://www.kernel.org/doc/man-pages/linux-next.html || linux-next-git^AUR

Longterm 4.9 — Le noyau pris en charge à long terme 4.9 et ses modules.

https://www.kernel.org/ || linux-lts49^AUR

Longterm 4.14 — Le noyau pris en charge à long terme 4.14 et ses modules.

https://www.kernel.org/ || linux-lts414^AUR

Longterm 4.19 — Le noyau pris en charge à long terme 4.19 et ses modules.

https://www.kernel.org/ || linux-lts419^AUR

Longterm 5.4 — Le noyau pris en charge à long terme 5.4 et ses modules.

https://www.kernel.org/ || linux-lts54^AUR

Longterm 5.10 — Le noyau pris en charge à long terme 5.10 et ses modules.

https://www.kernel.org/ || linux-lts510^AUR

Noyaux non officiels

Aufs — Le noyau linux et les modules compatibles aufs, utiles lors de l'utilisation de docker.

http://aufs.sourceforge.net/ || linux-aufs^AUR

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.

http://ck.kolivas.org/ || linux-ck^AUR

Clear — Patchs du projet Clear Linux d'Intel. Fournit des optimisations de performance et de sécurité.

https://github.com/clearlinux-pkgs/linux || linux-clear^AUR

GalliumOS — Le noyau et les modules Linux avec les correctifs GalliumOS pour les Chromebooks.

https://github.com/GalliumOS/linux || linux-galliumos^AUR

Libre — Sans «blob» propriétaire ou offuscation pour les pilotes de périphérique.

https://www.fsfla.org/ikiwiki/selibre/linux-libre/ || linux-libre^AUR

Liquorix — Remplacement du noyau construit à l'aide d'une configuration ciblée sur Debian et des sources du noyau Zen. Conçu pour les charges de travail de bureau, multimédia et de jeu, il est souvent utilisé comme noyau de remplacement pour de meilleures performances sous Debian. Damentz, le mainteneur du patchset Liquorix, est également un développeur du patchset Zen. https://liquorix.net

linux-lqx^AUR || not packaged? search in AUR

MultiPath TCP — Le noyau Linux et les modules avec la prise en charge de Multipath TCP.

https://multipath-tcp.org/ || linux-mptcp^AUR

pf-kernel — Fournit une poignée de fonctionnalités géniales qui ne sont pas intégrées dans le noyau principal. Maintenu par un ingénieur du noyau. Si le portage du patch inclus pour les nouveaux noyaux n'a pas été publié officiellement, le patchset fournit et prend en charge les ports de patchs pour les nouveaux noyaux. Les correctifs actuels les plus importants de linux-pf sont PDS CPU scheduler et UKSM.

https://gitlab.com/post-factum/pf-kernel/wikis/README || Packages:

Dépôt par le développeur de pf-kernel post-factum
Dépôt, linux-pf^AUR, linux-pf-preset-default^AUR par le développeur de pf-kernel fork Thaodan
linux-pf-git^AUR par yurikoles

Noyau temps réel — Maintenu par un petit groupe de développeurs principaux dirigé par Ingo Molnar. Ce patch permet de préempter la quasi-totalité du noyau, à l'exception de quelques très petites régions de code ("raw_spinlock critical regions"). Ceci est réalisé en remplaçant la plupart des spinlocks du noyau par des mutex qui prennent en charge l'héritage des priorités, ainsi qu'en déplaçant toutes les interruptions et les interruptions logicielles vers les threads du noyau.

https://wiki.linuxfoundation.org/realtime/start || linux-rt^AUR, linux-rt-lts^AUR

tkg — Un système de construction du noyau hautement personnalisable qui fournit une sélection de correctifs et de réglages visant à améliorer les performances des ordinateurs de bureau et des jeux. Il est maintenu par Etienne Juvigny. Entre autres correctifs, il offre divers ordonnanceurs de CPU : CFS, Project C PDS, Project C BMQ, MuQSS et CacULE.

https://github.com/Frogging-Family/linux-tkg || not packaged? search in AUR

VFIO — Le noyau Linux et quelques correctifs écrits par Alex Williamson (acs override et i915) pour permettre la possibilité de faire du PCI Passthrough avec KVM sur certaines machines.

https://lwn.net/Articles/499240/ || linux-vfio^AUR, linux-vfio-lts^AUR

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-xanmod^AUR, linux-xanmod-tt^AUR

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.

Note: Les paniques du noyau sont parfois appelées oops ou kernel oops. Si les paniques et les oops résultent tous deux d'un état de défaillance, un oops est plus général en ce sens qu'il n'entraîne pas nécessairement un blocage de la machine : parfois, le noyau peut se remettre d'un oops en tuant la tâche incriminée et en continuant son travail.

Astuce: Passez le paramètre noyau oops=panic au démarrage ou écrivez 1 dans /proc/sys/kernel/panic_on_oops pour forcer un oops récupérable à émettre une panique à la place. Ceci est conseillé si vous êtes préoccupé par la petite chance d'instabilité du système résultant d'une récupération d'oops qui peut rendre les erreurs futures difficiles à diagnostiquer.

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 system-journald 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

Astuce: Dans le cas où le message de panique défile trop rapidement pour être examiné, essayez de passer le paramètre noyau pause_on_oops=seconds au démarrage.

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 :

kernel: BUG: unable to handle kernel NULL pointer dereference at (null) ¹
kernel: IP: fw_core_init+0x18/0x1000 [firewire_core] ²
kernel: PGD 718d00067
kernel: P4D 718d00067
kernel: PUD 7b3611067
kernel: PMD 0
kernel:
kernel: Oops: 0002 [#1] PREEMPT SMP
kernel: Modules linked in: firewire_core(+) crc_itu_t cfg80211 rfkill ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG nf_conntrack_ipv4 ... ³
kernel: CPU: 6 PID: 1438 Comm: modprobe Tainted: P           O    4.13.3-1-ARCH #1
kernel: Hardware name: Gigabyte Technology Co., Ltd. H97-D3H/H97-D3H-CF, BIOS F5 06/26/2014
kernel: task: ffff9c667abd9e00 task.stack: ffffb53b8db34000
kernel: RIP: 0010:fw_core_init+0x18/0x1000 [firewire_core]
kernel: RSP: 0018:ffffb53b8db37c68 EFLAGS: 00010246
kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
kernel: RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffffc16d3af4
kernel: RBP: ffffb53b8db37c70 R08: 0000000000000000 R09: ffffffffae113e95
kernel: R10: ffffe93edfdb9680 R11: 0000000000000000 R12: ffffffffc16d9000
kernel: R13: ffff9c6729bf8f60 R14: ffffffffc16d5710 R15: ffff9c6736e55840
kernel: FS:  00007f301fc80b80(0000) GS:ffff9c675dd80000(0000) knlGS:0000000000000000
kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
kernel: CR2: 0000000000000000 CR3: 00000007c6456000 CR4: 00000000001406e0
kernel: Call Trace:
kernel:  do_one_initcall+0x50/0x190 ⁴
kernel:  ? do_init_module+0x27/0x1f2
kernel:  do_init_module+0x5f/0x1f2
kernel:  load_module+0x23f3/0x2be0
kernel:  SYSC_init_module+0x16b/0x1a0
kernel:  ? SYSC_init_module+0x16b/0x1a0
kernel:  SyS_init_module+0xe/0x10
kernel:  entry_SYSCALL_64_fastpath+0x1a/0xa5
kernel: RIP: 0033:0x7f301f3a2a0a
kernel: RSP: 002b:00007ffcabbd1998 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
kernel: RAX: ffffffffffffffda RBX: 0000000000c85a48 RCX: 00007f301f3a2a0a
kernel: RDX: 000000000041aada RSI: 000000000001a738 RDI: 00007f301e7eb010
kernel: RBP: 0000000000c8a520 R08: 0000000000000001 R09: 0000000000000085
kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000c79208
kernel: R13: 0000000000c8b4d8 R14: 00007f301e7fffff R15: 0000000000000030
kernel: Code: <c7> 04 25 00 00 00 00 01 00 00 00 bb f4 ff ff ff e8 73 43 9c ec 48
kernel: RIP: fw_core_init+0x18/0x1000 [firewire_core] RSP: ffffb53b8db37c68
kernel: CR2: 0000000000000000
kernel: ---[ end trace 71f4306ea1238f17 ]---
kernel: Kernel panic - not syncing: Fatal exception ⁵
kernel: Kernel Offset: 0x80000000 from 0xffffffff810000000 (relocation range: 0xffffffff800000000-0xfffffffffbffffffff
kernel: ---[ end Kernel panic - not syncing: Fatal exception

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 rd.blacklist=firewire_core.
Sinon, redémarrez avec le paramètre du noyau module_blacklist=firewire_core.

Redémarrez dans le shell root et corrigez le problème

This article or section is out of date.

Reason: rd.rescue et rd.emergency ne fonctionneront pas car le compte root dans l'initrmafs est verrouillé. (Discuss in Talk:Kernel (Français))

The factual accuracy of this article or section is disputed.

Reason: Le clavier ne fonctionne pas dans rd.emergency et ne peut donc pas être utilisé. (Discuss in Talk:Kernel (Français))

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, rd.emergency, ou -b pour recevoir une invitation à se connecter juste après que le système de fichiers racine soit monté et que systemd soit lancé.

Note: À ce stade, le système de fichiers racine sera monté en lecture seule. Exécutez mount -o remount,rw / en tant que super-utilisateur pour effectuer des changements.

Redémarrez avec le paramètre du noyau rescue, rd.rescue, single, s, S, ou 1 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 sur Ctrl+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" acpi=off et nolapic.

Astuce: Voir kernel-parameters.html pour tous les paramètres du noyau.

En dernier recours, démarrez avec le support d'installation d'Arch Linux et montez le système de fichiers racine sur /mnt puis exécutez arch-chroot /mnt 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.

Astuce: Il peut être nécessaire de générer une nouvelle image initial ramdisk si l'original est corrompu. Cela peut se produire lorsqu'une mise à jour du noyau est interrompue. Pour en créer une nouvelle, voir mkinitcpio.

Déboguer les régressions

Consultez General troubleshooting (Français)#Débogage des régressions.

Essayez linux-mainline^AUR 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 (linux-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 linux-git^AUR 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.

Note: La bissection du noyau peut prendre beaucoup de temps car il faut éventuellement le reconstruire plusieurs fois

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)