Kernel Panic - pas de synchronisation : VFS : Impossible de monter root fs sur unknown-block(0,0)

Commencez avec un livecd, ouvrez un terminal

sudo fdisk -l
sudo mount /dev/sdax /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt 

et maintenant vous pouvez faire update-initramfs et update-Grub sans erreurs.

update-initramfs -u -k 2.6.38-8-generic (or your version)

Si vous ne connaissez pas votre version. Utilisez :

dpkg --list | grep linux-image

Et mettez juste à jour Grub.

update-grub2

Redémarrez votre système.

Si cela s'est produit après une mise à jour du noyau avortée (par exemple, un crash du système alors que aptitude safe-upgrade ),

1. démarrer avec un noyau plus ancien et
2. exécuter dpkg --configure -a .

Cela terminera la mise à niveau, y compris la configuration des paramètres de démarrage en tant que psusi explique .

Dans ma situation, le problème était le suivant /boot était à 100% de sa capacité, donc les 2 dernières mises à jour du noyau n'avaient pas été effectuées avec succès, d'où le redémarrage quand GRUB2 a sélectionné le dernier Kernel, ça a échoué.

J'ai résolu le problème en démarrant dans le plus ancien noyau installé, et en supprimant certains noyaux inutilisés à l'aide d'aptitude. En utilisant aptitude après que la désinstallation ait eu lieu, dpkg a automatiquement essayé de configurer les paquets cassés, et cette fois a réussi.

Procédure de diagnostic complète basée sur les messages du noyau

Mais en utilisant cette Configuration de l'émulation QEMU J'ai essayé de produire des exemples minimaux de chaque type de défaillance possible pour vous aider à déboguer votre problème.

Dans cette configuration simple, QEMU émule un système avec :

• un seul disque virtio qui représente un disque dur ou SDD de matériel réel
• ce disque virtio contient une image ext4 brute non partitionnée. En fonctionnement normal, ce périphérique apparaît sous /dev/vda ( v est la lettre indicatrice pour virtio, s'il était partitionné les partitions seraient /dev/vda1 , /dev/vda2 etc.)

Les erreurs possibles que vous pouvez obtenir sont les suivantes :

1. Linux ne peut pas lire les octets du disque.

   Cela peut être dû au fait que le disque est cassé ou que vous n'avez pas configuré Linux pour qu'il puisse lire sur ce type de matériel.

   Dans mon cas QEMU, je peux reproduire ce problème en supprimant les options clés qui permettent au noyau de lire ce disque virtio :

   CONFIG_VIRTIO_BLK=y
   CONFIG_VIRTIO_PCI=y

   Le message d'erreur qui en résulte ressemble à ceci

   <4>[    0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
   <4>[    0.542035] Please append a correct "root=" boot option; here are the available partitions:
   <0>[    0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

   Donc ici Linux nous dit qu'il ne peut pas lire de vda du tout : VFS: Cannot open root device "vda" or unknown-block(0,0): error -6 .

   Ensuite, à Please append a correct "root=" boot option; here are the available partitions: il donne une liste des partitions qu'il a pu lire.

   Dans notre cas, la liste est cependant vide, car la ligne suivante n'a aucun rapport avec le sujet.

2. Linux peut lire des octets sur le disque, mais il ne comprend pas le système de fichiers pour y lire des fichiers.

   C'est normalement parce que vous n'avez pas configuré le noyau pour lire ce type de système de fichiers.

   Je peux atteindre ce cas en supprimant la capacité du noyau à lire un système de fichiers ext4 :

   CONFIG_EXT4_FS=y

   Avec cette suppression, le message d'erreur est :

   <4>[    0.585296] List of all partitions:
   <4>[    0.585913] fe00          524288 vda
   <4>[    0.586123]  driver: virtio_blk
   <4>[    0.586471] No filesystem could mount root, tried:
   <4>[    0.586497]  squashfs
   <4>[    0.586724]
   <0>[    0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0)

   Donc Linux nous dit qu'il a réussi à trouver une vda en lisant le disque avec l'option virtio_blk appareil.

   Mais alors, il n'était pas capable de lire cette partition. Il a essayé squashfs qui est le seul autre système de fichiers que nous avons activé, mais cela n'a pas fonctionné, car nous avons une partition ext4.

3. Vous avez passé le mauvais root= option de ligne de commande du noyau.

   Celui-ci est facile, il suffit de passer le bon ! Le noyau vous donne même une liste de ceux qu'il connaît !

   Par exemple, si nous passons un faux :

   root=/dev/vda2

   qui n'existe même pas, le noyau donne une erreur de type :

   <4>[    0.608475] Please append a correct "root=" boot option; here are the available partitions:
   <4>[    0.609563] fe00          524288 vda
   <4>[    0.609723]  driver: virtio_blk
   <0>[    0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2)

   qui nous dit que "hey : il n'y a pas de vda2 mais il y a un vda !"

   Cet exemple clarifie également bien ce que le (0,0) , (254,0) y (254,2) signifié des cas précédents :

   • (0,0) : le premier chiffre 0 signifie qu'il n'a pas pu lire le disque du tout.
   • (254,2) 254 est un ID qui a été assigné au disque. 2 est la partition avec cet ID comme dans /dev/vda2 . Et la partition 0 signifie une partition brute non partitionnée comme dans /dev/vda .

Testé sur Linux 5.4.3.