Realicé una actualización del sistema de CentOS 7 a AlmaLinux 8 con bastante éxito (como se señalóaquí). Durante el proceso sucedió algo extraño y GRUB perdió por completo sus entradas de arranque y mis esfuerzos limitados para reconstruirlas (realmente solo necesito la entrada del kernel AlmaLinux 8 y solo hay una imagen vmlinuz+ initrdhasta ahora de la actualización) han fallado (especialmente desde No he tenido que jugar con GRUB directamente desde mis días en Gentoo hace un par de décadas).
Actualmente, para que el servidor arranque, básicamente tengo que ir a la consola LISH (específicamente Glish) en el servidor Linode y esto es lo que obtengo al reiniciar:
Inglés:
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.
Luego en Lish y 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> _
Luego tengo que ingresar algo como lo siguiente, que preparé yo mismo como un esfuerzo desesperado ls (hd0)/boot/para simplemente iniciar el sistema en modo no de usuario único, para que arranque:
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
(Más adelante, tras una investigación y discusión, se encontró un conjunto quizás refinado de argumentos de arranque que deberían publicarse:
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
)
Pensé que podría simplemente reparar esto grub2-mkconfiguna vez con el siguiente comando, pero como puede ver, simplemente no encontró ninguna entrada:
$ grub2-mkconfig --output /boot/grub2/grub.cfg
Generating grub configuration file ...
done
Al mirar la b2/grub.cfg :: 10_linuxsección generada 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 ###
De hecho, también /boot/loader/entries/tiene un archivo que parece corresponder a lo que debería iniciarse a través de 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
Y en cuanto 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 la entrada de GRUB durante el arranque debería contener:
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
Sin embargo, no es así... Y en realidad no he modificado nada manualmente en este momento, por lo que no sé dónde ni cómo se está confundiendo GRUB.
Como comprobación de cordura, verifiqué que los paquetes estén instalados como se esperaba:
$ 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!
En última instancia, parece que GRUB no encuentra o no puede analizar grub.cfg...
Pensé que tal vez podría haber habido algún tipo de cambio relacionado con EFI, ya que parece que la actualización se estaba realizando en /boot/grub2/grub.cfgy noté que se había generado una nueva carpeta VACÍA en /boot/efi/EFI/almalinux/, así que intenté generarla grub.cfgallí también:
$ grub2-mkconfig --output /boot/efi/EFI/almalinux/grub.cfg
Generating grub configuration file ...
done
Pero como puede ver, todavía no hubo entradas durante la generación y cuando reinicié, tampoco se realizó ninguna generación/uso automático de BLS (como creo que entiendo que podría haber sucedido).
Aquí está el contenido de varias /boot/carpetas posiblemente pertinentes:
https://gist.github.com/ylluminate/d469ce8ace202a57f67f5aed255154cd
¿Qué puedo hacer para que GRUB construya y/o analice y use una configuración adecuada nuevamente?
Respuesta1
Resulta que la clave para resolver este problema en el contexto de un servidor Linode fue desactivar GRUB_ENABLE_BLSCFGy volver a ejecutar grub2-mkconfig, por ejemplo:
$ 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