Zorin OS ne démarre plus après une mise à jour du noyau : méthode complète de dépannage

Temps de lecture : 5 minutes

Une mise à jour du noyau Linux peut parfois mal se terminer. Le système redémarre alors sur un écran noir, un kernel panic, ou un message similaire à :

VFS: Unable to mount root fs on unknown-block(0,0)

C’est ce qui m’est arrivé sur un ordinateur sous Zorin OS. La mise à jour avait été interrompue et plusieurs paquets liés au noyau, à NVIDIA et à VirtualBox étaient restés partiellement configurés.

Voici la méthode qui m’a permis de remettre le système en état sans réinstaller Zorin OS.

Les symptômes rencontrés

Après une mise à jour, le noyau le plus récent ne démarrait plus. Le menu GRUB proposait plusieurs versions :

Linux 7.0.0-28-generic
Linux 6.17.0-40-generic
Linux 6.17.0-35-generic

Le noyau 7.0.0-28 provoquait un kernel panic. Le noyau 6.17.0-40 démarrait, mais sans Wi-Fi ni Ethernet. Seul le noyau 6.17.0-35 fonctionnait correctement avec le réseau.

L’objectif était donc de démarrer sur le dernier noyau fonctionnel, réparer les paquets interrompus, reconstruire l’image de démarrage du nouveau noyau et remettre GRUB à jour.

1. Démarrer sur un ancien noyau fonctionnel

Au démarrage de l’ordinateur, ouvrir le menu GRUB, puis choisir :

Options avancées pour Zorin

Sélectionner ensuite un noyau plus ancien, par exemple :

Zorin, avec Linux 6.17.0-35-generic

Il est important de ne pas supprimer cet ancien noyau tant que le nouveau n’a pas été testé avec succès.

Une fois connecté, vérifier le noyau utilisé :

uname -r

2. Vérifier si le gestionnaire de paquets est bloqué

La première commande utile est :

sudo dpkg --audit

Elle indique si des paquets sont décompressés mais non configurés, ou laissés dans un état incomplet.

On peut ensuite demander à dpkg de reprendre les configurations interrompues :

sudo dpkg --configure -a

Dans mon cas, cette commande révélait deux problèmes principaux :

un module VirtualBox qui ne se compilait plus avec le nouveau noyau ;
des modules NVIDIA impossibles à construire parce que les en-têtes du noyau correspondant avaient disparu.

Les messages importants ressemblaient à ceci :

cannot open linker script file
/usr/src/linux-headers-6.17.0-40-generic/scripts/module.lds

et :

nvidia.ko: Aucun fichier ou dossier de ce nom

3. Vérifier les noyaux, modules et en-têtes présents

Pour connaître les noyaux installés :

ls /lib/modules

Pour vérifier la version actuellement chargée :

uname -r

Pour voir les en-têtes disponibles :

ls -l /usr/src

On peut également filtrer les paquets liés à une version particulière :

dpkg -l | grep 6.17.0-40

Dans mon cas, le noyau 6.17.0-40 et ses modules existaient encore, mais les en-têtes linux-headers-6.17.0-40-generic n’étaient plus présents. Cela empêchait la construction correcte des modules NVIDIA.

4. Vérifier que le matériel réseau est toujours détecté

L’absence de Wi-Fi ou d’Ethernet ne signifie pas forcément que les cartes réseau sont mortes.

La commande suivante permet de vérifier si le matériel PCI est toujours détecté :

lspci -nn

Dans mon cas, Linux détectait bien :

la carte Wi-Fi Intel ;
la carte Ethernet Realtek ;
la carte graphique NVIDIA.

Le problème était donc logiciel.

Pour vérifier les interfaces réseau créées par le noyau :

ip a

Si seule l’interface suivante apparaît :

lo

cela signifie que les pilotes réseau n’ont pas été chargés correctement.

5. Tester un noyau encore plus ancien

Le noyau 6.17.0-40 démarrait mais ses modules étaient incohérents. J’ai donc redémarré sur 6.17.0-35.

Cette fois :

le Wi-Fi fonctionnait ;
l’Ethernet était présent ;
APT pouvait accéder aux dépôts.

Cette étape a été décisive, car elle a permis de réparer le système directement en ligne plutôt que de chercher manuellement des fichiers .deb.

6. Supprimer temporairement les modules tiers qui bloquent

Les modules DKMS sont reconstruits automatiquement lors de l’installation d’un nouveau noyau. Des logiciels tels que VirtualBox ou certains pilotes NVIDIA peuvent empêcher la configuration du noyau de se terminer.

Dans mon cas, VirtualBox était l’un des premiers éléments bloquants.

Je l’ai retiré temporairement :

sudo apt purge virtualbox virtualbox-dkms virtualbox-qt

Il est possible qu’APT indique que certains de ces paquets ne sont pas installés. Ce n’est pas problématique.

Il vaut mieux éviter de lancer immédiatement :

sudo apt autoremove

pendant une réparation. Cette commande peut supprimer d’anciens noyaux, des en-têtes ou des outils encore utiles. Il est préférable d’attendre que le système soit entièrement réparé.

