Kernel (Français)

État de la traduction:
Cet article est la version francophone de
Kernel
. Date de la dernière traduction: 2026-01-24. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
Kernel modules
Compile kernel module
sysctl
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
dans le répertoire
/usr/lib/modules/
et ensuite utilisés pour copier l'image exécutable
vmlinuz
dans
/boot/
.
[1]
Lorsque vous installez un noyau différent ou que vous passez d'un noyau à l'autre, vous devez configurer votre
chargeur d'amorçage
pour qu'il reflète les changements. Pour rétrograder le noyau vers une version antérieure, consultez
Downgrading packages (Français)#Rétrograder le noyau
.
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). Utile lorsque vous utilisez des modules maintenus en externe qui peuvent ne pas publier de versions compatibles avec le dernier noyau stable à temps.
https://www.kernel.org/
||
linux-lts
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
,
linux-rt-lts
Note
La prise en charge du noyau en temps réel a été fusionnée dans
Linux 6.12
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. Pour plus de détails consultez la
FAQ
et la
Liste detaillée des fonctions
.
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,
[2]
lié depuis
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/pub/scm/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
DRM
— Noyau Linux avec les pilotes GPU les plus récents.
https://gitlab.freedesktop.org/drm/
||
linux-drm-tip-git
AUR
,
linux-drm-next-git
AUR
Longterm
— Le noyau pris en charge à long terme et ses modules.
https://www.kernel.org/
||
linux-lts66
AUR
,
linux-lts61
AUR
,
linux-lts515
AUR
,
linux-lts510
AUR
Noyaux non officiels
linux-cachyos
— Le noyau Linux SCHED-EXT + BORE + la « sauce Cachy », avec d'autres correctifs et améliorations du noyau et des modules.
https://github.com/CachyOS/linux-cachyos
||
linux-cachyos
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
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.
https://pfkernel.natalenko.name
|| Paquets:
Dépôt
,
linux-pf
AUR
par le développeur de pf-kernel
post-factum
Project C
— Noyau avec l'ensemble des modifications du "Project C" d'Alfred Chen (ordonnanceurs BMQ et PDS).
https://gitlab.com/alfredchen/projectc
||
linux-prjc
AUR
Nitrous
— Noyau Linux modifié optimisé pour les processeurs Skylake et ultérieurs.
https://gitlab.com/xdevs23/linux-nitrous
||
linux-nitrous
AUR
Tachyon
— Correctifs issus du projet Clear Linux d'Intel, désormais transférés vers un nouveau projet, le projet Clear Linux ayant été abandonné. Offre des optimisations en termes de performances et de sécurité.
https://git.staropensource.de/StarOpenSource/Linux-Tachyon
||
linux-tachyon
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
|| disponible avec
chaotic-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 le planificateur d'E/S BFQ, le contrôle de congestion
TCP BBRv3
, la prise en charge du jeu d'instructions avancé x86_64, le patchset partial clear linux et d'autres changements par défaut.
https://xanmod.org/
||
linux-xanmod
AUR
,
linux-xanmod-lts
AUR
,
linux-xanmod-rt
AUR
,
linux-xanmod-bore
AUR
Beaucoup de ces noyaux non officiels contiennent des fonctionnalités qui doivent être activées manuellement. Essayez de lire la documentation fournie avec les correctifs eux-mêmes (beaucoup incluent déjà des modifications dans le répertoire
Documentation/
du code source du noyau) ou recherchez le nom du correctif sur le web.
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é.
Code QR sur un écran bleu
Depuis
linux
6.10 (par
drm_panic
), le noyau affiche une panique sous forme de
code QR
(par défaut) sur un écran bleu. La « stack trace » est visible à l'URL fournie par le code QR. Pour Arch Linux, il s'agit d'un lien vers
https://panic.archlinux.org/panic_report
. L'URL contient diverses informations et la « stack trace » compressée par gzip et encodée dans le
fragment d'URL
qui n'est pas transféré au serveur (il est traité côté client).
Un exemple de panique avec un lien et une capture d'écran peut être consulté dans un
message sur le forum anglais
.
Vous pouvez revenir à l'ancien comportement en passant le paramètre
panic_screen=kmsg
au module du noyau
drm
(ou
drm.panic_screen=kmsg
en tant que
paramètre du noyau
) pour afficher la « stack trace » dans une console.
Méthode console
L'ancienne méthode pour examiner le message de panique est de l'afficher sur la console au moment où il se produit est toujours disponible (sans avoir recours à la configuration d'un
kdump crashkernel
). Démarrez 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)
1
kernel: IP: fw_core_init+0x18/0x1000 [firewire_core]
2
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 ...
3
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
4
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
5
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'initramfs 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 le noyau
linux-git
AUR
et et signalez le bogue conformément au processus du noyau pour
signaler les régressions
. En fonction de l'entrée Bugtracker (
B:
) dans le fichier
MAINTAINERS
, cela implique ensuite d'ouvrir un ticket via les listes de diffusion des sous-systèmes, Kernel Bugzilla ou d'autres outils de suivi des problèmes tels que DRM Gitlab. Il est important d'essayer la version « vanilla » sans aucun correctif afin de s'assurer que le problème n'est pas lié à ceux-ci. Si un correctif est à l'origine du problème, signalez-le à l'auteur du correctif.
Note
La bissection du noyau peut prendre beaucoup de temps car il faut éventuellement le reconstruire plusieurs fois
Construire un noyau plus petit
Vous pouvez réduire le temps de construction du noyau en ne construisant que les modules requis par le système local en utilisant
modprobed-db
, ou avec
make localmodconfig
. Bien sûr, vous pouvez complètement abandonner les pilotes non pertinents, par exemple les pilotes de son pour déboguer un problème de réseau.
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)