Grub2-Bootloader Defect

[dcz01]

Hallo zusammen,
nachdem ich dieses Problem bereits auch im CentOS-Forum stehen habe, wollte ich es nicht nochmal übersetzen...
Ich hoffe es kann mir jemand helfen.

I have an bigger problem with one machine on UEFI with the Grub2-Bootloader.
I updated the machine some days ago with the command

yum update -y --allowerasing

and so the following package was uninstalled:

Removing dependent packages:
grub2-efi-x64                 x86_64  1:2.02-90.el8                 @anaconda             1.8 M

Then the server was rebooted and couldn't start up normally.
So i tried a repair of the bootloader with an GParted-Live-CD (Debian).
These where my used commands:

sudo mkdir /mnt/sysimage
sudo mount /dev/sda3 /mnt/sysimage
sudo mount /dev/sda2 /mnt/sysimage/boot
sudo mount /dev/sda1 /mnt/sysimage/boot/efi
sudo mount -o bind /dev /mnt/sysimage/dev
sudo mount -o bind /sys /mnt/sysimage/sys
sudo mount -t proc /proc /mnt/sysimage/proc
chroot /mnt/sysimage
grub2-install --efi-directory=/boot/efi --target=x86_64-efi /dev/sda

After that the system won't even start itself to CentOS 8 and it always waited for input at:

grub >

With the following command i could start it back to my CentOS 8.3.2011:

grub > normal

Then it loaded the kernel before the update but i can use my system.

Now in the system (CentOS) i tried to reinstall the grub2-efi-x64 and used this two commands:

grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg

grub2-install /dev/sda

But the normal grub isn't installed anymore on the MBR and i must use always the normal command to boot manually.

The grub2-install always creates two dirs at /boot/grub2:
One fonts dir and one x86_64-efi dir.

Does anyone know how to fix this problem?

Grüße
dcz01

 

[Grimba]

Also mit der Debian Live Distribution hast du den Grub ins EFI intalliert, aber zurück unter CentOS versuchst du ihn, in den MBR zu installieren, den du in dem Fall doch gar nicht hast, weil 1. GPT und 2. es ist noch immer EFI?

Was ist aus
--efi-directory=/boot/efi --target=x86_64-efi
geworden im zweiten Fall?

 

[dcz01]

@Grimba Danke für deine schnelle Antwort.
Meinst du dieser Befehl würde unter dem CentOS alles wieder normalisieren?

grub2-install --efi-directory=/boot/efi --target=x86_64-efi /dev/sda

 

[Grimba]

Ob das jetzt exakt der richtige Befehl ist, kann ich dir nicht sagen, vermutlich aber schon.

Was ich dir aber mit 100%iger Sicherheit sagen kann, ist, dass das, was du unter Debian gemacht hast, etwas anderes ist als das, was du unter CentOS versucht hast:

Du hast ein EFI System, das schließt MBR aus, denn dafür hast du gar keinen MBR, sondern GPT als Partitionstabelle sowie eine EFI Partition und natürlich musst du dann auch, wie du es unter Debian getan hast, GRUB mitteilen, dass du einen EFI Bootloader installieren willst. Demnach kann das, was du unter CentOS da versuchst, überhaupt nicht funktionieren.

edit: An deiner Stelle hätte ich auch, um Versionskonflikte zu vermeiden, eine CentOS Live Distribution genommen, und nicht eine ganz andere Distribution.

 

[Linuxfreakgraz]

Frage warum --allowerasing? Die habe ich unter Fedora noch nie genutzt.

 

[dcz01]

@Linuxfreakgraz Diese Option wurde genutzt um nicht mehr nötige Pakete bei Bedarf entfernen lassen zu können.
Warum nun ein wichtiges Grub2-EFI-Paket auf einer UEFI-Maschine entfernt worden ist, verstehe ich auch noch nicht so ganz.

 

[Grimba]

Warum nun ein wichtiges Grub2-EFI-Paket auf einer UEFI-Maschine entfernt worden ist, verstehe ich auch noch nicht so ganz.

Naja, auch das ist klar: weil DU zugestimmt hast.

Du wirst ja vorher gefragt, es sei denn, du hast "-y" benutzt, und das hast du ja hier, und damit allem vorab zugestimmt.

Dass das leichtsinnig ist, insbesondere in Verbindung zu "--allowerasing", hast du ja jetzt gemerkt, denn damit hast du dir jede Möglichkeit der Prüfung und des Eingreifens genommen, außer rechtzeitig Strg+C zu drücken. Offenbar kommt der Grub hier auch nicht aus dem Hauptrepository, sondern von Anaconda.

 

[mkossmann]

Code:

