Problème suivant depuis un dist upgrade
Symbol error grub_register_command_lockdown
J’ai acces a la console grub et au contenu du (hd0,msdos1)
J’ai essayé
Grub> set root=(hd0,msdos1)
Grub> Linux /boot/vmlinuz-linux root=/dev/sda1
Error: symbol ‘ grub_register_command_lockdown' not found.
Grub> _
Que donnent :
grub> ls
grub> ls (hd0,msdos1)/
Shell normal ou shell rescue ?
Les erreurs de symboles proviennent souvent d’une incohérence entre la version de la core image de GRUB active et la version d’un module qu’elle essaie de charger. Origine probable : les modules contenus dans /boot/grub ont été mis à jour mais pas la core image, soit parce que celle-ci n’a pas été écrite, soit parce qu’elle a été écrite ailleurs.
Peux-tu en dire un peu plus sur l’organisation des disques et de l’amorçage ?
Salut merci pour ta réponse. J’ai une disque sda divisé en deux partions une pour home l’autre pour le système. C’est sda1 qui démarre en premier. Si ça répond à ta question.Le Shell grub est celui normal pas le rescue.
Ça donne je crois tout les répertoires etc home var vmlinuz
Quelle est la version affichée ?
Gnu grub version 2.04-18
Linux 5.8.0-3-amd64
C’est la version de GRUB de sid/unstable, donc la core image est à jour. Et apparemment certains modules sont chargés (notamment « normal » sinon GRUB serait en mode rescue).
J’ai regardé la liste des modules qui référencent le symbole grub_register_command_lockdown, il y a mmap.mod qui est une dépendance du module linux.mod. Je suppose que c’est lui qui provoque l’erreur. Mais je n’ai pas d’explication sur sa cause.
Les dernières lignes disent linux.mod not Found
J’ai aussi un configfile.mod not found
Juste comme ça, si c’est un linux, pourquoi les partition sont-elles affichées nommées « msdos » ?
Bonjour
Ce n’est pas une référence au système de fichiers contenu dans la partition
mais une référence à la table des partitions dans laquelle la partition a été créée.
Donc, ici, il s’agit d’une partition qui a été créée
dans une table des partition de type msdos
Si le partitionnement avait été du type gpt
la référence à la première partition du premier disque aurait été : (hd0,gpt1)
Normal, tu as affecté une valeur incorrecte à la variable $prefix. Le bon chemin est /boot/grub, pas /grub (qui serait correct seulement avec une partition /boot séparée).
Après vérification de mon côté, il s’avère que la version affichée est celle du module normal.mod, pas de la core image. Donc je reviens à ma première hypothèse : les modules dans /boot/grub ont été mis à jour mais pas la core image, en tout cas pas celle qui est chargée.
Cause possible : le paquet grub-pc est configuré pour installer GRUB dans sda1 (secteur d’amorce de la partition 1) au lieu de sda (MBR du disque), ce qui serait correct si le MBR contenait un programme d’amorce « standard » qui chaîne le secteur d’amorce de la partition 1 mais pas si le MBR contient directement la boot image de GRUB.
Il faut réinstaller GRUB en démarrant avec l’installateur Debian en mode rescue ou un système live.
J’ai pas de live usb a porté. C’est le gros du problème. Ceci dit j’ai eu ma leçon des que je récupère ma debian je m’en fait une a vie 
Pas d’image d’installation non plus ?
Non:/
Une manip à tenter à l’invite de grub pour charger la nouvelle core image depuis l’ancienne :
insmod multiboot
multiboot (hd0,msdos1)/boot/grub/i386-pc/core.img
boot
Si la première commande échoue, inutile d’exécuter les suivantes.
Ça donne ça :
Grub> insmod multiboot
Error: symbol `grub_register_command_lockdown' not found.
Grub>
Je suppose que
insmod chain
renvoie la même erreur ?
En effet oui, malheureusement.
Par chance j’ai retrouvé un vieux disque que je vais pouvoir booter dessus et me faire une clé Debian. Quelqu’un pourrait m’indiquer les manips a faire pour réinstaller le grub. Quelles sont les manips a faire un fois sur le live?