7. Retirer les paquets NVIDIA restés dans un état incohérent

Dans mon cas, les paquets suivants restaient bloqués :

linux-modules-nvidia-535-6.17.0-40-generic
linux-modules-nvidia-535-generic-hwe-24.04

Ils dépendaient d’un ancien noyau dont les en-têtes n’étaient plus disponibles.

Il ne faut désactiver le pilote au profit de xorg et retirer ces paquets que si les messages d’erreur les désignent clairement comme responsables.

Lorsque le paquet principal n’est plus réellement installé et qu’il ne reste que ses fichiers de configuration, la commande suivante permet de supprimer le reliquat :

sudo dpkg --purge linux-modules-nvidia-535-6.17.0-40-generic

Les noms doivent évidemment être adaptés à la version affichée sur la machine.

Après cela :

sudo apt --fix-broken install
sudo dpkg --configure -a

Dans mon cas, ces commandes se sont enfin terminées sans erreur.

8. Réinstaller le noyau HWE proprement

Plutôt que de télécharger à la main chaque paquet du noyau, il est souvent plus sûr de réinstaller le paquet générique HWE correspondant à Ubuntu 24.04 et Zorin OS :

sudo apt update
sudo apt install --reinstall linux-generic-hwe-24.04

Ce paquet générique installe les éléments cohérents proposés par les dépôts actifs :

l’image du noyau ;
les modules ;
les en-têtes ;
les dépendances correspondantes.

Il est préférable d’utiliser ce méta-paquet plutôt que de deviner le nom d’un paquet comme :

linux-modules-extra-7.0.0-28-generic

Ce paquet n’existe pas nécessairement pour toutes les variantes de noyau.

9. Reconstruire l’initramfs

L’initramfs est une image chargée très tôt pendant le démarrage. Elle contient notamment les pilotes nécessaires pour accéder au disque système.

Lorsqu’elle est absente ou corrompue, Linux peut afficher :

VFS: Unable to mount root fs on unknown-block(0,0)

Pour mettre à jour toutes les images existantes :

sudo update-initramfs -u -k all

Si l’image du noyau défectueux doit être entièrement recréée, commencer par identifier la version exacte :

ls /boot/vmlinuz-*

Puis recréer son initramfs, par exemple :

sudo rm -f /boot/initrd.img-7.0.0-28-generic
sudo update-initramfs -c -k 7.0.0-28-generic

La version doit correspondre exactement au fichier présent dans /boot.

10. Mettre GRUB à jour

Une fois le noyau et l’initramfs réparés :

sudo update-grub

La commande doit détecter les noyaux et leurs images de démarrage :

Found linux image: /boot/vmlinuz-7.0.0-28-generic
Found initrd image: /boot/initrd.img-7.0.0-28-generic
Found linux image: /boot/vmlinuz-6.17.0-35-generic
Found initrd image: /boot/initrd.img-6.17.0-35-generic

Dans une configuration en double démarrage, GRUB peut également détecter Windows :

Found Windows Boot Manager

11. Effectuer les dernières vérifications

Avant de redémarrer, vérifier que le gestionnaire de paquets ne signale plus rien :

sudo dpkg --configure -a
dpkg --audit

Si les deux commandes restent silencieuses, c’est bon signe.

Vérifier ensuite les images de démarrage :

ls -lh /boot/vmlinuz-* /boot/initrd.img-*

Dans mon cas, j’obtenais notamment :

/boot/initrd.img-6.17.0-35-generic
/boot/initrd.img-7.0.0-28-generic
/boot/vmlinuz-6.17.0-35-generic
/boot/vmlinuz-7.0.0-28-generic

L’image initrd du noyau réparé faisait environ 77 Mo, ce qui confirmait qu’elle avait bien été recréée.

12. Tester le nouveau noyau

Après redémarrage, choisir manuellement :

Options avancées pour Zorin
Zorin, avec Linux 7.0.0-28-generic

Une fois connecté :

uname -r

Puis vérifier le réseau :

ip a

Il faut conserver l’ancien noyau fonctionnel pendant quelque temps, au cas où un problème apparaîtrait encore.

Ce qu’il faut retenir

Une panne après une mise à jour du noyau ne nécessite pas forcément de réinstaller tout le système.

La méthode la plus sûre consiste à :

démarrer sur un ancien noyau fonctionnel ;
rétablir le réseau ;
identifier les paquets partiellement configurés ;
retirer temporairement les modules tiers qui bloquent ;
réparer APT et dpkg ;
réinstaller le méta-paquet du noyau HWE ;
reconstruire l’initramfs ;
mettre GRUB à jour ;
conserver l’ancien noyau jusqu’à validation complète.

Dans mon cas, le système semblait gravement endommagé : kernel panic, réseau disparu, modules NVIDIA et VirtualBox en erreur. Pourtant, les fichiers personnels et l’installation de Zorin OS étaient toujours intacts. Une réparation méthodique a suffi.

Cas vécu par Louis, article créé par ChatGPT