sudo mkdir /mnt/sysimage
sudo mount /dev/sda3 /mnt/sysimage
sudo mount /dev/sda2 /mnt/sysimage/boot
sudo mount /dev/sda1 /mnt/sysimage/boot/efi
sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /sys /mnt/sys
sudo mount -t proc /proc /mnt/proc
chroot /mnt/sysimage
grub2-install --efi-directory=/boot/efi --target=x86_64-efi /dev/sda

Die mount Kommandos passen hier nicht zusammen . Wenn du die Root-Partition nach /mnt/sysimage mountest, muß auch /dev /sys und/proc nach /mnt/sysimage.

 

[dcz01]

Hier habe ich nochmal alles nötige gefunden, um es wohl wiederherzustellen:
https://fedoraproject.org/wiki/GRUB_2#Reinstalling_GRUB_2

Jedoch sind alle Dateien wieder da, aber er bootet mir nicht automatisch durch, sondern bleibt immernoch bei "grub > " hängen.

Ergänzung (12. Mai 2021)

@mkossmann Jap, sorry. Das war einfach nur schnell aus der Internetanleitung ohne meine eigene Anpassung wieder rauskopiert.
Habs oben nun nochmal korrigiert, wie ich es genutzt hatte.

Ergänzung (12. Mai 2021)

Könnte dies vllt. auch genau mein Problem sein?
https://thomas-leister.de/en/repair-fedora-efi-bootloader/

 

[Grimba]

Fedora != CentOS. Die sind zwar verwand, aber nicht zwingend gleich, denn sie sind für 2 völlig unterschiedliche Nutzergruppen gedacht. Fedora ist bleeding edge, CentOS das genaue Gegenteil davon. Daher solltest du in die Doku von CentOS schauen oder nach Tipps dafür, da das, was hier steht, nicht zwingend für dein System funktionieren muss.

 

[dcz01]

@Grimba Ja das stimmt schon... Aber selbst RedHat hat wohl in der Doku nichts von grub2-install bei UEFI stehen: https://access.redhat.com/documenta...er#sec-grub2-reinstall_on_UEFI-Based_Machines

 

[Grimba]

Also für mein Verständnis steht da bei deinem Link was. Was fehlt dir denn da genau?

BTW: Warnung in deinem vorherigen Link aus der Fedora Docu mal gelesen?

Do not use the grub2-install command on UEFI systems. On those systems, bootloaders are in the shim and grub-efi packages. By reinstalling those packages, the bootloaders are reinstalled to their proper location in /boot/efi/ (the EFI system partition).

Das könnte in der Tat auch bei RedHat/CentOS der Fall sein, womit es vermutlich in der hier verlinkten Anleitung auch nicht steht. Du hast den Befehl ja auch aus einer Anleitung für eine ganz andere Distribution, nämlich Debian, schon vergessen? Offensichtlich lösen das Fedora und RedHat/CentOS direkt über den Package Manager. Das heißt nicht, dass grub2-install mit Efi Parametern grundsätzlich nicht funktioniert, sondern offensichtlich gibt es für den Anwendungsfall ein Scriptgerüst. Und das ist vorzuziehen, wenn man nicht genau weiß, was man tut.

 

[Linuxfreakgraz]

Der Maintainer von Grub2 in dem Repository hat bei der Paketbeschreibung vergessen das Efi Paket als wichtige Abhängigkeit zu deklarieren. So konnte YUM das nicht wissen.

 

[dcz01]

Fehlen tut mir jetzt nichts mehr... Habe alles nochmal frisch in neuester Version installiert:

yum reinstall -y grub2-efi-x64-modules grub2-efi-x64 grub2-tools-efi grub2-tools shim-x64 efivar efibootmgr efi-filesystem efivar-libs

Ergänzung (12. Mai 2021)

@Linuxfreakgraz Sowas in der Art dachte ich mir fast schon...
Woher hast du diese Info denn?

 

[Linuxfreakgraz]

Woher hast du diese Info denn?

Das ist ein Hypothese von mir, auf Grund von 16 Jahren Linuxerfahrung. Ich hab schon einige Systeme geschrottet.
Wenn der Server sich nicht mehr Bootfähig kriegen lässt wird das extrem Aufwändig.
https://community.spiceworks.com/how_to/114945-centos-7-backup-and-restore

 

[Wochenende]

@dcz01

Poste mal die Ausgabe von ls -lR /boot/efi

 

[mkossmann]

Du bootest auch wirklich von einer SATA HDD/SSD/M2 ? Wenn du von einer NVMe SSD bootest, hast du das falsche Device benutzt. Zur Informationssammlung könntest du mal bootinfoscript laufen lassen.

 

