Error symbol grub calloc not found при установке ubuntu

After upgrading Beowulf, my desktop will not boot. It tries to run grub and reports

symbol grub_calloc not found
Entering rescue mode
grub rescue>

I have found a reference to this on an Ubuntu site :-

https://www.mail-archive.com/ubuntu-bug … 13006.html

which refers to :-

https://askubuntu.com/questions/1263125 … -not-found

I am trying to work my way through this, with

ls
ls (hd0,msdos5)
set boot=(hd0,msdos5)
set prefix=(hd0,msdos5)/grub
insmod normal

but the last line reports that grub_calloc is not found.

Geoff

Last edited by Geoff 42 (2020-08-01 10:59:56)

Looks like you need to attempt a reinstallation of the bootloader.

Load up a beowulf live ISO image then

sudo -i
mount /dev/sdXY /mnt
apt update && apt install grub-pc
grub-install --boot-directory=/mnt/boot /dev/sdX
reboot

^ That presumes you have a non-UEFI system and /boot is on the main root partition, replace X & Y with the drive letter and root partition number.

“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII, 18.

Thank you for that, I will have a look at that.

The url for giving some grub rescue commands was :-

https://www.easytechstutorials.com/how- … -rescue-2/

Rather than the ones above!

It does sound as though the problem is quite widespread, so it may be a good idea to not do any upgrades involving grub…

Geoff

I don’t think you will be able to boot from the GRUB command line. Re-installing the bootloader should fix things.

See also https://bugs.launchpad.net/ubuntu/+sour … omments/16 (but my commands are simpler).

“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII, 18.

Thank you. I found a memory stick with Refracta Beowulf no dbus and managed to boot it and followed your commands.

I my case I mounted /dev/sda5 on /mnt.

As the problem seemed to be related to the update, I missed that step out, as well as the install grub-pc.
I did the

grub-install --boot-directory=/mnt /dev/sda
reboot

which worked. I gave the boot-directory as /mnt, because that partition is /boot rather than root.

I can now investigate things like grub versions etc.

Thank you again, helpful as ever

Geoff

Just for the record, looking in /var/log/apt/history.log, the latest upgrade was this morning :-

So, I think that it was upgrading from the stable version to the stable-security version.

Geoff

This upgrade is referred to in :-

https://www.debian.org/security/2020/dsa-4735

which refers to a problem with grub_malloc and was suggested somewhere as being replaced with grub_calloc.

Geoff

It may be that it is related to my disk layout, where /boot is its own partition and maybe grub failed to do the grub-install correctly. When I can get to my desktop machine, I will check the output from apt to see if I missed an error message.

/boot is my only ext partition, the rest being handled by LVM, not encrypted.

Geoff

Last edited by Geoff 42 (2020-07-31 05:01:40)

I have now checked in /var/log/apt/term.log and I can see no error messages. The relevant part seems to be :-

Setting up grub-pc (2.02+dfsg1-20+deb10u1) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Including Xen overrides from /etc/default/grub.d/xen.cfg
Generating grub configuration file ...
Found theme: /usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txt
Found background image: Lake_mapourika_NZ.tga

before it trawls through all of the kernels and other partitions and finally saying

Geoff

Logged on this afternoon and unattended-upgrade has just updated grub-common.

Start-Date: 2020-07-31  12:10:26                                       
Commandline: /usr/bin/unattended-upgrade
Requested-By: marjorie (1000)
Upgrade: grub-common:amd64 (2.02+dfsg1-20+deb10u1, 2.02+dfsg1-20+deb10u2)
End-Date: 2020-07-31  12:10:28 

Maybe this fixes the problem?

https://linuxsecurity.com/advisories/de … e-17-52-37

Package        : grub2
Debian Bug     : 966554

The update for grub2 released as DSA 4735-1 caused a boot-regression
when chainloading another bootlaoder and breaking notably dual-boot with
Windows. Updated grub2 packages are now available to correct this issue.

