Problème Grub2 - Bloqué dans la liste des entrées en boucle

Support Debian
, ,
Tags: #<Tag:0x00007f63f4e9f368> #<Tag:0x00007f63f4e9f278> #<Tag:0x00007f63f4e9f160>
#1

Bonjour à tous,

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 !

#2

À 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 ?

#3

Bonjour,

D’après le numéro de version il s’agit de Debian testing :
https://packages.debian.org/trixie/grub-common

#4

Bonjour,

Oui effectivement, c’est Debian testing.

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.

Merci à vous !

#5

Bonjour,

Petit up, si quelqu’un a une solution ou une idée ça m’aiderait bien … :sweat:

Merci !

#6

La première chose a faire serait de regarder avec attention les logs, entre autres la:

https://libvirt.org/kbase/debuglogs.html

#7

Je ne connaissais pas ces debuglogs …
Merci, je regarderai ça demain soir !

#8

Bonsoir,

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

Logs /var/log/libvirt/libvirt.log 
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventGLibHandleDispatch:112 : Dispatch handler data=0x562f221ae460 watch=9 fd=17 events=1 opaque=0x562f221afd40
2023-11-02 21:29:00.001+0000: 2688147: info : virEventGLibHandleDispatch:115 : EVENT_GLIB_DISPATCH_HANDLE: watch=9 events=1 cb=0x7f8a1a3e8de0 opaque=0x562f221afd40
2023-11-02 21:29:00.001+0000: 2688147: info : virEventGLibHandleUpdate:194 : EVENT_GLIB_UPDATE_HANDLE: watch=9 events=1
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventGLibHandleUpdate:205 : Update handle data=0x562f221ae460 watch=9 fd=17 events=1
2023-11-02 21:29:00.001+0000: 2688147: info : virEventGLibHandleUpdate:194 : EVENT_GLIB_UPDATE_HANDLE: watch=9 events=1
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventGLibHandleUpdate:205 : Update handle data=0x562f221ae460 watch=9 fd=17 events=1
2023-11-02 21:29:00.001+0000: 2688147: info : virObjectRef:400 : OBJECT_REF: obj=0x562f22197770
2023-11-02 21:29:00.001+0000: 2688147: info : virObjectRef:400 : OBJECT_REF: obj=0x562f221ae1f0
2023-11-02 21:29:00.001+0000: 2688147: info : virObjectRef:400 : OBJECT_REF: obj=0x562f221a21e0
2023-11-02 21:29:00.001+0000: 2688147: info : virObjectUnref:378 : OBJECT_UNREF: obj=0x562f22197770
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventRunDefaultImpl:359 : running default event implementation
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventRunDefaultImpl:359 : running default event implementation
2023-11-02 21:29:00.001+0000: 2688149: debug : virThreadJobSet:93 : Thread 2688149 (rpc-libvirtd) is now running job remoteDispatchConnectListAllDomains
2023-11-02 21:29:00.001+0000: 2688149: debug : virConnectListAllDomains:6948 : conn=0x7f89fc003d40, domains=0x7f8a157fd930, flags=0xf0
2023-11-02 21:29:00.001+0000: 2688149: info : virObjectRef:400 : OBJECT_REF: obj=0x562f22190d00
2023-11-02 21:29:00.001+0000: 2688149: info : virObjectUnref:378 : OBJECT_UNREF: obj=0x562f22190d00
2023-11-02 21:29:00.001+0000: 2688149: debug : virThreadJobClear:118 : Thread 2688149 (rpc-libvirtd) finished job remoteDispatchConnectListAllDomains with ret=0
2023-11-02 21:29:00.001+0000: 2688149: info : virEventGLibHandleUpdate:194 : EVENT_GLIB_UPDATE_HANDLE: watch=9 events=3
2023-11-02 21:29:00.001+0000: 2688149: debug : virEventGLibHandleUpdate:205 : Update handle data=0x562f221ae460 watch=9 fd=17 events=3
2023-11-02 21:29:00.001+0000: 2688149: debug : virEventGLibHandleUpdate:214 : Removed old handle source=0x562f221b1580
2023-11-02 21:29:00.001+0000: 2688149: debug : virEventGLibHandleUpdate:223 : Added new handle source=0x7f89fc0028a0
2023-11-02 21:29:00.001+0000: 2688149: info : virObjectUnref:378 : OBJECT_UNREF: obj=0x562f221a21e0
2023-11-02 21:29:00.001+0000: 2688149: info : virObjectUnref:378 : OBJECT_UNREF: obj=0x562f221ae1f0
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventRunDefaultImpl:359 : running default event implementation
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventGLibHandleDispatch:112 : Dispatch handler data=0x562f221ae460 watch=9 fd=17 events=2 opaque=0x562f221afd40
2023-11-02 21:29:00.001+0000: 2688147: info : virEventGLibHandleDispatch:115 : EVENT_GLIB_DISPATCH_HANDLE: watch=9 events=2 cb=0x7f8a1a3e8de0 opaque=0x562f221afd40
2023-11-02 21:29:00.001+0000: 2688147: info : virEventGLibHandleUpdate:194 : EVENT_GLIB_UPDATE_HANDLE: watch=9 events=1
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventGLibHandleUpdate:205 : Update handle data=0x562f221ae460 watch=9 fd=17 events=1
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventGLibHandleUpdate:214 : Removed old handle source=0x7f89fc0028a0
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventGLibHandleUpdate:223 : Added new handle source=0x562f221b1580
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventRunDefaultImpl:359 : running default event implementation
2023-11-02 21:29:00.001+0000: 2688147: debug : virEventRunDefaultImpl:359 : running default event implementation

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.

Edit 2 : Idem avec l’entrée Recovery mode

#9

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 ?

#10

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.

Merci !

#11

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.

#12

:wink:

virsh console <vm_name>

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.

#13

Quid d’une commande comme

docker logs

?

#14

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.

#15

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).

#16

Ouai mais en tirant la bobine sur les forums avec l’output de cette commande, peut etre que…

Car là depuis le debut du fil je ne vois pas d’output

#17

De quel Output tu parles ?

Celui de virsh ? c’est dit plus haut rien justement mis à part la commande de démarrage.

#18

Je note tes recommandations, merci pour ça, je ne connaissais pas ces outils :slight_smile:

#19

Ouaip…c’est comme ca qu’on flingue le bouzin :wink:

Toujours tester un changement de noyau sur une machine de test…

question humoristique:

Le reboot se fait le vendredi soir? :smiley:

#20

J’ai retenu la leçon, je vais changer ça ^^

Réponse sérieuse, le dimanche matin, comme ça je suis sûr de pouvoir intervenir si y a un soucis :stuck_out_tongue:
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