[dcz01]

@Wochenende Hier wäre die Ausgabe, dort ist schon Inhalt drin:

ls -IR /boot/efi/
EFI

[root@brp-server ~]# ls -la /boot/efi/EFI/
insgesamt 28
drwx------. 4 root root  4096 11. Mai 2019  .
drwx------. 3 root root 16384  1. Jan 1970  ..
drwx------. 2 root root  4096 12. Mai 16:14 BOOT
drwx------. 3 root root  4096 12. Mai 17:12 centos
[root@brp-server ~]# ls -la /boot/efi/EFI/BOOT/
insgesamt 1580
drwx------. 2 root root    4096 12. Mai 16:14 .
drwx------. 4 root root    4096 11. Mai 2019  ..
-rwx------. 1 root root 1244496  1. Aug 2020  BOOTX64.EFI
-rwx------. 1 root root  362264  1. Aug 2020  fbx64.efi
[root@brp-server ~]# ls -la /boot/efi/EFI/centos/
insgesamt 3784
drwx------. 3 root root    4096 12. Mai 17:12 .
drwx------. 4 root root    4096 11. Mai 2019  ..
-rwx------. 1 root root     134  1. Aug 2020  BOOTX64.CSV
drwx------. 2 root root    4096  2. Mär 21:51 fonts
-rwx------. 1 root root    6548 12. Mai 17:12 grub.cfg
-rwx------. 1 root root    1024 12. Mai 17:12 grubenv
-rwx------. 1 root root  196096 12. Mai 17:11 grubx64.efi
-rwx------. 1 root root 1162400  1. Aug 2020  mmx64.efi
-rwx------. 1 root root 1238416  1. Aug 2020  shimx64-centos.efi
-rwx------. 1 root root 1244496  1. Aug 2020  shimx64.efi

@mkossmann Ich bin mir sehr sicher, dass wenn überhaupt /dev/sda passt, da es sich hier um ein Hardware-RAID handelt, welches als "eine Festplatte" erkannt wird.

Ich glaube aber rausgefunden zu haben, dass ich eher das Tool efibootmgr nutzen muss, um einen (U)EFI-Booteintrag zu erzeugen.
grub2-install darf wohl nicht verwendet werden, da es eine wichtige efi-Datei sonst überschreibt und sich ja nur in den MBR schreibt, welcher dann aber nicht gelesen wird.
efibootmgr kommuniziert direkt mit dem UEFI des Systems, welches dann selbst als Bootloader arbeitet:
https://wiki.gentoo.org/wiki/Efibootmgr/de

 

[dcz01]

Aber wie man korrekt den EFI-Bootloader wieder zum laufen bringt mit folgender Partitionierung weiß auch niemand oder?

[root@FBD01PSS ~]# parted -l
Modell: VMware Virtual disk (scsi)
Festplatte  /dev/sda:  215GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:

Nummer  Anfang  Ende   Größe   Dateisystem     Name                  Flags
 1      1049kB  211MB  210MB   fat16           EFI System Partition  boot, esp
 2      211MB   735MB  524MB   xfs
 3      735MB   106GB  105GB   xfs
 4      106GB   114GB  8460MB  linux-swap(v1)                        swap
 5      114GB   114GB  1049kB                                        bios_grub
 6      114GB   215GB  101GB   xfs

Ergänzung (14. Mai 2021)

Ich habs endlich gefunden, warum mir die drecks Kiste ned booten wollte...
Das alte pmbr_boot Flag war gesetzt und hat blockiert.
Gefunden hab ichs hier: https://www.suse.com/support/kb/doc/?id=000019468
Jetzt bootet das Ding endlich unter UEFI richtig. Schade und ich dachte man könnte es irgendwie BIOS-UEFI-Koexistent-Bootbar machen...

Modell: VMware Virtual disk (scsi)
Festplatte  /dev/sda:  215GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: pmbr_boot

Nummer  Anfang  Ende    Größe   Dateisystem     Name  Flags
 1      1049kB  2097kB  1049kB                        bios_grub
 2      2097kB  526MB   524MB   xfs
 3      526MB   105GB   105GB   xfs
 4      105GB   114GB   8482MB  linux-swap(v1)        swap
 5      114GB   114GB   210MB   fat16                 boot, esp
 6      114GB   215GB   101GB   xfs

 

[Wochenende]

Danke für die Info dcz01, das mit dem pmbr_boot war mir neu. Vermutlich will deshalb Windows bei UEFI immer GPT, bei BIOS immer MSDOS/MBR haben.

Ich selbst habe bei meinem Linux aus Versehen UEFI+MBR eingerichtet, geht aber ohne Probleme.