For the stable distribution (buster), this problem has been fixed in
version 2.02+dfsg1-20+deb10u2.

We recommend that you upgrade your grub2 packages.

For the detailed security status of grub2 please refer to its security
tracker page at:
https://security-tracker.debian.org/tracker/grub2

Oddly ‘grub-common’ is the only grub package I have on this PC, my other (my mail server) has ‘grub-common’, ‘grub2-common’, ‘grub-pc’ and and ‘grub-pc-bin’. Both were fresh Beowulf Beta installs.

Last edited by Marjorie (2020-07-31 12:33:05)

I have fed some info into the Debian bug report.

https://bugs.debian.org/cgi-bin/bugrepo … bug=966575

but the deb10u2 does look like the fix and is available now on my machine, but I will wait until I hear from them in case they want any further info.

Geoff

Last edited by Geoff 42 (2020-07-31 14:18:07)

I have Devuan Beowulf installed on a Dell Vostro netbook with legacy bios and no other operating systems installed and I had/have no issues with either grub upgrades.

rub-common/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]
grub-pc-bin/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]
grub-pc/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]
grub2-common/now 2.02+dfsg1-20+deb10u1 i386 [installed,upgradable to: 2.02+dfsg1-20+deb10u2]

grub-common/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed]
grub-pc-bin/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed,automatic]
grub-pc/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed]
grub2-common/stable-security,now 2.02+dfsg1-20+deb10u2 i386 [installed,automatic]

Based on browsing the Internet, I believe the grub bug only effects UEFI systems with multiple operating systems installed. Please don’t hesitate to provide corrections.

It does depend on your set-up, but is not just UEFI as my machine which broke has dos type disk labels.
I’m not sure whether it needs both multi-disk and/or multi-OS.
I have one SSD and one HDD and have the remnants of Win 7 although I haven’t booted that for a very long time.
I also use Xen for trying out OSs, so have several on the HDD in their own partitions, under LVM.

Geoff

Via the Debian bug report 966575 I got a message from Colin Watson saying :-

So I tried :-

debconf-show grub-pc
  grub2/update_nvram: true
  grub-pc/install_devices_failed_upgrade: true
  grub2/kfreebsd_cmdline:
  grub-pc/chainload_from_menu.lst: true
  grub-pc/kopt_extracted: false
  grub-pc/install_devices_empty: false
  grub-pc/timeout: 5
  grub-pc/mixed_legacy_and_grub2: true
  grub-pc/postrm_purge_boot_grub: false
* grub2/linux_cmdline_default: earlyprintk=vga,keep vsyscall=emulate init=/sbin/openrc-init
  grub-pc/hidden_timeout: false
  grub-pc/partition_description:
* grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD10EZRX-00A8LB0_WD-WCC1U2741701
  grub-pc/install_devices_disks_changed:
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/install_devices_failed: false
* grub2/linux_cmdline:
  grub2/device_map_regenerated:
  grub2/force_efi_extra_removable: false
  grub-pc/disk_description:

which asked 3 questions, 2 about the command line and then about where to install.
It had selected /dev/sdb and I added /dev/sda (with the spacebar) :-

 The grub-pc package is being upgraded. This menu allows you to select which devices you'd like grub-install to be automatically run for, if any.
 Running grub-install automatically is recommended in most situations, to prevent the installed GRUB core image from getting out of sync with GRUB modules or grub.cfg.
 If you're unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them.
 Note: it is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here. However, this forces GRUB to use the blocklist
 mechanism, which makes it less reliable, and therefore is not recommended.
 GRUB install devices:
    [*] /dev/sda (240057 MB; Corsair_Force_GS)
    [ ] - /dev/sda5 (262 MB; /boot)
    [ ] /dev/sda6 (239685 MB; LVM PV O44JvK-Gagl-jJ0w-aWwi-3qn0-Y2no-fbwG8Q on /dev/sda6)
    [*] /dev/sdb (1000204 MB; WDC_WD10EZRX-00A8LB0)
    [ ] /dev/sdb6 (882340 MB; LVM PV p10DED-cZEt-K24W-0Ov2-itdA-HOI8-EquJNg on /dev/sdb6)
    [ ] /dev/dm-0 (21474 MB; SSD0-root)
                                                                                   <Ok>

