This is some of the work we did fixing this on our Azure Ubuntu 18.04 servers
Problem appears to be a failed attempt to upgrade grub. Problem happens with an unattended reboot after a security upgrade.
We then found these instructions from a comment posted on the Ubuntu bug for this problem: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/16
Note that I modified this slightly and below is my modified version that I mention in a later comment on the bug( https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1889509/comments/45 )
For Azure users (the same should work in any cloud, with small changes) that end up here while looking for this bug, the steps to recover are:
Deploy a recovery VM using AzCli or just attach a copy of the affected OS vm disk to a rescue VM.
Once done, connected to rescue VM and:$ sudo su - # lsblk <-- this will identify the attached disk, usualy /dev/sdc, but can be /dev/sda or /dev/sdb # mkdir /rescue # mount /dev/sdc1 /rescue <-- this assumes /dev/sdc is the attached data disk # for fs in {proc,sys,tmp,dev}; do mount -o bind /$fs /rescue/$fs; done # cd /rescue # chroot /rescue # grub-install /dev/sdc <-- this assumes /dev/sdc is the attached data disk # exit # cd / # for fs in {proc,sys,tmp,dev}; do umount /rescue/$fs; done # umount /rescue # rmdir /rescueNow you should be able to swap back the repaired disk to affected VM.
First attempt at a fix
We found the following Azure documentation links useful:
- 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
Ok, step by step:
Deploy a recovery VM
What sort of VM is that? Attempted creating a regular Ubuntu 18.04 LTS VM. This is what you want — to create a recovery VM that matches the servers that are broken
All normal except for connecting to an existing disk. Looks like you can’t attach to a disk unless you first somehow move it from another machine (detach it) first.
attach a copy of the affected OS vm disk to a rescue VM.
To create a copy, you can take a read only snapshot of the disk and then create a new Managed Disk based on the snapshot.
The only disk you need a snapshot of is the OS disk, not the data disk.
You can create the recovery VM without a data disk, just the OS disk that automatically gets created.
You can then add the Managed Disk OS snapshot to the recovery VM as a data disk.
Then you can log into the recovery VM and follow the steps above.
All the steps completed without error — we could copy and paste the exact messages
The critical line is running grub-install you should see the following:
root@recoveryVM:/# grub-install /dev/sdc
Installing for i386-pc platform.
Installation finished. No error reported.
Then log out and stop the VM.
You can then go into the broken VM and under the Disks section of the VM select ‘Swap OS Disk’.
Reddit mini thread explaining the mounts required: https://www.reddit.com/r/Ubuntu/comments/i0vlf0/repair_grub_boot_error_symbol_grub_calloc_not/
Repeating the steps
- Make a snapshot of ‘broken’ OS disk (postfix
_snap) - Create a Managed Disk from the snapshot — this must be the same grade as the old OS disk as we are going to fully replace the old OS disk with this one (postfix
_recovery) — source type snapshot and use the just created snapshot - Attach Managed OS Disk to recovery VM (stop/start of recoveryVM not required)
- Login via SSH, run recovery steps, logout again
- Detach Managed OS Disk from recovery VM (edit the VM disks and detach the recovery OS Disk)
- Stop the ‘broken’ VM (possibly not necessary as the OS Disk swap stops it)
- In the ‘broken’ VM Disks click ‘Swap OS Disk’ and select the recovery OS Disk as the replacement
- Start the ‘recovered’ VM
- Clean up the snapshot — but leave the broken OS disk for now — reminder for a month or so to remove it too
Finally turn off the recovery VM and delete that in a month too
Problems with some servers
We hit a problem that the two server’s fixes didn’t work. All commands completed successfully — but we get the same grub error when starting the VM.
Further investigation showed up that the /dev/sda, /dev/sdb and /dev/sdc had changed on the recovery VM. I don’t know why this happened.
This is what you should get when running lsblk in sudo (but non-chroot) mode (note sda is recovery VM OS, and sdc is attached data disk to be recovered):
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
Здравствуйте.
После обновления Astra Linux Special Edition 1.6 с обновления 6 до оперативного обновления 9 на сервере, после перезагрузки системы слетел GRUB: symbol ‘grub_calloc’ not found. И строка grub rescue. Загрузка в режиме EFI.
У сервера был настроен дисковый массив на dmraid, в fstab был прописан корневой раздел по идентификатору массива (UUID). При загрузке дистрибутива с DVD в режиме восстановления массив не видится потому как в ALSE, как я понял, нет нормальных драйверов для RAID.
Посоветуйте что можно сделать в данном случае, чтобы починить загрузку?
Спасибо.
Последнее редактирование: 21.10.2021
Спасибо за ответ. Проблема в том, что из-за dmraid в системе нет дисков sda. Если б можно было как-то увидеть массив на dmraid — поправить GRUB можно было бы без особых усилий.
При чём здесь sda? Это просто пример подвернулся. Вы вообще пробовали? Мне тоже интересно.
Там был пример с новым железом и Астра как то спасовала. После восстановления загрузчика смогла загрузиться. Мне эта утилита помогала не только линуксовые загрузчики восстанавливать, но и виндовые (Win 10) после падения линукс-систем и ихнего Граба.
to Jbanchic
Правильно понимаю, что у вас на руках только DVD-диск с ALSE (базовый, без обновлений) и проблемный сервер, на который кто-то ранее установил пакеты поддержки dmraid? Если так, то пробуйте аналогично вот этому…
to YNA
Никакая утилита не поможет, если ОС, под которой загрузились, не видит накопителей с установленной ОС. Поэтому да, дело как раз в поддержке блочных устройств (те же /dev/sda в обычном случае SATA-дисков или /dev/dm в случае dmraid)…
Правильно понимаю, что у вас на руках только DVD-диск с ALSE (базовый, без обновлений) и проблемный сервер, на который кто-то ранее установил пакеты поддержки dmraid? Если так, то пробуйте аналогично вот этому…
Сервер был установлен с базового диска по вами указанной инструкции с подсовыванием модулей dmraid для того, чтобы система увидела массив и прекрасно работала и грузилась. На нее успешно было накатано оперативное обновление 6. После накатывания последнего оперативного обновления 9, который кстати установился без проблем, после перезагрузки сломался GRUB. На текущий момент времени при старте появляется grub rescue и вышеуказанная ошибка. Для того, чтобы починить GRUB, как я понимаю, нужно подцепить дисковый массив, который голым дистрибом ALSE в режиме восстановления не видится на моменте подключения корневого каталога. Поэтому и задаю вопрос здесь.
P.S.: Особенность dmraid в том, что в fstab сам массив прописан был по UUID. И, как я понимаю, там есть свои особенности. Для того, чтобы подцепить массив по UUID и примонтировать его куда-либо для починки GRUB что нужно сделать?
Последнее редактирование: 21.10.2021
to Jbanchic
Никогда не пользовался ALSE в режиме восстановления…
В Grub rescue команда ls тоже ничего не показывает?
Остается вариант грузануться с LiveCD с поддержкой dmraid, выполнить chroot в /boot-раздел или корневой (если /boot там) и оттуда восстановить grub через update-grub. Сам подобным не занимался на ALSE с учетом обязаловки паролей на grub и невозможности корректно использовать root (придется chroot выполнять под уч.запись sudo-пользователя, устанавливавшего систему). Поэтому что-то более детальное посоветовать не могу…
to Jbanchic
Кстати, да, можно и дистриб ALSE использовать. Выполнить как по инструкции dmraid=true, чтобы ALSE его увидела. Далее CTRL+ALT+F2, chroot, установить пакеты поддержки dmraid и обновить GRUB. И, не возвращаясь в графику, ребутнуть сервер. По-идее должно помочь…
Никогда не пользовался ALSE в режиме восстановления…
В Grub rescue команда ls тоже ничего не показывает?
Показывает. Два диска с тремя разделами на каждом. Ну оно и понятно — в RAID зеркало.
hd0 (hd0.gpt3) (hd0.gpt2) (hd0.gpt1) hd1 (hd1.gpt3) (hd1.gpt2) (hd1.gpt1)
Остается вариант грузануться с LiveCD с поддержкой dmraid, выполнить chroot в /boot-раздел или корневой (если /boot там) и оттуда восстановить grub через update-grub
Да, я примерно так и представлял. Спасибо.
to Jbanchic
Значит, поддержка dmraid не слетела. Тогда без LiveCD (чисто из grub rescue) можете сделать то же самое — ищите hd с /boot, чрутьтесь в него и далее по тексту…
to Jbanchic
Значит, поддержка dmraid не слетела. Тогда без LiveCD (чисто из grub rescue) можете сделать то же самое — ищите hd с /boot, чрутьтесь в него и далее по тексту…
Если можно поподробнее….из grub rescue. Какие команды доступны и какие нужно запустить из rescue? Насколько я знаю, в этом режиме доступны всего 4 команды: ls, set, unset, insmod.
По разделам: gpt3 -скорее всего раздел EFI, gpt2 — /, gpt1 — swap.
Последнее редактирование: 21.10.2021
to Jbanchic
Не знаю, актуально ли еще, но вот тут испчерпывающе расписаны возможные варианты…
Вообще, у вас, конечно, комбо: dmraid + efi. Imho, в подавляющем большинстве случаев любого сервера и GPT (и, следовательно, EFI) не требуется, и аппаратный (и тем более фейковый) RAID проще заменить программным на базе mdadm. Если речь не идет о каких-нибудь сверхнагруженных системах и обязательном требовании BBU и доп.кэширования…
Добрый вечер, когда уберут косяк с grub из обновлений? Уже две тачки легли.
Добрый вечер, когда уберут косяк с grub из обновлений? Уже две тачки легли.
Похоже надо трясти техподдержку Астры. Похоже это реально проблема для тех, у кого есть RAID-массивы.
Проблема с dmraid решена.
Долгое время не было возможности исправить ситуацию из-за того, что загруженная система не распознавала разделы массива, видела только сам массив без разделов. Не помог ни оригинальный дистрибутив ALSE, ни более новый ALCE.
В итоге загрузчик починен. Помог Linux Mint 20.2 Cinnamon загрузочный диск с офсайта. Все три раздела (EFI, root, swap) система увидела без добавления инструкции dmraid=true.
Решение:
1. Создается каталог, к примеру /mnt/1
2. Монтируется корневой каталог (в моем случае /dev/mapper/isw_xxxxx_xxxp2) в /mnt/1
3. mount -o bind /proc /mnt/1/proc
mount -o bind /sys /mnt/1/sys
mount -o bind /dev /mnt/1/dev
4. chroot /mnt/1
5. Если у вас UEFI загрузка, то дополнительно монтируется раздел с EFI (в моем случае /dev/mapper/isw_xxxxx_xxxp1) в раздел, в который он должен монтироваться в /etc/fstab (после chroot он легко смотрится cat /etc/fstab) (в моем случае в /boot/efi)
6. grub-install
7. update-grub
Загрузчик починен, система грузится.
P.S.:Единственное добавлю, что в некоторых случаях, если используется UEFI, в BIOS может появиться другой починенный раздел загрузки и сохранится старый, который не грузит grub. Лишний можно (да и нужно) удалить в BIOS.
1. Ошибка error symbol: `grub_calloc` not found на дисках с UEFI.
2. Загрузиться в AstraLinux Orel 2.13.1 livecd или Linux Mint 20.2 livecd.
3. Список дисков:
# lsblk
4. Монтируем корневой раздел:
# sudo mount /dev/sda2 /mnt/
5. efi:
# sudo mount /dev/sda1 /mnt/boot/efi/
7. # sudo mount -o bind /sys/ /mnt/sys/
# sudo mount -o bind /proc/ /mnt/proc/
# sudo mount -o bind /dev/ /mnt/dev/
8. # sudo chroot /mnt/
9. # grub-install
10. # update-grub
11. Перезагрузка.
Исправить GRUB UNKNOWN ERROR:
1. Список доступных разделов:
# ls
2. Просмотреть содержимое каждого раздела:
# ls (hd0,3)/
Если вы увидели папку boot, значит это наш раздел.
3. # set root=(hd0,3)
# set prex=(hd0,3)/boot/grub
4. # insmod normal
# normal
Если загрузились с текущего диска:
1. Устанавливаем GRUB на диск /dev/sda:
# sudo grub-install
2. # sudo update-grub
3. Перезагрузка.
-
116.3 КБ
Просмотры: 6 611 -
18.6 КБ
Просмотры: 6 396
Actually, there is no need to reinstall grub. The root cause of the problem is that the second stage of grub is not properly updated by the installation (upgrade process).
My system is KDE Neon (Ubuntu 18.04 LTS underneath), the grub package upgrade process was copying a file called grubx64.efi into /boot/efi/neon and grub was looking for /boot/efi/BOOT/bootx64.efi.
As soon as I copied /boot/efi/neon/grubx64.efi over /boot/efi/BOOT/bootx64.efi my system booted again, using the latest grub from the Ubuntu upgrades (2.02-2ubuntu8.17). For this, I had to boot with a live distro (I used latest Mint). It is faster, easier and more secure than reinstalling a previous version of grub.
Why is this happening? I do not know yet. If I have some more time for deeper investigations, I’ll update this answer.
My system seems to be too complicated for Boot-repair (dual NVME disks, RAID1, fully encrypted, LVM).
I hope this helps someone.
This document (000019679) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 12 SP5
SUSE Linux Enterprise Server 15 SP2
SUSE Linux Enterprise Server for SAP Applications 12 SP5
SUSE Linux Enterprise Server for SAP Applications 15 SP2
Situation
System was patched to fix the «Boothole» security issue (shim, grub2, mokutils plus additional needed patches like kernel, etc…)
Following reboot, the system is stuck in bootloader, saying:
grub2 error: symbol `grub_calloc' not found
Resolution
This must be fixed out of the rescue system.
Insert a SLES installation medium matching the installed (!) OS and boot the Rescue system.
Follow the instructions of https://www.suse.com/support/kb/doc/?id=000018770 and chroot into the installed OS.
- Check if the mandatory filesystems are mounted (compare /etc/fstab with «mount» output)
- Check if /etc/default/grub_installdevice contains the device where the root volume/filesystem is on.
- NOTE: grub_installdevice is a DISK device, not a partition! Also do not try to install the grub2 bootloader onto a disk without partitiontable. Grub2 needs space on the device to embed it’s code and that can only happen if there is a partition table on the disk.
Use « lsblk -f « command to determine the correct root disk.
If the correct device is found it is sufficient to reinstall the bootloader manually.
Examples (do NOT copy and paste, always use your system’s devices!):
grub2-install /dev/sda
grub2-install /dev/disk/by-id/scsi-361866d….
grub2-install /dev/mapper/mpatha
Should the disk name have changed (e.g. from sda to sdb for some reason) make sure all partitions in fstab use correct disk devices or the next reboot will end in emergency target as one or more partitions could not be found. In that case run «dracut -f —kver <installed kernel version>» to update initramfs.
Hint: use the directory name in /lib/modules/ like:
dracut -f —kver 4.12.14-197.29-default
If the system is UEFI/EFI there is a specific grub install command for that:
/usr/sbin/shim-install —config-file=/boot/grub2/grub.cfg
Cause
grub2 error: symbol `grub_calloc' not found
This error message points to a generic problem where the bootloader code itself is not compatible with the bootloader modules, hence the symbol error.
There are multiple reasons why this can happen:
- Bootloader is not installed on the disk with the root and/or boot filesystem
- /etc/default/grub_installdevice file contains false information
- /usr, /boot and/or /boot/efi filesystems out of space
- the copy operation from /usr/share/grub2/ to /boot/grub2 failed for some reason
- Bootloader installation failed after patching and system is using the old bootloader code with the new bootloader modules
- UEFI issues like broken loader entries
- …
Additional Information
In general, if a system fails to boot with errors like: : grub2 error: symbol `XYZ’ not found almost always there is a mismatch between bootloader code itself and the rest of the bootloader files. Reinstallation of the bootloader (grub2-install <device> ) usually fixes this.
grub2 error: module`XYZ’ not found points to a different problem. There the bootloader files /boot/grub2/i386-pc are not where the bootloader expects them to be. Note that kernel device names like sda, sdb, etc are not necessarily persistent across reboots and may change at any reboot. Here check carefully the disk names and use unique names like /dev/disk/by-id/scsi-36… wherever possible.
Note: older VMware ESX versions do not generate unique disk names in the guests by default. To enable uuids, follow this TID https://www.suse.com/support/kb/doc/?id=000016951
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented «AS IS» WITHOUT WARRANTY OF ANY KIND.
- Document ID:000019679
- Creation Date:
23-Sep-2021 - Modified Date:11-Oct-2021
-
- SUSE Linux Enterprise Server
- SUSE Linux Enterprise Server for SAP Applications
< Back to Support Search
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
- Печать
Страницы: [1] Вниз
Тема: «error: symbol ‘grub_calloc’ not found» при установке ubuntu budgie 21.04 (Прочитано 8434 раз)
0 Пользователей и 2 Гостей просматривают эту тему.
artem_2237
Хочу установить ubuntu budgie 21.04 рядом с windows 10. Скачал образ диска с официального сайта, записал на флэшку с помощью UltraIso. Перезагружаю компьютер, выбираю загрузку с флэшки. Дальше открывается grub, вверху надпись GNU GRUB 2.03, нужно выбрать ubuntu budgie и должна пойти установка. Выбираю Ubuntu budgie и получаю сообщение об ошибке «error: symbol ‘grub_calloc’ not found». Пробовал ставить Ubuntu 20.04.2.0 LTS, всё прекрасно установилось, никаких ошибок. Весь инет обшарил, хз что делать
« Последнее редактирование: 22 Июля 2021, 02:49:52 от artem_2237 »
vladimirzhuravlev
Дальше открывается grub, вверху надпись GNU GRUB 2.04, нужно выбрать ubuntu budgie и должна пойти установка.
Специально выбрал образ не «живой», а только инсталляционный ? Винда в каком режиме установлена …уефай или легаси ? На флешке в загрузочном меню что выбираешь ?
artem_2237
Пользователь добавил сообщение 21 Июля 2021, 22:38:53:
Специально выбрал образ не «живой», а только инсталляционный ? Винда в каком режиме установлена …уефай или легаси ? На флешке в загрузочном меню что выбираешь ?
Образ инсталяционной версии специально не выбирал, просто скачал с официального сайта https://ubuntubudgie.org/downloads/.
BIOS — Legacy.
В загрузочном меню есть 4 пункта:
— Ubuntu Budgie
— Ubuntu Budgie (safe graphics)
— OEM install (for manufacturers)
— Test memory
Я выбираю Ubuntu Budgie и получаю ошибку: «error: symbol ‘grub_calloc’ not found»
При выборе остальных пунктов та же ошибка
Пользователь добавил сообщение 21 Июля 2021, 22:46:03:
Пробовал ставить Ubuntu 20.04.2.0 LTS, тоже качал с официального сайта (https://ubuntu.com/download/desktop), то никаких ошибок не было
« Последнее редактирование: 21 Июля 2021, 22:46:03 от artem_2237 »
shamanhuev
BIOS — Legacy.
При винде десятке и легаси ?
artem_2237
При винде десятке и легаси ?
Да, так сложилось
shamanhuev
Да, так сложилось
Я не про это. Вопрос , в каком режиме установлена винда и в каком записана флешка с дистром. Вдруг несовпадение. Чем писал , как писал?
Дюшик
Можно попробовать записать флешку с ubuntu budgie другой программой, например Rufus -> Записать как dd образ.
Папандопуло
Да, действительно, хлопцы от Великого Дракона готовят дерьмосборки (не включают загрузчик). У меня Ноут флешку ваще не видит после записи стандартными средствами. Используя UneBootIn, можно обойти этот касяк. Проверено. RUFUSом не проверял.
ЗЫ. UnetBootIn просит FAT32 на флешку.
« Последнее редактирование: 22 Июля 2021, 12:50:01 от Папандопуло »
andytux
в каком режиме установлена винда и в каком записана флешка с дистром
На данном этапе — до лампочки. Эсли не совпадают, то скажется позже.
В загрузочном меню есть 4 пункта…
Судя по наличию в меню мемтеста, запускаешь в легаси режиме.
А если не побояться и запустить в ЕФИ-режиме. ГрубПС и грубЕФИ — это два, совершенно разных груба. Возможно ошибка только в грубПС. Ну и вариант, грузить другим грубом.
Я не стал ничего, никуда и ничем писать. Просто взял и загрузился из исо-образа.
« Последнее редактирование: 22 Июля 2021, 13:28:54 от andytux »
shamanhuev
Специально скачал этот дистр. Нормально грузится , уефи.
artem_2237
Попробовал установить budgie 20.04, всё с ходу заработало
- Печать
Страницы: [1] Вверх