Как восстановить систему, если GRUB потерял свои записи и при загрузке отображается только «grub>_»?

2024-6-28 • tag-icon

Как восстановить систему, если GRUB потерял свои записи и при загрузке отображается только «grub>_»?

Я выполнил обновление системы с CentOS 7 до AlmaLinux 8 довольно успешно (как отмеченоздесь). Во время этого процесса произошло что-то странное, и GRUB полностью потерял свои загрузочные записи, а мои ограниченные усилия по их восстановлению (мне на самом деле нужна только запись ядра AlmaLinux 8, а на данный момент есть только один образ vmlinuz+ initrdс момента обновления) потерпели неудачу (тем более, что мне не приходилось возиться с GRUB напрямую со времен Gentoo пару десятилетий назад).

В настоящее время для загрузки сервера мне по сути приходится заходить в консоль LISH (в частности Glish) на сервере Linode, и вот что я получаю при перезагрузке:

Глиш:

SeaBIOS (version rel-1.12.1-0.ga5ca58e9aef-prebuilt.qemu.org)

iPXE (http://ipxe.org) 00:04.0 C980 PCI2.10 PnP PMM+7FF90F20+7FEF0F20 C980


Booting from ROM...
Welcome to GRUB!

error: variable `prefix' isn't set.

Затем на Lish и Weblish:

                             GNU GRUB  version 2.04
   Minimal BASH-like line editing is supported. For the first word, TAB
   lists possible command completions. Anywhere else TAB lists possible
   device or file completions.


grub> _

Затем мне нужно ввести что-то вроде следующих строк, которые я составил сам в отчаянной попытке ls (hd0)/boot/заставить систему загрузиться в режиме, отличном от однопользовательского, чтобы она загрузилась:

set root=(hd0)
linux /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 root=/dev/sda console=ttyS0,19200n8
initrd /boot/initramfs-4.18.0-372.9.1.el8.x86_64.img
boot

(Возможно, уточненный набор аргументов загрузки, которые следует выдать, был найден позже после исследования и обсуждения:

set root=(hd0)
linux /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 root=/dev/sda ro crashkernel=auto rhgb console=ttyS0,19200n8 net.ifnames=0
initrd /boot/initramfs-4.18.0-372.9.1.el8.x86_64.img
boot

)

Я подумал, что могу просто исправить это с помощью grub2-mkconfigonce in с помощью следующей команды, но, как вы видите, она просто не нашла никаких записей:

$ grub2-mkconfig --output /boot/grub2/grub.cfg
Generating grub configuration file ...
done

При просмотре сгенерированного b2/grub.cfg :: 10_linuxраздела мы видим:

### BEGIN /etc/grub.d/10_linux ###
insmod ext2
set root='hd1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0 --hint-efi=hd0 --hint-baremetal=ahci0 --hint='hd1'  06e9a827-47b4-43f9-8e01-91b3852f86a8
else
  search --no-floppy --fs-uuid --set=root 06e9a827-47b4-43f9-8e01-91b3852f86a8
fi
insmod ext2
set boot='hd1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=boot --hint-bios=hd0 --hint-efi=hd0 --hint-baremetal=ahci0 --hint='hd1'  06e9a827-47b4-43f9-8e01-91b3852f86a8
else
  search --no-floppy --fs-uuid --set=boot 06e9a827-47b4-43f9-8e01-91b3852f86a8
fi

# This section was generated by a script. Do not modify the generated file - all changes
# will be lost the next time file is regenerated. Instead edit the BootLoaderSpec files.
#
# The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification documentation
# for the files format: https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/.

# The kernelopts variable should be defined in the grubenv file. But to ensure that menu
# entries populated from BootLoaderSpec files that use this variable work correctly even
# without a grubenv file, define a fallback kernelopts variable if this has not been set.
#
# The kernelopts variable in the grubenv file can be modified using the grubby tool or by
# executing the grub2-mkconfig tool. For the latter, the values of the GRUB_CMDLINE_LINUX
# and GRUB_CMDLINE_LINUX_DEFAULT options from /etc/default/grub file are used to set both
# the kernelopts variable in the grubenv file and the fallback kernelopts variable.
if [ -z "${kernelopts}" ]; then
  set kernelopts="root=/dev/sda ro crashkernel=auto rhgb console=ttyS0,19200n8 net.ifnames=0 "
fi

insmod blscfg
blscfg
### END /etc/grub.d/10_linux ###

Также /boot/loader/entries/действительно есть файл, который, похоже, соответствует тому, что должно загружаться через BLS:

title AlmaLinux (4.18.0-372.9.1.el8.x86_64) 8.6 (Sky Tiger)
version 4.18.0-372.9.1.el8.x86_64
linux /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
initrd /boot/initramfs-4.18.0-372.9.1.el8.x86_64.img $tuned_initrd
options $kernelopts $tuned_params
id almalinux-20220510130458-4.18.0-372.9.1.el8.x86_64
grub_users $grub_users
grub_arg --unrestricted
grub_class kernel

А что касается grubenv:

$ grub2-editenv list
saved_entry=4f09fa5fdd3642fa85221d7c11370603-4.18.0-372.9.1.el8.x86_64
kernelopts=root=/dev/sda ro crashkernel=auto rhgb console=ttyS0,19200n8 net.ifnames=0
boot_indeterminate=1

Похоже, что запись GRUB во время загрузки должна содержать:

linux /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64 root=/dev/sda ro crashkernel=auto rhgb console=ttyS0,19200n8 net.ifnames=0

Но это не так... И на самом деле я ничего не менял вручную на данный момент, поэтому не знаю, где/как GRUB запутался.

В качестве проверки работоспособности я убедился, что пакеты установлены так, как и ожидалось:

$ dnf install kernel grub2
Last metadata expiration check: 2:31:00 ago on Fri Jun 17 13:43:41 2022.
Package kernel-4.18.0-372.9.1.el8.x86_64 is already installed.
Package grub2-pc-1:2.02-123.el8.alma.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

В конечном итоге создается впечатление, что GRUB либо не находит, либо не может проанализировать grub.cfg...

Я подумал, что, возможно, произошли какие-то изменения, связанные с EFI, поскольку, похоже, обновление происходило в , /boot/grub2/grub.cfgи я заметил, что была создана новая ПУСТАЯ папка /boot/efi/EFI/almalinux/, поэтому я попытался создать ее grub.cfgи там:

$ grub2-mkconfig --output /boot/efi/EFI/almalinux/grub.cfg
Generating grub configuration file ...
done

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

Вот содержимое различных /boot/папок, которые могут иметь отношение к теме: https://gist.github.com/ylluminate/d469ce8ace202a57f67f5aed255154cd

Что я могу сделать, чтобы GRUB снова начал собирать и/или анализировать и использовать правильную конфигурацию?

решение1

Оказывается, ключом к решению этой проблемы в контексте сервера Linode было отключение GRUB_ENABLE_BLSCFGи повторный запуск grub2-mkconfig, например:

$ nano /etc/default/grub
### set: GRUB_ENABLE_BLSCFG=false
$ grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.18.0-372.9.1.el8.x86_64
Found initrd image: /boot/initramfs-4.18.0-372.9.1.el8.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-4f09fa5fdd3642fa85221d7c11370603
Found initrd image: /boot/initramfs-0-rescue-4f09fa5fdd3642fa85221d7c11370603.img
done

решение1

Связанный контент