It then continues

Installing for i386-pc platform.
Installation finished. No error reported.
Installing for i386-pc platform.
Installation finished. No error reported.
Including Xen overrides from /etc/default/grub.d/xen.cfg
Generating grub configuration file ...
Found theme: /usr/share/desktop-base/grub-themes/desktop-grub-theme/theme.txt
Found background image: Lake_mapourika_NZ.tga
Found linux image: /boot/vmlinuz-4.19.0-9-amd64
... several kernels later ...
Found Windows 7 on /dev/sda1
Found Windows 7 on /dev/sdb1
...
Found Debian GNU/Linux jessie/sid on /dev/mapper/HDD0-xenguest1--disk
done

My system can still boot but looks as though it will now install onto both disks.

debconf-show grub-pc now reports :-

Geoff

Colin Watson writes in the bug report :-

It is also mentioned that this is not a UEFI problem, although someone with UEFI was reporting a(nother) problem.

Geoff

Following the dpkg-reconfigure grub-pc I have now upgraded grub to the deb10u2 version and it still boots.

Geoff

I’ve encountered the same problem as OP. However I have /boot on separate partition, and the rest part of the OS is encrypted.
Will this method work or should I change anything? I don’t want to reinstall the whole system, as this is my main work machine.
I can boot in with live-iso. Thanks in advance.

sudo -i
mount /dev/sdXY /mnt
apt update && apt install grub-pc
grub-install --boot-directory=/mnt/boot /dev/sdX
reboot

So I’ve mounted /boot on /mnt and tried reinstall grub, but apt install grub-pc failes on nvme on which /boot partition is located.

root@devuan:~# grub-install --root-directory=/mnt/ /dev/nvme0n1
Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

I’m not very familiar with GRUB nor UEFI/BIOS internals. I found that above issue can be solved by creating small partition and flagging it with ‘bios_grub:
https://blog.hostonnet.com/grub-install … e-possible
https://askubuntu.com/questions/671809/ … -partition

How to do it if all disc space is already taken? I have LUKS FDE on entire drive beside /boot. Should I cut part of /boot partition then? Also I have amd64 system and grub installer is i386 — is it normal?

Last edited by uther (2020-08-07 20:07:59)

Boot with live-iso, shrink the /boot partition and make a new partition. Do not format the new partition with a filesystem. (Unformatted is the last choice in gparted’s dropdown list of formats.) Give it bios_grub flag (or type ef02 if you use gdisk).

You need at least 1MB for the bios_grub partition. I usually give it 2MB so I don’t have to worry about what kind of MB I’m using.

Thank you fsmithred. That fixed the issue.

Last edited by uther (2020-08-07 20:07:34)

My instructions were non-UEFI specific and if you have a GPT disk then you almost certainly had a UEFI system so you should have used

# apt update
# apt install grub-efi-amd64 # or grub-efi-ia32 for 32-bit UEFI implementations
# mount /dev/sdXY /mnt
# mkdir /efi
# mount /dev/sdXZ /efi
# grub-install --target=x86_64-efi --efi-directory=/efi --boot-directory=/mnt/boot
# umount /efi
# rmdir /efi
# reboot

Replace X with the drive letter, replace Y with the root partition number (or the /boot partition if that is separate, in which case omit /boot from the —boot-directory switch) and replace Z with the number for the EFI system partition.

I use sectors 34-2047 for BIOS boot partitions, that space should be free in a correctly-aligned disk.

The i386-pc bit refers to the non-UEFI bootloader rather than the system architecture.

“Et ignotas animum dimittit in artes.” — Ovid, Metamorphoses, VIII, 18.

I have stumbled into this horrible Grub bug myself and tried recovery from the Devuan Live 3.0 Beowulf image.

