Le gaming sous Linux va profiter d’un important gain de performances avec l’arrivée du noyau Linux 7.3. C’est du moins la promesse de plusieurs modifications du planificateur CPU. Les travaux portent sur une amélioration de la latence, l’efficacité de la répartition des tâches et le comportement du système sur les architectures modernes. Ces changements concernent …
Kubuntu Focus is funding at least three years of backported bug and security fixes for KDE Plasma 6.6, turning the desktop into the first Plasma 6 release with a dedicated long-term-support lifecycle. The “Bullet-Proof KDE Initiative” also covers the matching KDE Frameworks 6.24 and KDE Gear 25.12 components shipped with Kubuntu 26.04, and other Linux distributions can adopt the maintained versions.
Canonical expects Ubuntu running through Windows Subsystem for Linux (WSL) to overtake native Ubuntu desktop installations within the next few months. The prediction reflects faster growth among Ubuntu users on Windows 11, where developers and AI engineers can access Linux tools without replacing Windows or configuring dual boot.
The Linux kernel is making the x86 Time Stamp Counter (TSC) mandatory, removing the final option to build a kernel without it. The change ends Linux’s decades-long compatibility path for very old processors and lets the kernel discard timing code that detected, calibrated, and worked around missing or unreliable TSC hardware.
Hazmat is a free, open-source containment tool for running AI coding agents without exposing an administrator’s normal user account, SSH keys, or cloud credentials. It creates a separate local account, limits access to a selected project, and wraps agents including Claude Code, Codex, OpenCode, and Cursor Agent.
Linux 7.2 is now stable after a turbulent final stretch that followed an unusually large RC6 and an AI-heavy RC7. Linus Torvalds kept the August 16 release on schedule, despite a late surge of fixes and a rollback of problematic DRM GPU scheduling changes.
Ce serait trop cool non, si avec un double-clic sur un .docx dans votre gestionnaire de fichiers Linux, Word s'ouvrait directement ? Et je ne vous parle pas d'un bureau Windows complet en plein écran ou d'une session de bureau à distance. Juste une fenêtre Word tout ce qu'il y a de plus classique, avec son icône dans votre barre des tâches, épinglable et "alt-tabbable" comme le reste.
Hé bien, c'est ce que fait
WinPodX
, qui fait tourner un conteneur Windows sous KVM en arrière-plan et découpe l'affichage application par application via FreeRDP RemoteApp. Comme ça, les liens mailto: partent vers Outlook ou les schémas slack: ou vnc: vers l'application qui les a déclarés.
Tout ce qui est presse-papiers, son, imprimantes et votre dossier personnel sont partagés d'office, et le conteneur se met en pause tout seul quand personne ne s'en sert.
Jusque-là,
WinApps dont je vous ai déjà causé, qui fait tourner Office sous Linux
, faisait déjà l'essentiel avec les fenêtres détachées, le dossier personnel partagé, le clic droit qui envoie un fichier vers une application Windows. Mais WinPodX se distingue aussi dans l'autre sens puisque vos applications Linux remontent également dans le menu "Ouvrir avec..." du Windows, et dans un dossier "Linux Apps" du menu Démarrer. Bref, l'accès aux apps et aux fichiers marche dans les 2 sens, pour plus de transparence dans vos usages.
Si ça vous intéresse, sachez qu'il vous faut une licence Windows valide, car WinPodX ne la fournit pas (logique), que la virtualisation doit être activée dans le BIOS, avoir un accès à /dev/kvm, 8 Go de RAM et une trentaine de gigas de libre. La première installation prend cinq à dix minutes le temps de télécharger l'ISO, et les suivantes sont quasi instantanées.
Il y a également un paquet pour openSUSE, Fedora, Debian, Ubuntu, Arch et NixOS, un AppImage pour les autres. C'est sous licence MIT, et sans aucune télémétrie puisque celle de Windows a été elle-même coupée par défaut. Ah et l'interface du OuinOuin peut être configurée en français.
Par contre, pas d'accélération GPU, ce qui exclut les jeux et la 3D à moins de monter un passthrough à la main. Préférez Wine pour ça...
Au démarrage de Linux, le noyau doit pouvoir identifier et monter la partition racine / pour accéder aux fichiers nécessaires au fonctionnement du système. Lorsque cette étape échoue, le démarrage peut s’interrompre sur un Kernel Panic accompagné du message :
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(...)
Cette erreur peut apparaître après une mise à jour du noyau, une modification des partitions ou de GRUB, mais aussi à cause d’un initramfs endommagé, d’un UUID incorrect, d’un pilote de stockage manquant, d’un système de fichiers corrompu ou d’un SSD/disque défaillant.
Il n’est généralement pas nécessaire de réinstaller Linux. En identifiant à quelle étape l’accès à la partition racine échoue, il est souvent possible de réparer le démarrage depuis GRUB, le mode de récupération ou un Live USB Linux.
Dans ce guide, découvrez les causes de l’erreur « VFS: Unable to mount root fs » et les solutions pour démarrer sur un ancien noyau, vérifier la partition racine et son UUID, reconstruire l’initramfs, réparer le système de fichiers et retrouver un Linux fonctionnel.
Qu’est-ce que l’erreur « VFS: Unable to mount root fs » ?
L’erreur « VFS: Unable to mount root fs » est un Kernel Panic qui se produit pendant le démarrage de Linux lorsque le noyau ne parvient pas à accéder ou à monter le système de fichiers racine.
Le message se présente généralement sous une forme proche de :
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Le système de fichiers racine, représenté par /, contient les fichiers indispensables au fonctionnement de Linux. Si le noyau ne parvient pas à le monter, il ne peut pas poursuivre normalement la séquence de démarrage et déclenche alors un Kernel Panic.
Le problème peut apparaître très tôt au démarrage, parfois juste après une mise à jour du noyau, une modification des partitions ou une opération ayant affecté l’initramfs ou le stockage.
Que signifie VFS ?
VFS (Virtual File System) est la couche du noyau Linux qui fournit une interface commune aux différents systèmes de fichiers, tels que ext4, XFS ou Btrfs.
Lorsque le message indique :
VFS: Unable to mount root fs
cela signifie donc que le noyau n’a pas réussi à monter le système de fichiers devant devenir la racine /.
Cela ne signifie pas nécessairement que le système de fichiers lui-même est endommagé. Le noyau peut tout simplement ne pas parvenir à trouver le périphérique qui le contient ou ne pas disposer du pilote nécessaire pour y accéder.
Que signifie « unknown-block » ?
La fin du message fournit également un indice important :
unknown-block(0,0)
Les deux nombres correspondent à des identifiants utilisés par Linux pour représenter le périphérique de stockage.
Lorsque le message indique unknown-block(0,0), le noyau ne parvient généralement pas à identifier correctement le périphérique contenant la partition racine. Il faut alors rechercher en priorité un problème concernant l’initramfs, le paramètre root=, l’UUID de la partition ou le pilote du contrôleur de stockage.
Dans d’autres situations, vous pouvez rencontrer par exemple :
unknown-block(8,1)
Le noyau a alors identifié un périphérique bloc précis, ce qui peut davantage orienter les recherches vers la partition, le système de fichiers ou son accessibilité.
Le contenu exact de unknown-block(...) constitue donc un indice de diagnostic, mais ne permet pas à lui seul de déterminer la cause.
Quelles sont les causes de « Unable to mount root fs » ?
L’erreur « VFS: Unable to mount root fs » signifie que le noyau Linux n’arrive pas à monter la partition racine /. Plusieurs problèmes peuvent interrompre la chaîne de démarrage entre GRUB, le noyau, l’initramfs et le périphérique de stockage.
Le message unknown-block(...) ainsi que les erreurs affichées juste avant le Kernel Panic peuvent fournir de précieux indices.
Mise à jour interrompue, mauvaise génération de l’image
Erreur apparue après une mise à jour du noyau
Nouveau noyau défectueux ou incompatible
Régression du kernel, module incompatible
Ancien noyau fonctionnel depuis GRUB
Mauvaise partition racine
Paramètre root= incorrect
UUID ou périphérique différent de la partition réelle
UUID incorrect
Partition recréée, clonée ou modifiée
UUID de GRUB/fstab différent de celui retourné par blkid
Pilote de stockage absent
NVMe, SATA, RAID ou contrôleur non disponible dans l’initramfs
Souvent unknown-block(0,0)
Système de fichiers endommagé
Corruption ext4, XFS, Btrfs…
Erreurs de système de fichiers avant le panic
SSD ou disque défaillant
Erreurs de lecture ou contrôleur instable
I/O error, erreurs NVMe/SATA
Configuration GRUB incorrecte
Mauvaise entrée ou paramètres du noyau erronés
Mauvais root=, problème après modification de GRUB
Démarrer Linux avec un ancien noyau
Si l’erreur « VFS: Unable to mount root fs » est apparue juste après une mise à jour du noyau Linux, commencez par essayer de démarrer avec la version précédente du kernel.
Linux conserve généralement plusieurs noyaux installés. Il est donc possible de sélectionner un ancien kernel depuis GRUB sans désinstaller immédiatement la nouvelle version.
Sélectionner un ancien noyau depuis GRUB
Redémarrez le PC et affichez le menu GRUB. Selon la distribution et la configuration, vous devrez éventuellement maintenir la touche Maj (Shift) ou appuyer plusieurs fois sur Échap (Esc) pendant le démarrage.
Ensuite :
Sélectionnez Options avancées pour Ubuntu, ou l’entrée équivalente de votre distribution.
GRUB affiche les différentes versions du noyau disponibles.
Sélectionnez une version antérieure du noyau, sans choisir le mode Recovery dans un premier temps.
Démarrez Linux normalement.
Si le système démarre correctement, vérifiez le noyau actuellement utilisé avec :
uname -r
Vous pouvez également afficher les noyaux présents dans /boot :
ls -lh /boot
Si l’ancien noyau fonctionne
Si Linux démarre avec le kernel précédent mais affiche « Unable to mount root fs » avec la version la plus récente, cela constitue un indice important.
Le problème peut notamment concerner :
L’initramfs associé au nouveau noyau.
Un pilote ou module de stockage absent de cet initramfs.
Un module DKMS qui n’a pas été correctement reconstruit.
Une régression ou une incompatibilité avec le nouveau kernel.
Dans ce cas, évitez de supprimer immédiatement l’ancien noyau fonctionnel : il constitue une solution de secours pendant le diagnostic.
Vous pouvez ensuite tenter de reconstruire l’initramfs du noyau problématique et mettre à jour la configuration de GRUB.
Si aucun ancien noyau ne démarre
Si plusieurs versions du noyau provoquent la même erreur, la piste d’une simple régression du kernel devient moins probable.
Il faut alors vérifier en priorité la partition racine, son UUID, l’initramfs, le système de fichiers et le périphérique de stockage.
Si Linux ne démarre avec aucun noyau disponible, utilisez le mode de récupération ou un Live USB Linux afin d’accéder au système et d’effectuer les réparations.
Le démarrage avec un ancien noyau constitue donc surtout un test de diagnostic rapide : si l’ancien kernel fonctionne, concentrez les recherches sur ce qui a changé avec la nouvelle version plutôt que de modifier immédiatement les partitions ou le système de fichiers.
Démarrer en mode de récupération
Si Linux ne démarre toujours pas normalement, le mode de récupération (Recovery Mode) permet d’accéder à plusieurs outils de dépannage sans charger complètement le système.
Il est particulièrement utile avec l’erreur « VFS: Unable to mount root fs », car il peut permettre d’obtenir un shell administrateur et d’effectuer certaines réparations sur le système de fichiers, l’initramfs ou la configuration du démarrage.
Depuis GRUB, ouvrez généralement Options avancées, puis sélectionnez une entrée du noyau comportant la mention Recovery Mode.
Selon la distribution et la situation, vous pourrez notamment :
Accéder à un shell root.
Vérifier ou réparer le système de fichiers.
Reconstruire l’initramfs.
Corriger une mise à jour de paquets interrompue.
Vérifier les partitions et leurs UUID.
Mettre à jour la configuration de GRUB.
Examiner les journaux et messages d’erreur.
Si plusieurs noyaux sont proposés, vous pouvez également essayer le mode de récupération d’un ancien kernel lorsque l’erreur est apparue après une mise à jour.
Pour accéder au mode Recovery et connaître les différents outils disponibles, suivez le guide correspondant à votre distribution :
Si le mode de récupération ne démarre pas non plus ou provoque le même Kernel Panic, utilisez plutôt un Live USB Linux. Celui-ci permettra d’accéder aux partitions depuis un système indépendant afin de vérifier le stockage, réparer le système de fichiers ou reconstruire l’initramfs.
Vérifier la partition racine et son UUID
L’erreur « VFS: Unable to mount root fs » peut apparaître lorsque le noyau Linux cherche la partition racine / au mauvais emplacement. Cela peut notamment se produire après un clonage de disque, une modification du partitionnement, une restauration ou un changement incorrect de la configuration de démarrage.
L’objectif est donc de vérifier que la partition existe toujours et que son UUID correspond à celui utilisé par Linux et GRUB.
Identifier la partition racine
Depuis le mode de récupération ou un Live USB Linux, affichez les partitions et leurs systèmes de fichiers :
lsblk -f
Vous pouvez compléter avec :
sudo blkid
Repérez la partition contenant votre installation Linux, par exemple :
L’UUID doit correspondre à celui obtenu avec lsblk -f ou blkid.
Si les valeurs sont différentes, Linux peut essayer de monter une ancienne partition ou un système de fichiers dont l’identifiant a changé.
Ne modifiez toutefois pas /etc/fstab avant d’avoir identifié avec certitude la partition racine.
Vérifier le paramètre root= de GRUB
GRUB indique également au noyau où se trouve la partition racine grâce au paramètre root=.
Si Linux démarre avec un ancien noyau, affichez les paramètres utilisés :
cat /proc/cmdline
Vous pouvez notamment obtenir :
root=UUID=a1b2c3d4-e5f6-7890-abcd-123456789abc
Vérifiez là encore que cet UUID correspond à celui de la véritable partition racine.
Si Linux ne démarre plus, sélectionnez son entrée dans GRUB puis appuyez sur e. Recherchez la ligne commençant par linux et vérifiez la valeur :
root=UUID=...
Vous pouvez temporairement remplacer un UUID incorrect par le bon afin de tester le démarrage. Cette modification n’est valable que pour cette tentative et ne change pas définitivement la configuration de GRUB.
Si Linux démarre après cette correction, vous avez probablement identifié la cause du problème.
Corriger définitivement l’UUID
Une fois Linux démarré, corrigez si nécessaire l’UUID incorrect dans /etc/fstab ou la configuration concernée, puis régénérez GRUB.
Sur Ubuntu et Debian :
sudo update-grub
Si la partition racine, son UUID et le paramètre root= sont déjà corrects mais que le Kernel Panic affiche toujours unknown-block(0,0), le problème vient probablement d’une autre étape du démarrage.
Il faut alors vérifier en priorité l’initramfs et les pilotes nécessaires pour accéder au périphérique de stockage.
Reconstruire l’initramfs
L’initramfs est chargé très tôt pendant le démarrage de Linux. Il contient notamment les modules et outils nécessaires pour détecter le périphérique de stockage et accéder à la partition racine /.
S’il est endommagé, incomplet ou ne contient plus un pilote nécessaire, le noyau peut ne pas parvenir à monter la partition racine et afficher l’erreur « VFS: Unable to mount root fs ». Cette situation peut notamment survenir après une mise à jour du noyau ou d’un pilote.
Reconstruire l’initramfs sur Ubuntu et Debian
Si vous pouvez démarrer avec un ancien noyau ou depuis le mode de récupération, reconstruisez les images initramfs avec :
sudo update-initramfs -u -k all
Pour reconstruire uniquement celle du noyau actuellement utilisé :
sudo update-initramfs -u -k "$(uname -r)"
Mettez ensuite à jour GRUB :
sudo update-grub
Puis redémarrez le PC et essayez à nouveau le noyau qui provoquait l’erreur.
Reconstruire l’initramfs sur Fedora et RHEL
Fedora, RHEL et plusieurs distributions dérivées utilisent généralement dracut.
Pour reconstruire l’initramfs du noyau en cours :
sudo dracut --force
Si plusieurs noyaux sont installés, vérifiez leurs versions :
ls /lib/modules/
Lorsque vous devez réparer un noyau différent de celui actuellement démarré, veillez à reconstruire l’image correspondant à la bonne version du kernel.
Vérifier que l’initramfs existe
Vous pouvez contrôler les images présentes dans /boot :
ls -lh /boot
Selon la distribution, vous devez notamment retrouver des fichiers de type :
vmlinuz-...
initrd.img-...
ou :
initramfs-....img
Vérifiez qu’une image initramfs existe bien pour le noyau que vous essayez de démarrer. Un nouveau kernel accompagné d’un initramfs absent ou mal généré peut expliquer pourquoi l’ancien noyau fonctionne alors que le nouveau provoque le Kernel Panic.
Si Linux ne démarre plus du tout
Si aucun noyau ou mode de récupération ne permet de démarrer, utilisez un Live USB Linux. Vous pourrez monter l’installation existante, entrer dans le système avec chroot, puis reconstruire l’initramfs et mettre à jour GRUB.
Le principe est alors : Live USB → monter Linux → chroot → reconstruire l’initramfs → mettre à jour GRUB
Inutile de détailler ici toute la procédure chroot, puisqu’elle est déjà expliquée dans le guide dédié.
Si l’erreur persiste
Si l’initramfs a été correctement reconstruit mais que le noyau affiche toujours unknown-block(0,0), vérifiez ensuite que l’image contient bien les pilotes nécessaires au contrôleur de stockage.
Si le SSD ou le disque est détecté mais que la partition racine ne peut toujours pas être montée, recherchez plutôt un système de fichiers endommagé ou un problème avec le périphérique de stockage.
Vérifier et réparer le système de fichiers
Si le noyau détecte correctement la partition racine mais n’arrive pas à monter son système de fichiers, une corruption de celui-ci peut provoquer l’erreur « VFS: Unable to mount root fs ».
Ce problème peut notamment apparaître après un arrêt brutal du PC, une coupure de courant, un plantage pendant une écriture ou des erreurs provenant du SSD ou du disque dur.
Recherchez dans les messages précédant le Kernel Panic des indications comme :
Sous Linux, la commande fsck permet de vérifier et, selon le système de fichiers, de réparer les erreurs détectées. fsck sert en réalité d’interface aux outils adaptés au type de système de fichiers concerné.
Commencez par identifier la partition et son système de fichiers :
lsblk -f
Par exemple, si la partition racine utilise ext4 et correspond à /dev/nvme0n1p2, vous pouvez effectuer sa vérification depuis un Live USB ou un environnement de récupération, une fois la partition démontée :
sudo fsck /dev/nvme0n1p2
Selon les erreurs rencontrées, l’outil peut proposer de réparer les incohérences détectées.
Attention : n’effectuez pas une réparation fsck sur la partition racine montée en lecture/écriture. Pour les systèmes de fichiers ext2/ext3/ext4 notamment, e2fsck déconseille explicitement la vérification d’un système de fichiers monté. Utilisez de préférence le mode de récupération ou un Live USB.
Pour connaître les différentes options et méthodes de réparation, consultez notre guide complet :
Enfin notez que vous pouvez effectuer un fsck depuis les options de récupération :
Attention au type de système de fichiers
Tous les systèmes de fichiers ne se réparent pas de la même manière. Pour XFS, par exemple, fsck.xfs ne réalise pas directement la réparation : l’outil dédié est xfs_repair.
Btrfs utilise également ses propres outils de vérification et de réparation ; fsck.btrfs n’effectue pas une vérification classique.
Il est donc important d’identifier le système de fichiers avec lsblk -f avant de lancer une réparation.
Si les erreurs réapparaissent après avoir réparé le système de fichiers, ne vous contentez pas de relancer régulièrement fsck. Des corruptions répétées peuvent être le symptôme d’un SSD ou disque défaillant, d’erreurs d’entrée/sortie ou d’une autre instabilité matérielle.
Dans ce cas, l’étape suivante consiste à vérifier l’état du périphérique de stockage.
Vérifier le SSD ou le disque dur
Si l’erreur « VFS: Unable to mount root fs » s’accompagne d’erreurs d’entrée/sortie ou si le système de fichiers se corrompt régulièrement, vérifiez également l’état du SSD ou du disque dur.
Un périphérique de stockage défaillant peut empêcher le noyau de lire correctement la partition racine. Dans ce cas, reconstruire l’initramfs ou réparer le système de fichiers peut ne résoudre le problème que temporairement.
Rechercher les erreurs de stockage
Depuis le mode de récupération ou un Live USB, consultez les messages du noyau :
lsblk permet d’obtenir les informations sur les périphériques bloc détectés par Linux.
Repérez le SSD ou disque contenant la partition racine avant de poursuivre les vérifications.
Vérifier les données SMART
Les SSD et disques compatibles exposent généralement des informations S.M.A.R.T. permettant de surveiller leur état de santé, les erreurs enregistrées et différents indicateurs d’usure. Sous Linux, ces données peuvent notamment être interrogées avec smartctl, fourni par smartmontools.
Comme tu as déjà un guide complet consacré à cette vérification, je ne détaillerais pas ici toutes les commandes et attributs SMART :
L’objectif est notamment de rechercher des erreurs matérielles, des secteurs problématiques, une usure anormale du SSD ou des erreurs enregistrées par le contrôleur.
Si le stockage présente des signes de défaillance, sauvegardez vos données importantes avant d’effectuer des réparations répétées du système de fichiers.
À l’inverse, si le disque est en bon état, que la partition est correctement détectée et que son système de fichiers ne présente pas d’erreur, revenez plutôt aux pistes liées à l’initramfs, aux pilotes de stockage ou à la configuration du démarrage.
Vérifier les pilotes de stockage dans l’initramfs
Pour monter la partition racine /, le noyau doit pouvoir détecter le SSD ou le disque dès les premières étapes du démarrage. Les pilotes nécessaires au contrôleur de stockage doivent donc être disponibles dans l’initramfs.
Si un module NVMe, SATA, RAID ou correspondant à un contrôleur particulier est absent, Linux peut ne pas détecter le périphérique contenant la partition racine et afficher notamment :
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Cette piste est particulièrement intéressante lorsque le problème apparaît après une mise à jour du noyau, une reconstruction de l’initramfs ou une modification de la configuration du stockage.
Identifier le pilote de stockage utilisé
Si vous pouvez démarrer avec un ancien noyau fonctionnel, identifiez le contrôleur de stockage et le pilote utilisé :
Vous pouvez également rechercher les principaux modules de stockage chargés :
lsmod | grep -Ei "nvme|ahci|ata|scsi|raid"
Selon le matériel, vous pouvez par exemple rencontrer nvme, nvme_core, ahci ou libahci. Le module réellement nécessaire dépend toutefois du contrôleur présent sur le PC.
Vérifier que le module est présent dans l’initramfs
Sur Ubuntu et Debian, affichez d’abord les images disponibles :
ls -lh /boot/initrd.img-*
Puis recherchez le pilote dans l’initramfs correspondant au noyau qui ne démarre pas. Par exemple pour NVMe :
Si l’ancien noyau démarre correctement, comparer son initramfs avec celui du nouveau kernel peut aider à repérer un module absent dans l’image problématique.
Que faire si le pilote est absent ?
Si vous avez identifié avec certitude un module indispensable absent de l’initramfs, commencez par reconstruire l’image comme expliqué dans la section précédente.
Sur Ubuntu/Debian :
sudo update-initramfs -u -k all
sudo update-grub
Si le module reste absent, il est possible de forcer son inclusion dans l’initramfs. Cette opération dépend toutefois de la distribution et ne doit être effectuée qu’après avoir identifié précisément le pilote nécessaire.
Cas des volumes RAID, LVM ou chiffrés
La détection du disque ne suffit pas toujours. Si la partition racine se trouve sur LVM, un RAID ou un volume chiffré, l’initramfs doit également disposer des composants nécessaires pour assembler ou déverrouiller le volume avant de pouvoir monter /.
Ainsi, si le SSD apparaît correctement depuis un Live USB mais que Linux affiche toujours unknown-block au démarrage, vérifiez la configuration de l’initramfs et la manière dont la partition racine est construite.
Si les pilotes nécessaires sont bien présents, poursuivez plutôt le diagnostic du côté de l’UUID, de GRUB, du système de fichiers ou du stockage lui-même.
Réparer depuis un Live USB Linux
Si Linux ne démarre avec aucun noyau disponible ni en mode de récupération, utilisez un Live USB Linux. Celui-ci permet d’accéder au système installé depuis un environnement indépendant afin d’effectuer les réparations.
Commencez par identifier et monter la partition racine comme expliqué dans la section « Vérifier la partition racine et son UUID ». Profitez également du Live USB pour sauvegarder vos fichiers importants si vous suspectez une corruption du système de fichiers ou un problème de stockage.
Une fois la partition montée, vous pouvez utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.
Réparer l’installation avec chroot
Pour reconstruire l’initramfs ou corriger la configuration de démarrage, vous pouvez ensuite utiliser chroot afin d’exécuter les commandes dans l’environnement du Linux installé.
Cette opération nécessite notamment de monter certains systèmes virtuels et, selon la configuration, les partitions /boot et EFI. La procédure étant identique à celle utilisée pour réparer GRUB depuis un Live USB, suivez le guide dédié :
mkdir -p /tmp/chroot
sudo mount -t ext4 /dev/sda2 /tmp/chroot
sudo mount --bind /proc /tmp/chroot/proc
sudo mount --bind /dev /tmp/chroot/dev
sudo mount --bind /sys /tmp/chroot/sys
sudo chroot /tmp/chroot/
Une fois dans le chroot, sur Ubuntu ou Debian, reconstruisez l’initramfs :
update-initramfs -u -k all
Puis régénérez la configuration de GRUB :
update-grub
Sur Fedora, RHEL ou une distribution utilisant dracut, reconstruisez l’initramfs avec l’outil correspondant à votre distribution.
Quittez ensuite le chroot, démontez proprement les partitions puis redémarrez le PC sans le Live USB.
Si l’erreur « VFS: Unable to mount root fs » persiste malgré un UUID correct et un initramfs reconstruit, poursuivez les vérifications du côté des pilotes de stockage, du système de fichiers et de l’état du SSD ou du disque dur.
Que faire si l’erreur persiste ?
Si Linux affiche toujours « VFS: Unable to mount root fs » après les vérifications précédentes, évitez de multiplier les modifications au hasard. À ce stade, il faut déterminer précisément à quelle étape l’accès à la partition racine échoue.
Vérifiez en priorité les points suivants :
Essayez un ancien noyau Linux depuis GRUB.
Vérifiez que la partition racine est bien détectée avec lsblk -f et blkid.
Comparez son UUID avec celui utilisé dans /etc/fstab et le paramètre root= de GRUB.
Reconstruisez l’initramfs et vérifiez qu’il contient les pilotes de stockage nécessaires.
Contrôlez et réparez le système de fichiers si des erreurs sont détectées.
Vérifiez l’état de santé du SSD ou du disque dur.
Recherchez les messages I/O error, nvme, ata, EXT4-fs error ou similaires avant le Kernel Panic.
Utilisez un Live USB Linux lorsque le système installé ne permet plus d’effectuer ces opérations.
Le message unknown-block(...) peut également aider à orienter les recherches. Un unknown-block(0,0) suggère notamment que le noyau ne parvient pas à identifier correctement le périphérique racine, ce qui renforce les pistes liées à l’initramfs, au paramètre root= ou au pilote de stockage.
À l’inverse, si le périphérique est identifié mais que son système de fichiers ne peut pas être monté, concentrez davantage les vérifications sur la partition, le système de fichiers et l’état du stockage.
Sauvegarder les données avant d’aller plus loin
Si le SSD ou le disque présente des erreurs ou si le système de fichiers se corrompt régulièrement, sauvegardez vos fichiers importants avant de poursuivre les réparations.
Un Live USB permet généralement d’accéder à la partition Linux et de copier les données vers un autre support, à condition que le stockage reste suffisamment fonctionnel.
Évitez notamment d’enchaîner les réparations du système de fichiers sur un disque présentant des erreurs matérielles : la priorité devient alors la récupération des données et le remplacement du périphérique défaillant.
Une réinstallation peut être envisagée si le stockage est sain mais que le système reste impossible à démarrer malgré :
UUID correct → système de fichiers sain → initramfs reconstruit → pilotes présents → GRUB corrigé.
Elle doit toutefois rester une solution de dernier recours. L’erreur « Unable to mount root fs » possède souvent une cause précise qu’il est possible de corriger sans réinstaller complètement Linux.
Si le problème s’accompagne d’autres Kernel Panic, de blocages ou d’erreurs matérielles sans rapport apparent, élargissez également le diagnostic au reste du PC.
Un Kernel Panic est l’une des erreurs les plus critiques que peut rencontrer un système Linux. Il se produit lorsque le noyau détecte une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement. Le système peut alors se figer complètement, afficher une série de messages techniques ou redémarrer automatiquement.
Identifier l’origine d’un Kernel Panic nécessite donc d’examiner les messages du noyau et les événements ayant précédé le plantage. Des outils comme journalctl, dmesg, lsmod ou kdump permettent de récupérer des informations précieuses et d’orienter le diagnostic vers un problème logiciel ou matériel.
Dans ce guide, découvrez comment diagnostiquer un Kernel Panic sous Linux, récupérer et analyser les journaux, identifier un pilote ou module responsable, vérifier le matériel et réparer un système qui ne démarre plus après le plantage.
Un Kernel Panic est une erreur critique du noyau Linux qui se produit lorsque celui-ci rencontre une situation suffisamment grave pour qu’il ne puisse plus continuer à fonctionner normalement.
Le noyau (kernel) constitue le cœur du système Linux. Il assure notamment la communication avec le matériel, la gestion de la mémoire, des processus, des pilotes et des systèmes de fichiers. Lorsqu’une erreur irrécupérable survient à ce niveau, poursuivre l’exécution pourrait provoquer une corruption des données ou aggraver le problème. Le noyau peut alors déclencher volontairement un panic et arrêter le système.
Selon la configuration de Linux, le PC peut alors :
Se figer complètement avec un message d’erreur à l’écran.
Afficher une série d’informations techniques et une Call Trace.
Redémarrer automatiquement après quelques secondes.
Rester bloqué jusqu’à un redémarrage manuel.
Un Kernel Panic est donc différent du simple plantage d’une application. Si Firefox, un jeu ou un autre programme se ferme brutalement, le noyau Linux continue généralement de fonctionner. Lors d’un Kernel Panic, c’est au contraire le fonctionnement du système lui-même qui est compromis.
Kernel Panic, Kernel Oops ou blocage : quelles différences ?
Tous les problèmes graves de Linux ne correspondent pas nécessairement à un Kernel Panic.
Un Kernel Oops indique qu’une erreur a été détectée dans le noyau. Linux enregistre des informations techniques sur l’incident et peut parfois continuer à fonctionner, même si le système peut ensuite devenir instable.
Un Kernel Panic est plus grave : le noyau considère qu’il n’est plus possible de poursuivre l’exécution de manière sûre.
Enfin, un freeze ou blocage de Linux peut avoir de nombreuses autres origines : pilote graphique bloqué, manque de mémoire, problème matériel, stockage défaillant ou processus qui monopolise certaines ressources. Un écran figé ne signifie donc pas automatiquement qu’un Kernel Panic s’est produit.
Les messages affichés à l’écran ou enregistrés dans les journaux sont essentiels pour faire la différence. Des termes comme Kernel panic, Oops, BUG, Call Trace ou le nom d’un module noyau constituent alors des indices importants.
Dans la suite de ce guide, nous allons voir quelles sont les principales causes d’un Kernel Panic et comment récupérer ces informations afin d’identifier son origine.
Quelles sont les causes d’un Kernel Panic ?
Un Kernel Panic peut avoir une origine logicielle ou matérielle. Un pilote défectueux, un problème de mémoire RAM, une erreur de stockage ou encore une mise à jour du noyau peuvent provoquer une erreur suffisamment grave pour empêcher Linux de continuer à fonctionner normalement.
Image initramfs endommagée, pilote de stockage manquant
Kernel Panic principalement au démarrage
Matériel ou firmware
BIOS/UEFI, carte mère, alimentation, périphérique PCIe
Erreurs matérielles, comportement instable ou aléatoire
Pilote ou module du noyau défectueux
Les pilotes et modules du noyau sont une cause importante de Kernel Panic puisqu’ils s’exécutent directement dans l’espace noyau.
Un problème peut apparaître après la mise à jour d’un pilote graphique, l’installation d’un module tiers ou le passage à une nouvelle version du noyau Linux. Les pilotes NVIDIA, les modules DKMS ou certains pilotes de périphériques constituent par exemple des éléments à vérifier lorsqu’un Kernel Panic apparaît après une modification du système.
Le nom du module impliqué peut parfois apparaître dans la Call Trace ou dans les messages enregistrés avant le plantage.
Problème matériel ou instabilité du PC
Un Kernel Panic peut également être la conséquence d’une instabilité matérielle. La mémoire RAM est notamment à surveiller : une barrette défectueuse ou des paramètres XMP/EXPO trop agressifs peuvent provoquer des corruptions mémoire qui finissent par faire planter le noyau.
Le processeur peut également devenir instable à cause d’un overclocking, d’un undervolting trop important ou, dans certains cas, de températures excessives.
Si les Kernel Panic sont aléatoires, impliquent des modules différents ou apparaissent principalement sous forte charge, il est pertinent d’élargir le diagnostic au matériel.
Un SSD ou un disque dur défaillant peut provoquer des erreurs d’entrée/sortie (I/O) qui empêchent le noyau d’accéder correctement aux données nécessaires au fonctionnement du système.
Une corruption du système de fichiers peut également entraîner des problèmes graves, notamment lorsque la partition système devient inaccessible.
Des messages contenant I/O error, EXT4-fs error, BTRFS error, nvme ou encore des erreurs SATA constituent alors des pistes à examiner.
Mise à jour ou régression du noyau Linux
Enfin, un Kernel Panic peut apparaître après une mise à jour du noyau. Une nouvelle version peut introduire une régression ou révéler une incompatibilité avec un pilote ou un périphérique particulier.
Un indice particulièrement intéressant est donc la date d’apparition du problème. Si Linux fonctionnait normalement avant une mise à jour du kernel et que les Kernel Panic ont commencé immédiatement après, démarrer temporairement sur l’ancien noyau depuis GRUB constitue un excellent test.
L’identification de la cause repose toutefois rarement sur le seul message « Kernel Panic ». Il faut récupérer les journaux du noyau et les informations affichées au moment du plantage pour déterminer quel pilote, composant ou sous-système est réellement impliqué.
Comment récupérer les informations après un Kernel Panic ?
Pour déterminer l’origine d’un Kernel Panic, il faut récupérer les messages enregistrés par le noyau avant le plantage. Ils peuvent contenir le nom d’un pilote ou d’un module, une erreur mémoire, une erreur d’entrée/sortie ou encore une Call Trace permettant d’orienter le diagnostic.
Lorsque Linux a redémarré, journalctl est généralement le premier outil à utiliser.
Consulter les messages du noyau du démarrage précédent
Sur une distribution utilisant systemd, exécutez :
journalctl -k -b -1
L’option -k limite l’affichage aux messages du noyau, tandis que -b -1 demande les journaux correspondant au démarrage précédent.
Vous pouvez également afficher uniquement les erreurs :
Il est souvent utile d’examiner également les dernières lignes précédant le plantage, car l’erreur ayant déclenché le Kernel Panic peut apparaître avant le message final.
dmesg est surtout utile pour examiner le démarrage et la session en cours. Après un redémarrage consécutif à un Kernel Panic, journalctl -k -b -1 est généralement plus intéressant pour retrouver les événements du système précédent.
Que faire si le journal du démarrage précédent est vide ?
Les journaux ne sont pas toujours conservés après un redémarrage. Vous pouvez vérifier si les anciens boots sont disponibles avec :
journalctl --list-boots
Si seul le démarrage actuel apparaît, la journalisation persistante n’est probablement pas disponible ou les anciens journaux ont déjà été supprimés.
Dans ce cas, il peut être nécessaire de configurer la conservation persistante du journal systemd avant de reproduire le problème.
Il faut également garder à l’esprit qu’un Kernel Panic particulièrement brutal peut empêcher Linux d’écrire les derniers messages sur le disque. Le journal peut alors s’interrompre juste avant l’information la plus intéressante.
Pour les plantages difficiles à reproduire ou lorsque les journaux classiques ne suffisent pas, des mécanismes plus avancés comme kdump permettent de conserver un vidage mémoire du noyau afin d’effectuer une analyse plus approfondie.
Une fois les messages récupérés, l’étape suivante consiste à identifier les lignes réellement importantes dans le Kernel Panic et à interpréter la Call Trace.
Vérifier si un pilote ou module noyau est responsable
Les pilotes et modules du noyau sont une cause fréquente de Kernel Panic, car ils s’exécutent directement dans l’espace noyau. Un module défectueux, incompatible avec une nouvelle version du kernel ou mal compilé peut provoquer une erreur critique du système.
La première étape consiste à rechercher si un nom de module revient dans les journaux ou dans la Call Trace du Kernel Panic.
Vous pouvez par exemple filtrer les messages du démarrage précédent avec :
Si un nom de module apparaît régulièrement juste avant le plantage, notez-le pour poursuivre les vérifications.
Lister les modules noyau chargés
La commande suivante affiche les modules actuellement chargés :
lsmod
Vous pouvez rechercher un module précis avec :
lsmod | grep nom_module
Pour obtenir davantage d’informations :
modinfo nom_module
modinfo peut notamment afficher :
Le chemin du module.
Sa version.
Son auteur.
Les dépendances.
Les paramètres disponibles.
La version du noyau pour laquelle il a été compilé selon le module.
Ces informations sont utiles lorsqu’un pilote tiers ou un module DKMS est suspecté.
Vérifier les modules DKMS
Certains pilotes tiers sont reconstruits automatiquement à chaque mise à jour du noyau grâce à DKMS, notamment certains pilotes graphiques ou pilotes matériels additionnels.
Pour afficher les modules DKMS installés :
dkms status
Si un Kernel Panic apparaît juste après une mise à jour du noyau, vérifiez que les modules nécessaires ont bien été recompilés pour la nouvelle version et qu’aucune erreur DKMS n’est présente.
Vous pouvez aussi comparer la version du noyau actuellement utilisée :
uname -r
avec les informations retournées par modinfo.
Rechercher les erreurs liées à un pilote précis
Si vous connaissez le nom du module suspect, filtrez directement les journaux :
Désactiver temporairement un module pour confirmer le diagnostic
Si un module non essentiel semble responsable, vous pouvez tenter de le désactiver temporairement afin de vérifier si les Kernel Panic disparaissent.
Pour retirer un module chargé :
sudo modprobe -r nom_module
Cette commande ne fonctionne que si le module n’est pas utilisé par un périphérique ou un autre module.
Pour empêcher son chargement au prochain démarrage, il est également possible de le placer temporairement dans une blacklist modprobe. Cette méthode doit toutefois être utilisée avec prudence : bloquer un pilote graphique, réseau ou de stockage indispensable peut empêcher le système de fonctionner correctement.
L’objectif n’est donc pas de désactiver au hasard les modules présents dans la Call Trace, mais de vérifier si le même pilote revient systématiquement dans plusieurs Kernel Panic.
Si le problème est apparu récemment, demandez-vous ce qui a changé juste avant :
Mise à jour du noyau Linux.
Mise à jour du pilote NVIDIA ou AMD.
Installation d’un nouveau module DKMS.
Mise à jour du BIOS/UEFI.
Ajout d’un périphérique PCIe, USB ou de stockage.
Modification d’un paramètre du kernel ou du démarrage.
Lorsqu’un Kernel Panic apparaît juste après une mise à jour du noyau, un test très efficace consiste à redémarrer sur l’ancienne version du kernel depuis GRUB. Si les plantages disparaissent, cela renforce fortement l’hypothèse d’une régression du noyau ou d’une incompatibilité avec un pilote/module.
Enfin, gardez à l’esprit qu’un module cité dans une Call Trace n’est pas automatiquement le responsable. Une corruption mémoire ou une instabilité matérielle peut provoquer le crash d’un pilote parfaitement sain. Il faut donc toujours croiser cette piste avec les autres symptômes et les tests matériels.
Analyser un Kernel Panic avec kdump
Lorsque les journaux journalctl et dmesg ne permettent pas d’identifier l’origine d’un Kernel Panic, les utilisateurs avancés et administrateurs système peuvent utiliser kdump pour effectuer une analyse plus approfondie.
Kdump utilise kexec pour démarrer un second noyau, appelé noyau de capture, après le plantage. Une partie de la mémoire est réservée à l’avance afin que ce noyau puisse récupérer l’état mémoire du système qui vient de planter et l’enregistrer dans un fichier vmcore.
Le principe est le suivant : Kernel Panic → noyau de capture → création du vmcore → analyse du crash
Le fichier vmcore peut ensuite être analysé avec des outils spécialisés comme crash, en utilisant les symboles de débogage correspondant au noyau ayant planté. Cette analyse permet notamment d’examiner les messages du noyau, la pile d’appels, les processus et les modules présents au moment du crash.
La mise en place et surtout l’analyse d’un vmcore restent toutefois des opérations techniques destinées principalement aux administrateurs système et au débogage du noyau. Pour un PC personnel, commencez par journalctl, les messages du noyau, la vérification des pilotes/modules et le diagnostic matériel.
Que faire si Linux ne démarre plus après un Kernel Panic ?
Si Linux ne démarre plus après un Kernel Panic, le problème peut venir du noyau récemment installé, d’un pilote/module incompatible, de l’initramfs, du système de fichiers ou d’un problème matériel.
L’objectif est d’abord de retrouver un système démarrable, puis d’analyser ce qui a changé juste avant l’apparition du problème.
Démarrer sur un ancien noyau depuis GRUB
Si les Kernel Panic ont commencé après une mise à jour du noyau, essayez en priorité de démarrer sur une version précédente.
Depuis le menu GRUB :
Ouvrez Options avancées pour Ubuntu/Debian ou l’entrée équivalente de votre distribution.
Sélectionnez un ancien noyau Linux.
Démarrez normalement.
Si le système démarre correctement avec l’ancien kernel, cela oriente fortement vers une régression du noyau ou un problème de pilote/module compatible uniquement avec certaines versions.
Vous pouvez vérifier la version utilisée avec :
uname -r
Utiliser le mode de récupération
Si un ancien noyau ne suffit pas, essayez le mode Recovery / dépannage proposé dans GRUB.
Selon la distribution, ce mode permet notamment de :
Ouvrir un shell root.
Vérifier le système de fichiers.
Réparer certains paquets.
Recréer l’initramfs.
Désactiver temporairement un pilote ou module problématique.
Il peut être utile lorsque le Kernel Panic survient très tôt pendant le démarrage.
Vérifier ou reconstruire l’initramfs
Un initramfs endommagé ou incomplet peut empêcher le noyau de charger les pilotes nécessaires au démarrage, notamment ceux liés au stockage.
Sur Debian/Ubuntu, vous pouvez reconstruire l’initramfs avec :
sudo update-initramfs -u -k all
Puis mettre à jour GRUB :
sudo update-grub
Sur d’autres distributions, la commande peut différer, par exemple avec dracut.
Démarrer depuis un Live USB
Si aucun noyau installé ne permet de démarrer, utilisez un Live USB Linux.
Depuis le système Live, vous pouvez :
Accéder aux fichiers importants et effectuer une sauvegarde.
Monter la partition Linux.
Vérifier le système de fichiers.
Examiner les journaux présents sur le disque.
Réparer le chargeur d’amorçage.
Réinstaller un noyau ou reconstruire l’initramfs.
C’est également une bonne méthode pour déterminer si le problème vient du système installé ou d’une panne matérielle plus générale.
Vérifier le système de fichiers et le stockage
Si le Kernel Panic est associé à des erreurs de lecture, de montage ou d’entrée/sortie, vérifiez le stockage avant d’insister sur les réparations logicielles.
Vous pouvez rechercher des erreurs dans les journaux avec des termes comme :
Un système de fichiers endommagé peut parfois être réparé avec fsck, à condition de ne pas lancer la vérification sur une partition montée en écriture.
Profitez également du Live USB pour vérifier l’état SMART du SSD ou du disque si une défaillance matérielle est suspectée.
Si les journaux ou la Call Trace pointent régulièrement vers un module noyau précis, il peut être utile de désactiver temporairement ce module afin de vérifier si Linux démarre à nouveau.
Cette opération est surtout pertinente pour les pilotes graphiques, Wi-Fi ou modules tiers. Évitez toutefois de blacklister au hasard un pilote lié au stockage ou à un composant indispensable au démarrage.
En dernier recours : sauvegarder puis réparer ou réinstaller
Si Linux reste impossible à démarrer malgré un ancien noyau, la reconstruction de l’initramfs et la vérification du stockage, sauvegardez d’abord vos données depuis un Live USB.
Vous pourrez ensuite tenter une réparation plus complète du système ou, si la corruption est importante, procéder à une réinstallation.
Avant d’en arriver là, vérifiez cependant que le problème n’est pas matériel. Des Kernel Panic répétés avec des messages différents peuvent être provoqués par une RAM instable, un SSD défaillant, un CPU instable ou un autre composant matériel.
Le guide Kernel Panic pourrait n’en donner qu’une explication de 200 mots + lien vers ce futur guide.
Kernel panic – not syncing: Attempted to kill init!
Le message Kernel panic - not syncing: Attempted to kill init! apparaît lorsque le processus init, généralement le processus PID 1, s’arrête ou rencontre une erreur qui l’empêche de poursuivre son fonctionnement.
Ce processus joue un rôle essentiel : il constitue le premier processus lancé en espace utilisateur et permet ensuite d’initialiser le reste du système. S’il disparaît, Linux ne peut normalement plus poursuivre son fonctionnement et déclenche un Kernel Panic.
Cette erreur peut notamment être liée à :
Un initramfs endommagé ou incomplet.
Un problème avec systemd ou le programme utilisé comme init.
Une corruption du système de fichiers racine.
Des bibliothèques ou fichiers système manquants ou corrompus.
Une mise à jour interrompue ou défectueuse.
Une erreur de mémoire ou une instabilité matérielle provoquant le crash du processus init.
Si le problème apparaît au démarrage, essayez d’abord de lancer un ancien noyau depuis GRUB ou le mode de récupération. Vous pouvez ensuite vérifier le système de fichiers, reconstruire l’initramfs et contrôler les fichiers système.
Il est également important d’examiner les lignes affichées juste avant Attempted to kill init! : ce message indique la conséquence finale du problème, mais pas nécessairement sa cause initiale.
Kernel panic – not syncing: Fatal exception
Le message Kernel panic - not syncing: Fatal exception indique qu’une exception suffisamment grave s’est produite dans le noyau pour empêcher Linux de poursuivre son fonctionnement en toute sécurité.
Contrairement à une erreur très spécifique comme VFS: Unable to mount root fs, le message Fatal exception ne permet généralement pas à lui seul d’identifier la cause.
Il faut donc examiner les informations qui le précèdent, notamment :
La Call Trace.
Le nom d’un pilote ou module noyau.
Les éventuels messages Oops ou BUG.
Le processus et le CPU concernés.
Les erreurs mémoire ou matérielles précédant le panic.
Les modules éventuellement indiqués comme chargés ou impliqués.
Une Fatal exception peut notamment provenir d’un bug du noyau, d’un pilote défectueux, d’un module tiers ou d’une corruption mémoire provoquée par une instabilité matérielle.
Après le redémarrage, consultez en priorité les messages du noyau du démarrage précédent :
journalctl -k -b -1
Si plusieurs Kernel Panic présentent des Call Trace différentes et impliquent des modules sans rapport entre eux, élargissez également les vérifications à la RAM, au processeur et au matériel.
Kernel Panic après une mise à jour du noyau
Si les Kernel Panic commencent immédiatement après une mise à jour du noyau Linux, la nouvelle version du kernel constitue une piste importante.
Le problème ne vient toutefois pas nécessairement du noyau lui-même. Une mise à jour peut également révéler une incompatibilité avec un pilote, un module DKMS, l’initramfs ou un périphérique matériel.
Le test le plus simple consiste à redémarrer le PC et à sélectionner l’ancienne version du noyau depuis les options avancées de GRUB.
Si Linux fonctionne normalement avec l’ancien kernel, vérifiez ensuite :
Les éventuelles erreurs connues avec la nouvelle version du noyau.
Les modules DKMS avec dkms status.
Les pilotes graphiques ou autres pilotes tiers récemment mis à jour.
La bonne génération de l’initramfs.
Les journaux du démarrage ayant échoué.
Les paramètres du noyau éventuellement modifiés.
Vous pouvez connaître le noyau actuellement utilisé avec :
uname -r
et afficher les noyaux disponibles dans /boot :
ls -lh /boot
Si l’ancien noyau fonctionne correctement, conservez-le temporairement comme solution de secours plutôt que de supprimer immédiatement les autres versions. Cela permet de continuer à utiliser Linux pendant que vous recherchez s’il s’agit d’une régression du kernel ou d’une incompatibilité avec un module.
A recent TONTOU attack showed that Spectre v2 defenses on AMD and Intel CPUs could still be bypassed; now researchers have demonstrated major Spectre vulnerabilities on commercial RISC-V processors. The attacks can extract arbitrary Linux kernel memory from a T-Head Xuantie C910 at about 338 bytes per second, overturning the assumption that RISC-V is largely immune.
NVIDIA officialise l’application GeForce NOW sous Linux. Ubuntu 24.04 LTS est pris en charge et des optimisations améliorent la fluidité en 4K et jusqu’à 120 FPS.
OpenAI a annoncé, le 11 août 2026, lancer une version preview de son application ChatGPT pour Linux. Elle réunit au sein d’une même interface ChatGPT, l’agent professionnel Work et l’assistant de programmation Codex.
OpenAI has released a preview of its official ChatGPT desktop app for Linux, ending the platform’s reliance on browser access. Native `.deb` and `.rpm` packages support x64 and ARM64 systems running Ubuntu, Debian, or Fedora.
Vous jouez sous Linux et votre bibliothèque Steam, GOG ou Epic tourne à peu près entièrement grâce à
Proton
? Cela signifie que, malheureusement, vos jeux Xbox PC et ceux du Game Pass, eux, restent à la porte... C'est con d'avoir un catalogue entier, payé tous les mois rubis sur l'ongle et de ne pas pouvoir y toucher ailleurs que sous Windows, via le streaming cloud.
Mais cette époque est révolue puisque Xodus est un projet open source qui rétro-ingénierie la chaîne Xbox PC pour faire tourner ces jeux directement sur Linux. Son dépôt coche déjà la connexion de l'appareil, celle du compte, l'autorisation Xbox, la récupération des licences, le téléchargement des paquets de jeu et le déchiffrement des exécutables à la demande. Bref, la douane est passée (non pas Hamza, celle de Microsoft).
Ce qui bloquait n'a jamais été Proton puisqu'en fait un jeu Xbox PC moderne repose sur le GDK de Microsoft et arrive emballé dans un conteneur MSIXVC chiffré, dont les clés dépendent de la licence attachée au compte.
Rien à voir donc avec un .exe posé dans un dossier.
L'équipe, emmenée par Paweł Lidwin qui contribue aussi à
Heroic
, a donc dû fabriquer ses propres briques, une bibliothèque d'authentification Xbox, un lecteur capable de parcourir ces conteneurs, et surtout une réimplémentation libre de xgameruntime.dll, le composant par lequel les jeux réclament les services Xbox (Celle-là est toujours en chantier). Le projet entretient même ses propres versions modifiées de Wine et de Proton.
Sauf qu'on ne joue toujours pas... Aucun binaire n'est distribué, il faut tout compiler soi-même, et les fameux services Xbox doivent encore être servis aux jeux à travers Wine. Le lancement, c'est donc le gros morceau restant même si un jeu auquel vous avez droit se récupère et se déchiffre.
Côté catalogue, il faut du GDK et du MSIXVC. Le MSIXVC2 n'est pas géré, Gears of War 4 reste sur le carreau, et les titres rétrocompatibles se récupèrent mais réclameront peut-être des correctifs dans wine ou dxvk. Quant au déchiffrement, il s'appuie sur les instructions AES du processeur. Cela signifie que sur une machine trop vieille pour les avoir, ça ne ramera même pas... ça s'arrête juste net sur une instruction "illegal".
Et puis, vous vous en doutez, il y a Microsoft... Le projet n'est ni affilié ni approuvé par Redmond, donc c'est à utiliser à vos risques et périls, car rien n'empêche l'éditeur de changer une clé ou de modifier un bout du protocole et de refermer la porte du jour au lendemain. Avec Xodus, personne n'a rien promis, et c'est un pari sur un avenir incertain... Toutefois le
dépôt
avance bien quand même, sans binaire à la clé pour le moment.
Lucas, lecteur de Korben.info, m'a écrit pour me montrer
Wayland-Wheeltani
, son outil qui ramène l'autoscroll au clic molette sous Wayland, et qu'il met à jour depuis ce printemps. C'est un peu dans l'air du temps de ce genre d'outils puisque fin juillet, je vous parlais déjà de
midscroll
, qui règle le même manque sous Linux. Wayland-Wheeltani vise le même geste, mais avec une idée nouvelle que l'autre n'a pas.
Le geste, donc... Vous le connaissez, on maintient le bouton du milieu, on éloigne la souris du point d'appui, et la page défile dans cette direction. Plus on s'éloigne, plus ça accélère et si on relâche, ça s'arrête net. Et si on repasse de l'autre côté du point de départ, hé bien le défilement s'inverse sur cet axe.
Toutefois, un mouvement minuscule ne déclenche rien, ce qui fait que sous le seuil, le clic molette reste un clic molette, collage de la sélection compris. Et comme le programme déchiffre les mouvements de la souris au niveau du noyau pour réémettre un genre de molette virtuelle, les applications au-dessus n'en savent rien. Pour elles, c'est juste une molette de souris ordinaire.
L'écart sur la méthode de fonctionnement avec Midscroll, c'est que Wayland-Wheeltani ne se lie pas à votre souris par son fichier dans /dev/input, dont le numéro bouge à chaque branchement, mais bien par son identifiant USB constructeur et produit. Le réglage survit ainsi aux redémarrages et aux changements de port, et le service la retrouve seul quand vous la rebranchez. C'est super si par exemple vous utilisez à certains moments un dock externe.
Le filtre par application, lui, existe des deux côtés, mais ne fonctionne pas dans le même sens. Midscroll démarre avec FreeCAD, OrcaSlicer et Minecraft déjà blacklistés alors qu'avec Wayland-Wheeltani, rien n'est filtré au départ, et vous pouvez exclure des applications ou n'en autoriser que quelques-unes grâce à une commande donnant l'identifiant précis de la fenêtre active. Hyprland, Sway et i3 sont ainsi supportés en direct, GNOME avec une extension fournie, KDE avec kdotool. Et l'autoscroll, lui, marche sur toute session Wayland.
Pour le reste, il faut une session Wayland, systemd en mode utilisateur et l'accès à /dev/uinput. L'installation dépose une règle udev visant votre souris, ce qui évite de faire tourner le service en root au quotidien.
Après la limite, vous la connaissez puisqu'elle est dans le nom : Wayland-Wheeltani ne couvre que Wayland, là où midscroll gère aussi X11. Donc si votre session est encore en X11, vous n'aurez pas le choix. Par contre, si elle est en Wayland et que vous passez votre temps à débrancher / rebrancher votre souris et qu'elle change de port sans cesse, c'est celui-ci qu'il vous faut.
Bonne nouvelle les amis, je viens de vous mettre en ligne un
sélecteur de distribution Linux
!! 35 distributions dans la balance, vingt questions max et à l'arrivée, le nom du Linux qu'il vous faut !
Parce que oui, la "meilleure" distribution Linux n'existe pas dans l'absolu. En fait, le bon choix dépend de votre machine, de votre usage et du temps que vous acceptez d'y passer. Posez la question à deux personnes, l'une répondra Linux Mint, l'autre CachyOS, et les deux auront raison !
L'outil vous demande vos usages et ce que vous avez sous la main... L'âge de la machine, la RAM, la carte graphique, un Windows à garder à côté, et ce que vous comptez en faire,
jouer
compris.
Le questionnaire se raccourcit ensuite selon ce que vous avez déjà répondu et au final, vous repartez avec une distribution, sa fiche technique et 2 alternatives si celle-là ne vous branche pas.
J'ai remarqué que ce qui manquait à la plupart des classements de ce type, c'était le "pourquoi pas cette distrib ?". C'est pour cela que mon sélecteur affiche aussi les distributions écartées avec la raison de leur élimination, et celles qui ne démarreront même pas chez vous. Hé oui, un vieux PC en 32 bits n'a plus grand monde à se mettre sous la dent depuis que Debian 13 a supprimé son noyau i386.
Et quand Linux n'est pas la réponse à votre besoin, il vous prévient. Par exemple, si votre travail dépend de la suite Adobe ou d'un jeu avec un système anti-triche, l'outil ne fera pas semblant du contraire.
Et bien sûr, tout cela tourne exclusivement dans votre navigateur, et rien ne part ailleurs dans le cloud. En plus c'est gratuit ! 35 distributions ne font évidemment pas tout l'écosystème Linux, et j'ai dû faire des choix mais ça vous donne déjà un nom précis sur lequel vous lancer en toute sérénité.
Linux desktop traffic reached 22% among likely human visitors on a single Monday, highlighting a sharp workday surge rather than a sudden overnight migration from Windows. Cloudflare’s broader measurements also show Linux gaining ground, partly because AI agents and other automated workloads generate substantial Linux traffic.
Connexion
Le gaming sous Linux va profiter d’un important gain de performances avec l’arrivée du noyau Linux 7.3. C’est du moins la promesse de plusieurs modifications du planificateur CPU. Les travaux portent sur une amélioration de la latence, l’efficacité de la répartition des tâches et le comportement du système sur les architectures modernes. Ces changements concernent …