Это часть работы, которую мы проделали, чтобы исправить это на наших 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

Как Хуан Фра - у меня 2 диска, но нет RAID. Я подозреваю, что GRUB был на обоих. Я использую Ubuntu, поэтому загрузился с компакт-диска, установил «восстановление загрузки» (инструкции доступны в Интернете) и обновил все разделы grub. Все хорошо.

То же самое и здесь с настройкой 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
   

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

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