Panique du noyau Snappy Ubuntu Core 15.04 (impossible d'ouvrir le périphérique racine) après `update-grub`
J'ai créé un disque virtuel VMDK à partir de l'image Snappy Ubuntu Core 15.04 obtenue ici: http://cdimage.ubuntu.com/ubuntu- snappy/vivid/stable/latest / , l’utiliser pour démarrer un VM nouvellement créé dans VMware Workstation Pro 14.
Je voulais utiliser cette ancienne version pour émuler un ancien appareil que nous avons. Ça va bien.
Cependant, si je fais un Sudo update-grub (voir image 1 ), la prochaine fois qu'il démarrera, le noyau s'affolera du noyau à cause de VFS: Ouverture impossible périphérique racine, "LABEL = system-a" ou unknown-block (0,0): erreur -6 (voir l'image 2 ).
Image 1: 
Photo 2: 
Une recherche rapide montre que /boot/grub/grub.cfg a été modifié au cours de update-grub même si je ne modifie pas du tout /etc/default/grub. L'image montre l'original (la partie contenant l'entrée de menu, où $label est "system-a"); image 4 montre le nouveau.
Photo 3: 
Image 4: 
Mise à jour 1 (6/28)
Tentative de update-initramfs, pas de chance. La panique du noyau persiste après update-grub.
En outre, il se plaint "aucun fichier ou répertoire de ce type" pour /boot/config-3.19.0-47-generic, ne sachant pas si cela est pertinent (il reste encore beaucoup de résultats si j'active le mode commenté pour cette commande).
Mise à jour 2 (6/28)
Je règle GRUB_HIDDEN_TIMEOUT=10 et commente GRUB_HIDDEN_TIMEOUT_QUIET=true dans /etc/default/grub. Maintenant je suis capable de voir le timeout caché et Esc pour afficher le menu de grub.
Ni de "système-a" ou "système-b" ne fonctionnera. "Ubuntu" a fonctionné à la première fois; mais lors du prochain redémarrage, le délai d'expiration masqué n'existait plus et le noyau a de nouveau été pris de panique par "LABEL = system-a".
Il semble que dans le nouveau grub.cfg, "Ubuntu" utilise "root = UUID = ...", tandis que "system-a" utilise "root = LAEBL = system-a".
Notez qu'avant d'utiliser update-grub, il n'y avait qu'une option "system-a" dans le menu grub.
Après avoir regardé dans le passé et post grub.cfg, la conclusion est que, lorsque vous exécutez update-grub, il existe une fonction écrite dans /etc/grub.d/09-snappy appelée get_kernels(...) qui répertorie tous les noyaux installés dans /boot et choisissez le plus récent pour créer l'entrée du menu de démarrage.
Le grub.cfg d'origine utilise /vmlinuz et /initrd.img qui désignent respectivement /boot/vmlinuz-3.19.0-47-generic et /boot/initrd.img-3.19.0-47-generic. Cependant, après avoir exécuté update-grub, il sélectionne /boot/vmlinuz-3.19.0-47-generic.efi.signed, qui n'a pas de initrd.img correspondant. Ensuite, le script 09-snappyignore simplement ce fichier n’a pas été trouvé et n’a pas ajouté la commande initrd dans le grub.cfg généré, puis l’entrée de menu ne démarre pas.
Après la suppression manuelle de /boot/vmlinuz-3.19.0-47-generic.efi.signed, update-grub ne provoque plus de problème de démarrage.
TL; DR
L'image de noyau signée /boot/vmlinuz-3.19.0-47-generic.efi.signed n'a pas de initrd.img correspondant. Supprime-le.
Nouvelle édition: le grub.cfg généré par update-grub est remplacé par celui d'origine après un démarrage réussi. Je ne sais pas pourquoi cela se produit, mais il semble que ce soit un problème distinct, de sorte que nous n'en discuterons pas ici.