It worked! but for those in my same situation is worth knowing this slight variation:

I do not have EFI (and do not like to use UEFI) but the latest Grub keeps selecting it by default.

In my case this command worked:

 grub-install --target=i386-pc --boot-directory=/mnt/boot /dev/sdX 

Else I kept receiving an error message from grub-install mentioning the boot directory «is not an EFI partition».

As you mentioned later in this thread, i386-pc does not relate to the CPU architecture, this is also required for AMD64 platforms.

Not reading often here, if urgent contact me via E-Mail: J @ Dyne.org
GPG fingerprint: 6113 D89C A825 C5CE DD02  C872 73B3 5DA5 4ACB 7D10

Это часть работы, которую мы проделали, чтобы исправить это на наших Azure Ubuntu 18.04 серверах

Проблема, похоже, является неудачной попыткой обновления grub. Проблема возникает при автоматической перезагрузке после обновления системы безопасности.

Затем мы нашли эти инструкции в комментарии к ошибке Ubuntu для этой проблемы: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/16

Обратите внимание, что я слегка изменил это, и ниже приведена моя измененная версия, о которой я упоминаю в последующем комментарии к ошибке( https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/45 )

Для пользователей Azure (то же самое должно работать в любом облаке, с небольшими изменениями), которые попадают сюда, пока ищут эту ошибку, шагами для восстановления являются:

Развертывание ВМ восстановления с помощью AzCli или просто прикрепление копии поврежденного диска OS vm к загрузочной ВМ.
После этого подключитесь к загрузочной ВМ и:

$ sudo su -
# lsblk <-- это определит вложенный диск, обычно /dev/sdc, но может быть /dev/sda или /dev/sdb.
# mkdir /rescue
# mount /dev/sdc1 /rescue <-- предполагается, что /dev/sdc - это вложенный диск с данными.
# for fs in {proc,sys,tmp,dev}; do mount -o bind /$fs /rescue/$fs; done
# cd /rescue
# chroot /rescue
# grub-install /dev/sdc <-- предполагается, что /dev/sdc - это вложенный диск с данными.
# выход
# cd /
# for fs in {proc,sys,tmp,dev}; do umount /rescue/$fs; done
# umount /rescue
# rmdir /rescue

Теперь вы можете поменять отремонтированный диск на поврежденную ВМ.

Первая попытка исправления

Мы нашли следующие ссылки на документацию Azure полезными:

• 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

Хорошо, шаг за шагом:

Разверните восстанавливающую ВМ

Что это за ВМ? Попытка создания обычной ВМ Ubuntu 18.04 LTS. Это то, что вы хотите — создать VM восстановления, которая будет соответствовать серверам, которые сломаны

Все нормально, за исключением подключения к существующему диску. Похоже, что вы не сможете прикрепить его к диску, если вы сначала не переместите его с другой машины (отсоедините его).

прикрепите копию поврежденного диска OS vm к спасательной ВМ.

Чтобы создать копию, вы можете сделать снимок диска только для чтения, а затем создать новый управляемый диск на основе этого снимка.

Единственный диск, на котором нужен снимок — это диск OS, а не диск с данными.

Можно создать восстанавливаемую ВМ без диска с данными, только автоматически создаваемый диск с данными. Затем можно добавить снимок ОС управляемого диска на восстанавливаемую ВМ в виде диска с данными.

Затем можно войти в ВМ восстановления и выполнить описанные выше действия.

Все шаги завершены без ошибок — мы можем скопировать и вставить точные сообщения

В критической строке выполняется grub-install Вы должны увидеть следующее:

root@recoveryVM:/# grub-install /dev/sdc
Installing for i386-pc platform.
Installation finished. No error reported.

Затем выйдите из системы и остановите ВМ.

Затем вы можете войти в сломанную ВМ и в разделе «Диски» ВМ выбрать ‘Swap OS Disk’.

Reddit mini thread объясняет необходимые крепления: https://www.reddit. com/r/Ubuntu/comments/i0vlf0/repair_grub_boot_error_symbol_grub_calloc_not/

