Kernel

Ramener votre poste Ubuntu 24.04 au standard de classe : noyau 6.14 épinglé, VirtualBox qui démarre, bureau qui s'ouvre

Le standard de classe en trois lignes

Un poste conforme roule sur la série de noyaux 6.14, avec VirtualBox 7.0.16 qui compile dessus, et les métapaquets HWE retenus pour qu'une mise à jour ne pousse jamais un noyau 6.17 ou 7.0 en pleine session. Trois commandes disent où vous en êtes :

uname -r
dkms status
apt-mark showhold
CommandeRésultat attendu
uname -rcommence par 6.14
dkms statusune ligne virtualbox/7.0.16, 6.14.0-XX-generic, x86_64: installed
apt-mark showholdlinux-generic-hwe-24.04, linux-image-generic-hwe-24.04 et linux-headers-generic-hwe-24.04
Pourquoi : la pile HWE d'Ubuntu 24.04 pousse des noyaux plus récents (le 6.17 à l'hiver 2026, le 7.0 depuis l'automne 2026). VirtualBox 7.0.16 ne compile pas dessus, et certains postes plantent carrément. Le 6.14 est la série qui marche partout.

Le diagnostic en une ligne

Le script vérifie onze points (noyau actif, noyaux installés, état de dpkg, retenues, paquets parasites, VirtualBox, Secure Boot, KVM, résidus) et rend un verdict. Il est en lecture seule : il ne modifie rien.

curl -fsSL https://kernel.projet.autos/verifier.sh | bash

Si curl manque : wget -qO- https://kernel.projet.autos/verifier.sh | bash. Le verdict se lit à la dernière ligne : CA PASSE ou CA NE PASSE PAS avec la liste des points en échec. La page Diagnostic explique chaque point et quoi faire.

Trouver sa page par symptôme

Mon écran reste noir à la connexionKubuntu, Plasma. Le bureau ne vient pas, ou des dialogues d'erreur apparaissent sur fond noir. VirtualBox refuse de démarrer une machinevboxdrv absent, VERR_VM_DRIVER_NOT_INSTALLED, VERR_VMX_IN_VMX_ROOT_MODE. apt ou dpkg refuse tout« erreur de traitement du paquet », « Sub-process dpkg returned an error code », verrou, dépôt tiers cassé. Mon noyau n'est pas le 6.14vérifier, redémarrer sur le bon noyau par GRUB, retenir. Poste sur 6.11 avec un 7.0 à moitié installéstabiliser d'abord, migrer ensuite. Poste stable, prêt à migrer vers le 6.14installer le 6.14 par son numéro, point de contrôle DKMS, redémarrer. Poste neuf qui roule sur 7.0installer le 6.14, purger les 7.0, retenir, puis VirtualBox en dernier. Écran bleu MOK ou modules non signésSecure Boot, clé MOK, signature des modules VirtualBox et NVIDIA.

Réparer avec le script guidé

Quand le diagnostic dit CA NE PASSE PAS, le script de réparation refait le chemin étape par étape et demande une confirmation (« o ») avant chaque action. Il se télécharge puis se lance, jamais à l'aveugle par curl, parce qu'il pose des questions :

curl -fsSL -o reparer.sh https://kernel.projet.autos/reparer.sh
bash reparer.sh
Le script ne suffit pas quand le poste roule déjà sur un noyau cassé ou qu'un paquet bloque dpkg : c'est le domaine des plans A, B et C, qui donnent les commandes exactes à copier dans l'ordre.

Les règles d'or

  1. Le noyau d'abord, VirtualBox en dernier. DKMS compile le module VirtualBox contre le noyau actif au moment de l'installation.
  2. La retenue se pose après le purge. apt-mark hold bloque aussi la suppression : on purge les noyaux indésirables, puis on retient.
  3. On garde toujours un noyau de secours. Deux noyaux qui marchent, c'est la ceinture et les bretelles : GRUB (Échap ou Maj au démarrage, Options avancées) ramène sur l'autre.
  4. Lire l'écran avant de dire oui. Dans une liste de suppressions, un paquet du noyau actif qui apparaît veut dire non.
  5. Ne supprimez pas de noyau vous-même si vous n'êtes pas sûr : un poste qui démarre sur le 6.14 avec le noyau récent retenu est dans l'état attendu. Le grand ménage se fait avec le prof.

Les pages du site