Comment réparer une erreur de démarrage de Grub : "symbole 'grub_calloc' introuvable"

Utilisation de Linux Mint 19.3 bios grub setup dans une installation simple à 2 partitions.

Après la mise à jour de GRUB2, la machine a planté lors du redémarrage et est entrée en mode de secours.

erreur : symbole 'grub_calloc' non trouvé    

Pour restaurer GRUB, j'ai démarré sur la clé USB Live de Linux Mint 19.3 et j'ai entré les commandes suivantes dans le terminal :

sudo mount /dev/sda1  /mnt    
sudo grub-install --root-directory=/mnt/  /dev/sda    

Après le redémarrage, le bureau s'est affiché correctement.

J'étais dans la même situation que Rick N. avec 2 disques mais ils n'étaient pas en RAID. J'ai utilisé cet outil https://sourceforge.net/p/boot-repair-cd/home/Home/

J'ai trouvé cet outil sur la page d'aide d'Ubuntu https://help.ubuntu.com/community/Boot-Repair

Il semble avoir installé quelques fonctionnalités GUI qui n'étaient pas là auparavant (ce système était en mode CLI uniquement aussi longtemps que je m'en souvienne) mais je suis de nouveau opérationnel, et c'est ce qui compte.

Merci aux autres, ici, pour leur aide.

Ceci est une partie du travail que nous avons accompli en corrigeant cela sur nos serveurs Azure Ubuntu 18.04

Le problème semble être une tentative échouée de mettre à jour grub. Le problème survient après un redémarrage non assisté suite à une mise à jour de sécurité.

Nous avons ensuite trouvé ces instructions dans un commentaire publié sur le bug Ubuntu pour ce problème : https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/16

Notez que j'ai légèrement modifié ceci et ci-dessous se trouve ma version modifiée que je mentionne dans un commentaire ultérieur sur le bug( https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/45 )

Pour les utilisateurs Azure (la même méthode devrait fonctionner dans n'importe quel cloud, avec de petites modifications) qui se retrouvent ici en cherchant ce bug, les étapes de récupération sont les suivantes :

Déployez une VM de récupération en utilisant AzCli ou attachez simplement une copie du disque VM affecté à une VM de secours. Une fois que c'est fait, connectez-vous à la VM de secours et :

$ sudo su -
# lsblk <-- cela identifiera le disque attaché, habituellement /dev/sdc, mais peut être /dev/sda ou /dev/sdb
# mkdir /rescue
# mount /dev/sdc1 /rescue <-- cela suppose que /dev/sdc est le disque de données attaché
# for fs in {proc,sys,tmp,dev}; do mount -o bind /$fs /rescue/$fs; done
# cd /rescue
# chroot /rescue
# grub-install /dev/sdc <-- cela suppose que /dev/sdc est le disque de données attaché
# exit
# cd /
# for fs in {proc,sys,tmp,dev}; do umount /rescue/$fs; done
# umount /rescue
# rmdir /rescue

Maintenant vous devriez pouvoir réinsérer le disque réparé dans la VM affectée.

Première tentative de correction

Nous avons trouvé les liens de documentation Azure suivants utiles :

• https://docs.microsoft.com/nl-nl/archive/blogs/mast/recover-azure-vm-by-attaching-os-disk-to-another-azure-vm
• https://docs.microsoft.com/en-us/azure/virtual-machines/scripts/virtual-machines-linux-cli-sample-create-vm-from-snapshot?toc=/cli/module/toc.json
• https://social.msdn.microsoft.com/Forums/azure/en-US/6bed5c4f-f5c3-4926-9ac5-05ce7b1efeac/create-copy-of-a-managed-disk?forum=windowsazuredata
• https://docs.microsoft.com/en-us/azure/virtual-machines/linux/snapshot-copy-managed-disk

D'accord, étape par étape :

Déployez une VM de récupération

Quel type de VM est-ce ? Nous avons essayé de créer une VM Ubuntu 18.04 LTS régulière. C'est ce que vous voulez - créer une VM de récupération qui corresponde aux serveurs qui sont cassés

Tout est normal sauf pour la connexion à un disque existant. On dirait que vous ne pouvez pas attacher un disque à moins que vous ne le déplaciez d'une autre machine (le détacher) d'abord.

attacher une copie du disque VM OS affecté à une VM de secours.

Pour créer une copie, vous pouvez prendre un instantané en lecture seule du disque puis créer un nouveau disque géré basé sur l'instantané.

Le seul disque dont vous avez besoin d'un instantané est le disque OS, pas le disque de données.

Vous pouvez créer la VM de récupération sans disque de données, simplement avec le disque OS qui se crée automatiquement.

Ensuite, vous pouvez ajouter l'instantané du disque OS géré à la VM de récupération en tant que disque de données.

Ensuite, vous pouvez vous connecter à la VM de récupération et suivre les étapes ci-dessus.

Toutes les étapes se sont déroulées sans erreur - nous pourrions copier-coller les messages exacts

La ligne critique est l'exécution de grub-install vous devriez voir ce qui suit :

root@recoveryVM:/# grub-install /dev/sdc
Installation pour la plate-forme i386-pc.
Installation terminée. Aucune erreur rapportée.

Ensuite, déconnectez-vous et arrêtez la VM.

Vous pouvez ensuite aller dans la VM cassée et sous la section Disques de la VM, sélectionnez 'Échanger le disque OS'.

Mini discussion Reddit expliquant les montages requis : https://www.reddit.com/r/Ubuntu/comments/i0vlf0/repair_grub_boot_error_symbol_grub_calloc_not/

Répétition des étapes

1. Faites un instantané du disque OS 'cassé' (suffixe _snap)
2. Créez un disque géré à partir de l'instantané - cela doit être de la même qualité que l'ancien disque OS car nous allons le remplacer complètement par celui-ci (suffixe _recovery) - type de source instantané et utilisez l'instantané fraîchement créé
3. Attachez le disque OS géré à la VM de récupération (pas besoin d'arrêter/démarrer la VM de récupération)
4. Connectez-vous via SSH, exécutez les étapes de récupération, déconnectez-vous à nouveau
5. Détachez le disque OS géré de la VM de récupération (éditez les disques de la VM et détachez le disque OS de récupération)
6. Arrêtez la VM 'cassée' (peut-être pas nécessaire car l'échange de disque OS l'arrête)
7. Dans les Disques de la VM 'cassée' cliquez sur 'Échanger le disque OS' et sélectionnez le disque OS de récupération comme remplacement
8. Démarrer la VM 'récupérée'
9. Nettoyez l'instantané - mais laissez le disque OS cassé pour le moment - rappel pour le supprimer aussi d'ici un mois environ

Enfin, éteignez la VM de récupération et supprimez-la aussi d'ici un mois

Problèmes avec certains serveurs

Nous avons rencontré un problème avec lequel les corrections des deux serveurs n'ont pas fonctionné. Toutes les commandes se sont exécutées avec succès - mais nous obtenons la même erreur de grub lors du démarrage de la VM.

Une investigation plus approfondie a montré que les /dev/sda, /dev/sdb et /dev/sdc avaient changé sur la VM de récupération. Je ne sais pas pourquoi cela s'est produit.

C'est ce que vous devriez obtenir en exécutant lsblk en mode sudo (mais non chroot) (notez que sda est le disque OS de la VM de récupération, et sdc est le disque de données attaché à récupérer) :

NOM    MAJ:MIN RM  TAILLE RO TYPE POINT DE MONTAGE
sda       8:0    0   30G  0 disque
sda1    8:1    0 29,9G  0 part /
sda14   8:14   0    4M  0 part
sda15   8:15   0  106M  0 part /boot/efi
sdb       8:16   0   16G  0 disque
sdb1    8:17   0   16G  0 part /mnt
sdc       8:32   0   30G  0 disque
sdc1    8:33   0 29,9G  0 part
sdc14   8:46   0    4M  0 part
sdc15   8:47   0  106M  0 part
sr0      11:0    1  628K  0 rom

J'ai eu la même erreur et un système non démarrable après avoir installé Lubuntu 20.04 plus tôt aujourd'hui (sur un vieil ordinateur portable, installation Bios, pas d'EFI) et l'avoir laissé faire la mise à jour. Il est apparu une boîte de dialogue très confuse demandant de mettre à jour GRUB sur ma première partition ainsi que sur ma partition Lubuntu. Il semblait suggérer de mettre à jour les deux partitions, ce que j'ai fait. Et ensuite, au redémarrage, il a planté avant de charger l'interface.

Quoi qu'il en soit, j'ai trouvé plus une solution de contournement qu'une solution à ce problème. Comme GRUB semble être le problème (pour une raison quelconque), j'ai réinstallé Lubuntu et lors du premier démarrage, j'ai ouvert une fenêtre de terminal et j'ai manuellement effectué la mise à jour, en excluant les mises à jour de grub:

sudo apt update

sudo apt list --upgradable |grep grub

Qui a montré :

grub-common/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]
grub-pc-bin/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]
grub-pc/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]
grub2-common/focal-updates 2.04-1ubuntu26.1 amd64 [upgradable from: 2.04-1ubuntu26]