Повторяя шаги

1. Сделайте снимок ‘сломанного’ диска операционной системы (постфикс _snap)
2. Создайте управляемый диск из снимка — это должна быть та же оценка, что и у старого диска ОС , так как мы собираемся полностью заменить старый диск ОС на этот (постфикс _recovery) — снэпшот исходного типа и использовать только что созданный снэпшот
3. Attach Managed OS Disk to recovery VM (stop/start of recoveryVM not required)
4. Login through SSH, запустить восстановительные мероприятия, Выход из системы снова
5. Отключение диска управляемой операционной системы от восстановительной ВМ (редактирование дисков ВМ и удаление диска управляемой операционной системы)
6. Остановка ‘сломанной’ ВМ (возможно, в этом нет необходимости, т.к. замена диска управляемой операционной системы останавливает ее)
7. В ‘сломанных’ дисках ВМ нажмите ‘Заменить диск управляемой операционной системы’ и выберите восстановительный диск управляемой операционной системы в качестве замены
8. Запуск ‘восстановленной’ ВМ
9. Очистка моментального снимка — но пока оставьте сломанный диск с операционной системой — напоминание на месяц или около того, чтобы удалить его тоже

Наконец выключите ВМ восстановления и удалите это тоже через месяц

Проблемы с некоторыми серверами

Мы столкнулись с проблемой, что исправления на двух серверах не сработали. Все команды завершились успешно — но при запуске ВМ мы получили такую же ошибку grub.

Дальнейшее исследование показало, что /dev/sda, /dev/sdb и /dev/sdc изменились на ВМ восстановления. Я не знаю, почему это произошло.

Это то, что вы должны получить при запуске lsblk в sudo (но не chroot) режиме (обратите внимание sda — это восстановление VM OS, а sdc — это вложенный диск с данными для восстановления):

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda       8:0    0   30G  0 disk
├─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 disk
└─sdb1    8:17   0   16G  0 part /mnt
sdc       8:32   0   30G  0 disk
├─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

То же самое и здесь с настройкой grub linux mint 20 и BIOS (в отличие от EFI).

Кто-нибудь может помочь?

Редактирование: Я нашел основную причину своей проблемы и решение.Основная причина в моем случае заключается в том, что у меня есть RAID5, состоящий из 4 дисков, и, я полагаю, автоматическая установка grub во время обновления пакета обновляла только «disk2». Поскольку моя биография загружается с диска «disk1», у него была более старая личинка, поэтому она не могла загрузиться. Я изменил BIOS для загрузки с каждого из дисков за раз (например, «disk1», «disk2», «disk3», «disk4»), и работал только один «disk2».

Чтобы решить проблему Я только что загрузился с «disk2» и выполнил:

sudo grub-install /dev/sda  
sudo grub-install /dev/sdc  
sudo grub-install /dev/sdd  
# ("disk2" is /dev/sdb and it was already working properly so I didn't install grub in that disk)  
sudo update-grub  
sudo reboot  

А затем переконфигурировал свой BIOS для загрузки с «disk1». Таким образом, каждый раз, когда grub обновляется, у меня будет аналогичная проблема, и об этом будет напоминать grub-install, grub-update остальные диски.

Надеюсь, это поможет другим людям в такой же ситуации.

Использование Linux Mint 19.3 bios grub при установке простой установки с двумя разделами.

После обновления GRUB2 произошел сбой при перезагрузке компьютера и он перешел в режим восстановления.

error: symbol 'grub_calloc' not found    

Чтобы восстановить GRUB, я загрузился в Linux Mint 19.3 Live USB-накопитель и выдал в терминале следующие команды:

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

После перезагрузки рабочий стол появился нормально.

Я использовал Linux Mint, и то же самое случилось со мной. Похоже, это вызвано недавним обновлением безопасности, так как я не смог найти в Google ничего другого, кроме этого объявления об обновлении .

Решено путем загрузки на Mint Live USB и использования Timeshift для восстановления на момент времени до того, как я обновил grub2.

