Ce matin suite au redémarrage de mon serveur, les VMs Debian, gérées par libvirt, ne démarrent plus.
Après légère enquête, il s’avère que Grub tourne en boucle sur la liste des entrées. Lorsque la sélection automatique tente d’exécuter l’entrée par défaut Debian GNU/Linux, la console revient immédiatement sur la liste des entrées avec le décompte de 5s.
Il s’agit de Grub 2.06-13+deb13u1.
Le serveur a la même version et boot sans problème.
Une seule VM était démarrée après le démarrage du serveur, et lorsque j’ai voulu la redémarrer, elle aussi a eu le même problème.
J’ai remarqué que je ne peux pas sélectionner l’entrée Advanced options via la console virsh.
De plus, juste après la sélection, un bref « Booting Debian GNU/Linux » s’affiche.
J’ai essayé de réinstaller grub sur l’une des VMs, qui n’est pas sensible en terme de perte de données, à l’aide d’un master vierge que je garde de côté et qui est sur Debian 11. Aucun problème pour lancer le master.
Je ne sais pas trop quoi faire et un petit coup de pouce ne serait pas de refus.
Merci d’avance à ceux qui prendront le temps de m’aider !
À première vue, on dirait que GRUB recharge son fichier de configuration ou qu’il redémarre, ou que la machine redémarre. Est-ce que les messages « Loading Linux … » et « Loading initial ramdisk … » sont afichés après le compte à rebours ?
Pourquoi, que se passe-t-il ? Le clavier ne répond pas ?
Quelle est la version des autres VM et de l’hôte ?
Je ne sais pas pour la sélection d’une entrée du Grub, je constate seulement que je ne peux pas agir depuis la console virsh. Ni les flèches, ni enter, ni ‹ e › pour éditer ne fonctionnent.
Le seul message qui s’affiche après la sélection automatique de l’entrée est « Booting Debian GNU/Linux ».
Le master n’est pas en testing, je le conserve sur une version 11 de Debian. Mais toutes les autres VMs sont sur debian testing et donc avec la version de Grub indiquée dans le premier post, ainsi que l’hyperviseur qui boot correctement.
Je n’ai rien dans le fichier de log à part la commande de lancement exécutée pour la VM logée.
J’ai cherché à obtenir des logs plus précis en élevant le niveau de debug au niveau de libvirtd.conf mais je n’ai rien de plus, à part des lignes que je ne comprends pas dans /var/log/libvirt/libvirt.log mais qui n’ont pas l’air d’être en lien avec la VM que j’utilise pour essayer d’obtenir des logs …
Je vous mets quand même un extrait de ce que j’ai, le nom de la VM étant Grafana, et qui n’apparaît pas ici
Edit : je suis parvenu à forcer Grub à booter sur le kernel 6.5.0.1 au lieu du 6.5.0.3 sans succès, on en revient toujours au « Booting Debian Debian GNU/ Linux 6.5.0.1 » affiché très rapidement puis retour au menu Grub avec la liste des entrées.
As-tu essayer de démarrer une machine depuis la CLI avec virsh, qu’est-ce que t’as comme message et log ?
Un installation fraîche en testing démarre ?
Depuis une machine créer avec ton master en bookworm suite à upgrade tu as le même souci ?
Dernière question tes VM en testing ont -elles eu des mise à jour récemment ?
C’est toujours par la CLI que je fais les lancements, je n’ai pas d’écran sur mon hyperviseur. Pas de d’erreur, ni dans les logs, simplement le message de confirmation de lancement de la VM. J’ai l’impression que libvirt considère que la VM est correctement initialisé et ne « voit » pas le problème de boot.
Je teste l’installation fraîche et l’upgrade depuis bookworm ce soir.
Oui, elles ont eu des mises à jours, j’ai cherché à voir s’il y avait eu du Grub, je n’ai trouvé que du grub-cloud. Je reconstituerai la liste des MAJ de la semaine avant le reboot ce soir aussi.
L’hyperviseur reboot toutes les semaines, et il n’y a pas eu de soucis le dimanche 22 octobre.
N’étant pas familier avec KVM/QEMU mais touchant un peu à proxmox il me semblerait possible que KVM/QEMU permette d’accéder aux vm un peu comme docker et proxmox permettent d’accéder aux containers. Pourriez vous essayez de voir la doc? Dans tous les cas vous devriez avoir acces aux logs spécifiques de chaque machine individuellement de cette façon.
En plus j’ai une question: pourquoi ces redémarrages de l’hyper? car il me semblerait qu’il serait plus judicieux de ne pas le faire et de gérer les maj de secu par cron.
Mais si elle redémarre en boucle s’est peine perdu, autant monté le disque à la main et explorer d’éventuels logs de boot mais si cela ne passe pas grub idem il doit rien y avoir.
Non, je vous confirme qu’il n’y a aucun logs de boot.
J’ai essayé via deux techniques, d’abord en montant le disque avec guestmount, puis avec virt-log. C’est de cette dernière à laquelle vous faites référence @loicmtp.
C’est justement depuis virsh console que je constate le comportement du blocage sur Grub.
Les redémarrages ont pour objectif de nettoyer la mémoire et faire la bascule sur un nouveau kernel si besoin. Les maj sont effectivement gérés par une tâche cron qui tourne tous les matins.
si ton container configuré en restart always crash dès le départ tu n’aura aucun log dedans, juste ceux de docker te précisant que le container crash et redémarre, sans plus de raison …
Le plus pertinent serait de monitorer si il y a besoin de redémarrage ou d’un simple redémarrage de service via needrestart, ça peu se monitorer via des outils de monitoring avec une sonde ou un script (c’est plus safe à mon goût).
Réponse sérieuse, le dimanche matin, comme ça je suis sûr de pouvoir intervenir si y a un soucis
Et puis si problème, comme maintenant, ça n’impact que moi, donc c’est pas très grave, je ne l’aurai pas fait comme ça sinon
Edit : après, comme dit plus tôt, l’ancien kernel ne fonctionne pas non plus