J'ai ensuite mis ces mises à jour de grub "en attente" avec ceci :

sudo apt-mark hold grub*

..puis j'ai poursuivi avec la mise à jour :

sudo apt full-upgrade

J'ai redémarré la machine, et elle est revenue sur le bureau sans erreur.

Je ne sais pas quels effets indésirables pourraient se produire en ne mettant pas à jour GRUB, mais jusqu'à présent, tout se passe normalement dans les sessions de bureau.

Idem avec linux mint 20 cinnamon et la configuration du bios (par opposition à EFI) de grub.

Est-ce que quelqu'un pourrait fournir de l'aide ?

Modification: J'ai trouvé la cause principale de mon problème et la solution. La cause principale dans mon cas est que j'ai un RAID5 construit à partir de 4 disques et, je suppose, l'installation automatique de grub lors de la mise à jour du package n'a mis à jour que "disque2". Comme mon bios démarre à partir de "disque1", il avait un grub plus ancien et donc il ne pouvait pas démarrer. J'ai changé le bios pour démarrer à partir de chacun des disques à tour de rôle (c'est-à-dire : "disque1", "disque2", "disque3", "disque4" ) et le seul qui fonctionnait était "disque2".

Pour résoudre le problème, j'ai simplement démarré à partir de "disque2" et exécuté :

sudo grub-install /dev/sda  
sudo grub-install /dev/sdc  
sudo grub-install /dev/sdd  
# ("disque2" est /dev/sdb et il fonctionnait déjà correctement donc je n'ai pas installé grub sur ce disque)  
sudo update-grub  
sudo reboot  

Ensuite, j'ai reconfiguré mon BIOS pour démarrer à nouveau à partir de "disque1". De cette façon, chaque fois que grub est mis à jour, je rencontrerai un problème similaire et cela me rappellera d'installer grub, de mettre à jour grub sur le reste des disques.

J'espère que cela aidera d'autres personnes dans la même situation.