У меня была такая же ошибка и не загружалась система после того, как я установил Lubuntu 20.04 ранее сегодня (на старый ноутбук, установите Bios, а не EFI) и позволил ему выполнить обновление. Появился очень запутанный диалог о желании обновить GRUB на моем первом разделе, а также на моем разделе Lubuntu. Было предложено обновить оба раздела, что я и сделал. А затем при перезагрузке произошел сбой перед загрузкой DE.

В любом случае, я нашел больше обходного пути, чем исправления. Поскольку проблема возникает с GRUB (по какой-то причине), я переустановил Lubuntu, и когда он загрузился в первый раз, я открыл окно терминала и вручную выполнил обновление, исключив обновления для grub:

sudo apt update

sudo apt list --upgradable |grep grub

Что показало:

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]

Затем я поместил эти обновления grub в режим ожидания следующим образом:

sudo apt-mark hold grub*

.. а затем продолжил обновление:

sudo apt full-upgrade

Я перезагрузил компьютер, и он вернулся на рабочий стол без ошибок .

Я не знаю, какие побочные эффекты могут возникнуть, если не обновлять GRUB, но пока что в сеансах рабочего стола он работает нормально ..

Я был в одной лодке с Риком Н. 2 диска, но они не были в RAID. Я использовал этот инструмент https://sourceforge.net/p/boot-repair-cd/home/Home/

Я нашел этот инструмент на странице справки Ubuntu https: //help.ubuntu. com / community / Boot-Repair

Похоже, что были установлены некоторые функции графического интерфейса, которых раньше не было (эта система использовалась только для интерфейса командной строки, сколько я себя помню), но я снова запускаю, что является важная часть.

Спасибо остальным, здесь, за руководство.

Я определенно решил проблему.

1. Перейдите на страницу, щелкните здесь и загрузите BOOT-REPAIR-DISK .

2. Запишите его на DVD-диск или сделайте загрузочный USB-диск объемом не более 4 ГБ и USB 2.0 (я рекомендую DVD-диск 4 ГБ).

3. Включите компьютер со вставленным DVD-диском или загрузочным USB-устройством.

4. Когда на экране отобразится заголовок «Boot-Repair-Disk», вы должны выбрать два варианта. Щелкните первый, верхний 64-битный сеанс .

   

5. Когда на экране отобразится рабочий стол, он отобразит сообщение об обновлении Boot-Repair-Disk, щелкните NO , потому что в этом нет необходимости.

6. Когда на экране отобразятся два параметра, которые вы должны выбрать, как показано на следующем рисунке, щелкните первый Рекомендуемый ремонт (устраняет наиболее частые проблемы).

   

7. После завершения процесса перезагрузите компьютер, и он должен загрузиться ОС Ubuntu.

Вот и все. Удачи!

Дополнительная информация здесь:
https://help.ubuntu.com/community/Boot-Repair

У нас было много производственных систем, у которых была именно эта проблема: (следующие шаги выполняются с DVD-диска Debian, но они должны быть довольно похожими или применимы на ubuntu)

1. Начните со спасательного диска
2. Просто щелкните по вопросам
3. Игнорируйте сеть
4. выберите ваш корневой диск для монтирования
5. выберите также /boot to be mounted
6. бросьте оболочку на выбранный корневой диск
7. grub-install DISKNAMEWITHOUTPARTITION (
   но без идентификатора раздела (1,2,3….)), например grub-install /dev/sda
8. reboot

We did the Update noninteractively. В интерактивном режиме оно сообщает следующее:

grub-install: error: cannot find a GRUB drive for /dev/vda. Проверьте device.map.

даже если диск должен быть xvda, а не vda в нашем случае.
Это разбивает MBR, который находится в специальном месте на жёстком диске, поэтому вы должны поместить диск без номера раздела.

Ubuntu Bug Report

Debian Bug Report

Сюрприз:

После недавнего обновления я та же ошибка:

