Realizei uma atualização do sistema do CentOS 7 para o AlmaLinux 8 com bastante sucesso (conforme observadoaqui). Durante o processo, algo estranho aconteceu e o GRUB perdeu completamente suas entradas de inicialização e meus esforços limitados em reconstruí-las (eu realmente só preciso da entrada do kernel AlmaLinux 8 e há apenas uma imagem vmlinuz+ initrdaté agora da atualização) falharam (especialmente desde Eu não tive que mexer diretamente no GRUB desde meus dias no Gentoo, algumas décadas atrás).
Atualmente, para fazer o servidor inicializar, eu essencialmente tenho que ir para o console LISH (especificamente Glish) no servidor Linode e é isso que recebo na reinicialização:
Glish:
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.
Então em 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> _
Em seguida, tenho que inserir algo como o seguinte, que eu mesmo preparei como um esforço desesperado ls (hd0)/boot/para fazer o sistema inicializar no modo de usuário não único, para inicializá-lo:
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
(Um conjunto talvez refinado de argumentos de inicialização que deveriam ser emitidos foi encontrado posteriormente após investigação e discussão:
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
)
Achei que poderia simplesmente consertar isso grub2-mkconfiguma vez por meio do seguinte comando, mas como você pode ver, ele simplesmente não encontrou nenhuma entrada:
$ grub2-mkconfig --output /boot/grub2/grub.cfg
Generating grub configuration file ...
done
Ao olhar para a b2/grub.cfg :: 10_linuxseção gerada, vemos:
### 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 ###
Também /boot/loader/entries/possui um arquivo que parece corresponder ao que deveria ser inicializado via 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
E quanto a 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
Parece que a entrada do GRUB durante a inicialização deve conter:
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
No entanto, isso não acontece ... E na verdade não modifiquei nada manualmente neste momento e, portanto, não sei onde/como o GRUB está ficando confuso.
Como verificação de integridade, verifiquei que os pacotes estão instalados conforme esperado:
$ 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!
Em última análise, parece que o GRUB não encontra ou falha ao analisar grub.cfg...
Achei que talvez tenha havido algum tipo de mudança envolvendo o EFI, pois parece que a atualização estava acontecendo /boot/grub2/grub.cfge percebi que uma nova pasta EMPTY havia sido gerada em /boot/efi/EFI/almalinux/e tentei gerar grub.cfglá também:
$ grub2-mkconfig --output /boot/efi/EFI/almalinux/grub.cfg
Generating grub configuration file ...
done
Mas como você pode ver, ainda não houve entradas durante e durante a geração e quando reiniciei, nenhuma geração/uso automático de BLS também foi realizada (como acho que entendo que poderia ter acontecido).
Aqui está o conteúdo de várias /boot/pastas possivelmente pertinentes:
https://gist.github.com/ylluminate/d469ce8ace202a57f67f5aed255154cd
O que posso fazer para construir e/ou analisar o GRUB e usar uma configuração adequada novamente?
Responder1
Acontece que a chave para resolver este problema no contexto de um servidor Linode era desabilitar GRUB_ENABLE_BLSCFGe executar novamente grub2-mkconfig, por exemplo:
$ 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