Ich habe ein Systemupgrade von CentOS 7 auf AlmaLinux 8 ziemlich erfolgreich durchgeführt (wie erwähntHier). Während des Vorgangs ist etwas Seltsames passiert und GRUB hat seine Boot-Einträge vollständig verloren und meine begrenzten Bemühungen, sie/ihn wiederherzustellen (ich brauche wirklich nur den AlmaLinux 8-Kernel-Eintrag und es gibt bisher nur ein vmlinuz+ initrdImage vom Update), sind fehlgeschlagen (insbesondere, da ich seit meiner Gentoo-Zeit vor ein paar Jahrzehnten nicht mehr direkt mit GRUB herumspielen musste).
Um den Server derzeit zu booten, muss ich im Wesentlichen zur LISH-Konsole (genauer gesagt Glish) auf dem Linode-Server gehen und beim Neustart erhalte ich Folgendes:
Glisch:
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.
Dann in 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> _
Dann muss ich etwas in der Art der folgenden Zeilen eingeben, die ich in einem verzweifelten Versuch, ls (hd0)/boot/das System einfach in den Nicht-Einzelbenutzermodus zu bekommen, selbst zusammengeschustert habe, um es zum Booten zu bringen:
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
( Ein möglicherweise verfeinerter Satz von Boot-Argumenten, die ausgegeben werden sollten, wurde später nach Untersuchung und Diskussion gefunden:
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
)
Ich dachte, ich könnte dies einfach mit grub2-mkconfigonce in über den folgenden Befehl reparieren, aber wie Sie sehen, wurden einfach keine Einträge gefunden:
$ grub2-mkconfig --output /boot/grub2/grub.cfg
Generating grub configuration file ...
done
Wenn wir uns den generierten Abschnitt ansehen, b2/grub.cfg :: 10_linuxsehen wir:
### 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 ###
Außerdem /boot/loader/entries/gibt es tatsächlich eine Datei, die dem zu entsprechen scheint, was über BLS gebootet werden soll:
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
Und was betrifft 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
Es scheint, als ob der GRUB-Eintrag während des Bootvorgangs Folgendes enthalten sollte:
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
Das ist aber nicht der Fall ... Und ich habe zu diesem Zeitpunkt noch nichts manuell geändert und weiß daher nicht, wo/wie GRUB durcheinander gerät.
Zur Plausibilitätsprüfung habe ich überprüft, ob die Pakete wie erwartet installiert sind:
$ 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!
Letztendlich scheint es, als ob GRUB es entweder nicht findet oder die Analyse fehlschlägt grub.cfg...
Ich dachte, dass es vielleicht eine Änderung im Zusammenhang mit EFI gegeben haben könnte, da das Update anscheinend um stattfand /boot/grub2/grub.cfgund ich bemerkte, dass ein neuer LEERER Ordner um generiert worden war /boot/efi/EFI/almalinux/, also versuchte ich, ihn grub.cfgauch dort zu generieren:
$ grub2-mkconfig --output /boot/efi/EFI/almalinux/grub.cfg
Generating grub configuration file ...
done
Aber wie Sie sehen, gab es immer noch keine Einträge in und während der Generierung, und als ich neu gestartet habe, wurde auch keine automatische BLS-Generierung/-Verwendung durchgeführt (soweit ich weiß, könnte es passiert sein).
Hier sind die Inhalte verschiedener möglicherweise relevanter /boot/Ordner:
https://gist.github.com/ylluminate/d469ce8ace202a57f67f5aed255154cd
Was kann ich tun, damit GRUB wieder eine ordnungsgemäße Konfiguration erstellt und/oder analysiert und verwendet?
Antwort1
Es stellte sich heraus, dass der Schlüssel zur Lösung dieses Problems im Kontext eines Linode-Servers darin lag, zu deaktivieren GRUB_ENABLE_BLSCFGund erneut auszuführen grub2-mkconfig, z. B.:
$ 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