ошибка: символ grub_calloc не найден.
Вход в режим восстановления …
grub rescue> _

Отличия:

То, что в моем случае отличается от всех других ответов, перечисленных здесь, а также пунктов, упомянутых в сообщении OP под Edit , было , У меня есть UEFI !

Кроме того, у меня есть система с двойной загрузкой с Windows 10 и с Debian 10 (а не с Ubuntu, я знаю, этот форум askubuntu , но он одно из первых совпадений при поиске в сети ‘grub_calloc not found’ error).

Исправления:

• Я прочитал все обсуждения о том, что grub состоит из двух частей и т. д., как на этом форуме, так и в других местах. Я переустановил grub (и grub-common , и grub-efi-amd64-bin и grub-efi-amd64-bin-signed ] и grub2-common ), надеясь на некоторую «перестройку». grub-pc не был установлен в моей системе раньше, поэтому я установил его также на всякий случай. Для меня по-прежнему ничего не изменилось.

• Установка в MBR не подходила для меня. На этом ноутбуке установлена ​​Windows 10 с UEFI

• У меня нет ни RAID, ни настройки LVM. Даже не знаю, что это за штуки. Так что ни один из других ответов мне не помог.

Загрузка из EFI-файла:

Я надеялся, что в ближайшее время появится исправление ошибки, поскольку из-за этой ошибки система не загружается и становится непригодной для использования. Между тем, я все еще мог загружаться как в Windows 10, так и в Debian 10:

1. войдя в «Настройка BIOS», нажав ESCAPE при запуске портативного компьютера,
2. , а затем выбрав вариант «Загрузка из файла EFI» вместо «Загрузка из диспетчера ОС»,
3. и затем из папки Boot , debian , HP и Microsoft , войдя в debian ,
4. , а затем выбрав файл grubx64.efi ,

который вызовет обычное меню grub с перечисленными обычными вариантами ОС. Может эта опция что-то специфическая для моего ноута, сказать не могу. (Думаю, что-то подобное можно было бы получить, используя Live USB / CD).

Исправление, которое сработало:

В любом случае, после недели ожидания исправления ошибки, Я устал от этой рутинной процедуры настройки BIOS для загрузки ноутбука каждое утро. После загрузки Debian 10 этим утром я сделал следующее:

1. Я посмотрел, что находится в папке Boot в EFI, где я нашел только один файл bootx64.efi ].
2. Я сделал резервную копию файла bootx64.efi —> bootx64.efi.bak , помещенного в ту же папку.
3. Затем я скопировал поверх grubx64.efi из папки debian в папку Boot как новый bootx64.efi .
4. Перезагрузил ноутбук, и появилось меню grub, чисто и ясно, без каких-либо скачков.

Думаю, то же самое можно было бы сделать и с живого USB / CD.

Я не знаю, насколько это безопасное или хакерское решение (или даже если это решение для всех с UEFI).

• Загрузка до исправления.

. Я столкнулся с этой ошибкой при обновлении нескольких серверов с Ubuntu 16.04 до 18.04. В моем случае на одной машине был отдельный загрузочный том, который находился на / dev / md0 (массив mdraid), который использовал / dev / sda1 и / dev / sdb1 как тома RAID. Исправление было следующим:

• Загрузитесь с USB-накопителя 18.04 в режим «LiveCD».
• Используйте blkid , чтобы найти UUID тома и диски. Определяется / dev / md127 как массив mdraid, который обычно отображается как / dev / md0 .
• Затем:

   apt install grub2-common grub-pc
  mkdir -p / мнт / корень / загрузка
  смонтировать / dev / md127 / mnt / root / boot
   

• Установите MBR на оба физических диска, чтобы любой из них работал после сбоя.

   grub-install --root-directory = / mnt / root / dev / sdb
  grub-install --root-directory = / mnt / root / dev / sda
   

• Убедитесь, что в / mnt / root / boot / grub есть новые файлы grub:

   ls -alR / mnt / root
   

• Перезагрузка

После этого сервер снова заработал.