How to fix a grub boot error : "symbol 'grub_calloc' not found

Просто запустил последнюю партию обновлений 20.04 (Xubuntu), и теперь я получаю ошибку GRUB:

symbol 'grub_calloc' not found

Я попал в оболочку 'grub rescue', но понятия не имею, что там делать, что может быть полезно. Для меня «символ не найден» подразумевает какую-то ошибку сборки с пакетом grub, но я действительно не знаю, как работает grub. Я заметил, что это обновление также включает в себя «прошивку», не уверен, что это может быть связано. Моя лучшая ставка - просто загрузиться с live CD и посмотреть, смогу ли я как-нибудь откатить обновление до grub?

Отредактировано, чтобы добавить:

Хорошо, спасибо многим людям! Вот что, я думаю, теперь я понимаю.

  1. В системах «не-UEFI» grub устанавливается в двух отдельных частях. Первый, самая основная часть - это часть, которая запускается при загрузке. Но для большей части его функциональности нужна вторая часть. Эти части должны быть выровнены - ни одна из них не должна требовать какой-либо функциональности от другой части, которой на самом деле нет.

    Видимая проблема времени выполнения возникает, когда эти части не выровнены, а функция grub_calloc не предоставлена. Мне не на 100% ясно, принадлежит ли grub_calloc ко второй, большей части или первому. Я бы ожидал второго, но система сборки grub - произведение большого искусства, поэтому я не знаю:).

  2. Основная причина проблемы заключается в том, что обновление grub не гарантировало, что детали были обновлены. В идеале, неспособность сделать это должна привести к сбою установки grub, и система должна быть возвращена в безопасное состояние. Такого не бывает. 1279 Для меня это все еще немного загадка. Все, что нужно сделать обновлению по умолчанию, это поместить каждую часть в текущую, потому что, очевидно, это сработало. Если места установки / диски определяются конфигурацией, и одно из этих мест не может быть достигнуто, то каким-то образом возникло несоответствие между этими данными конфигурации и реальностью. Это может не показаться проблемой, если между частями не было введено никакой новой зависимости.

Все варианты решения включают переустановку grub, чтобы обеспечить выравнивание двух частей. На самом деле нет необходимости возвращаться к предыдущей версии (хотя это будет работать), потому что нарушена не сама среда выполнения grub. Существует множество способов добиться этого, в зависимости от вашей среды, но запуск живого диска Boot-repair мне помог.

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

Это обновление устраняет некоторые важные ошибки ( Смотрите Ubuntu Security Notice 4432 ). Если вы вернули grub для решения этой проблемы, имейте в виду, что вы подвержены этим проблемам.

26
задан 2 August 2020 в 10:27

8 ответов

Это часть работы, которую мы проделали, чтобы исправить это на наших серверах 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 (то же самое должно работать в любом облаке, с небольшими изменениями), которые попадают сюда при поиске этой ошибки, шаги по восстановлению являются: После этого подключитесь к спасательной виртуальной машине и:

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

Теперь у вас должна быть возможность заменить восстановленный диск на поврежденную виртуальную машину.

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

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

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

Развертывание виртуальной машины восстановления

Что это за виртуальная машина? Попытка создать обычную виртуальную машину Ubuntu 18.04 LTS. Это то, что вы хотите - создать виртуальную машину восстановления, соответствующую сломанным серверам.

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

прикрепите копию затронутого виртуального диска ОС к спасательной виртуальной машине.

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

Единственный диск, который вам нужен, - это диск ОС , а не диск данных.

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

Затем вы можете добавить снимок управляемой дисковой ОС на виртуальную машину восстановления в качестве диска данных.

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

  • Очистите моментальный снимок - но пока оставьте сломанный диск ОС - напоминание на месяц или около того, чтобы удалить и его
  • Наконец, выключите виртуальную машину восстановления и удалите ее через месяц

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

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

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

    Это то, что вы должны получить при запуске lsblk в режиме sudo (но без chroot) (примечание sda ] - это ОС восстановления виртуальной машины, а 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
    
    0
    ответ дан 2 August 2020 в 22:01

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

    0
    ответ дан 2 August 2020 в 22:01

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

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

    Редактирование: Я нашел основную причину своей проблемы и решение. Основная причина в моем случае заключается в том, что у меня есть 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 остальные диски.

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

    1
    ответ дан 2 August 2020 в 22:01

    Использование 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    
    

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

    2
    ответ дан 2 August 2020 в 22:01

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

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

    1
    ответ дан 2 August 2020 в 22:01

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

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

    3
    ответ дан 2 August 2020 в 22:01

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

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

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

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

    5
    ответ дан 2 August 2020 в 22:01

    I definitely solved the problem.

    enter image description here

    1. Go to the page, click here and download BOOT-REPAIR-DISK.

    2. Burn it to the DVD disk or make a USB Bootable no more than 4GB and USB 2.0 (I recommend the DVD disk 4 GB).

    3. Power on the PC with the DVD disk or USB bootable inserted.

    4. Once the screen displays the title "Boot-Repair-Disk", there are two options that you have to choose. Click the first, the upper 64bit session.

      enter image description here

    5. Once the screen displays the desktop, it will display about the updating Boot-Repair-Disk, click NO because it's not necessary.

    6. Once the screen displays two options that you have to choose as the following picture displays, click the first Recommended repair (repairs most frequent problems)

      enter image description here

    7. Once finished the process, reboot the PC and it must boot up the Ubuntu OS.

    That's all. Good Luck!

    More information, here: https://help.ubuntu.com/community/Boot-Repair

    0
    ответ дан 2 August 2020 в 22:01

    Другие вопросы по тегам:

    Похожие вопросы: