[solved] grub2 schreibt nur GRUB GRUB GRUB... auf den Bildschirm

[Geier0815]

Moin Moin,

ich habe hier bei einem SLES12 SP4 das Problem das (offensichtlich) nach einem Crash grub2 nicht mehr will. Der gesamte Bildschirm wird mir dem Wort grub vollgeschrieben, direkt nach dem Crash kam nur ein roter Bildschirm mit der Meldung "illegal opcode".

Maschine ist eine HP DL 360 Gen9 mit P440ar Raid-Controller und Raid 1. Das logische Laufwerk ist GPT, lief/läuft aber per legacy-mode.
Mit einer Live-DVD hab ich schon die Partitionen geprüft und repariert. Grub hab ich dann versucht per grub-install neu zu schreiben, seitdem nur noch "GRUB GRUB GRUB" den gesamten Bildschirm voll.
Mittels Super Grub 2 DVD läßt sich das SLES starten. "grub2-install /dev/sda" und "grub2-mkconfig -o /boot/grub2/grub.cfg" bringt genauso viel bzw wenig wie der Versuch über yast den bootrecord zur Mitarbeit zu überreden. Die boot-Partition hat die flags bios_grub und legacy_boot.

Hat einer von euch 'ne Idee was ich gerade übersehe?

 

[susejunky]

Hallo Geier0815,

... ich habe hier bei einem SLES12 SP4 das Problem das (offensichtlich) nach einem Crash grub2 nicht mehr will. Der gesamte Bildschirm wird mir dem Wort grub vollgeschrieben, direkt nach dem Crash kam nur ein roter Bildschirm mit der Meldung "illegal opcode".

Maschine ist eine HP DL 360 Gen9 mit P440ar Raid-Controller und Raid 1. Das logische Laufwerk ist GPT, lief/läuft aber per legacy-mode.

Wenn das Laufwerk mit GPT partitioniert ist, empfiehlt es sich eine separate BIOS-boot-Partition (https://www.gnu.org/software/grub/manual/grub/grub.html#BIOS-installation) zu nutzen .

Ist eine solche vorhanden?

Viele Grüße

susejunky

 

[Geier0815]

sda1 ist swap
sda2 ist boot
sda3 ist system

Installiert wurde in MBR und boot-Partition. Autoyast-Einträge boot_boot und boot_mbr beide auf true, die anderen auf false. Hat ja auch funktioniert, bis zum crash. Und ist jetzt auch das erste System das solche Zicken macht. Bei anderen System, die Probleme hatten, hat die Wiederherstellung per Live-DVD immer funktioniert, Hardwaredefekte natürlich ausgenommen.

 

[susejunky]

Hallo Geier0815,

sda1 ist swap
sda2 ist boot
sda3 ist system

Installiert wurde in MBR und boot-Partition.

Und sda2 hat auch den Partitionstyp ‘0xEF02’ bzw. GUID ‘21686148-6449-6e6f-744e656564454649’?

Viele Grüße

susejunky

 

[josef-wien]

Zu dem Fehlerbild fällt mir nur ein, daß GRUB2-Dateien beschädigt sein könnten (aus Sicht des Dateisystems sind sie trotzdem in Ordnung). Entferne einmal alle GRUB2-Pakete (und das, was auf /boot/grub2 übrigbleiben sollte), und installiere sie und den Boot-Manager dann neu.

 

[Geier0815]

[...]
Und sda2 hat auch den Partitionstyp ‘0xEF02’ bzw. GUID ‘21686148-6449-6e6f-744e656564454649’?

Partitionsname: primary │
│ Partitions-UUID: 6B8FCA6B-456C-462A-9AB8-D1DD7F08C9A5 │
│ Partitionstyp: BIOS boot (21686148-6449-6E6F-744E-656564454649) │
│ Attribute: LegacyBIOSBootable │
│Dateisystem-UUID: 30b0190f-a8b9-41f4-87ff-8e77d1b74c3a │
│ Dateisystem: ext3 │
│ Einhängepunkt: /boot (eingehängt)

Sieht so aus.


@josef-wien,

Wenn die Dateien unterhalb von /boot/grub2 beschädigt wären, dann würde die Super Grub2 DVD doch den original-Eintrag des SLES nicht finden. Tut er aber und kann das System auch booten. Und wenn das grub-Paket bzw die binary selber defekt wäre, würden grub2-install und grub2-mkconfig auf die Nase fallen.

Ich habe inzwischen den Verdacht das da irgendwelche Bytes im MBR nicht sauber überschrieben werden oder zusätzlich da sind. Früher hätte ich da die ersten 440 Byte des MBR mit Nullen per dd überschrieben, bin mir aber nicht sicher ob ich mir bei einer gpt damit nicht auch schon Teile der Partitiontabelle kaputt mache.

 

[josef-wien]

Um Linux zu starten, benötigt man nur Kernel und initrd. Vom Rest verwendet die Super GRUB2 Disk wahrscheinlich noch die Menü-Datei, um allfällige Boot-Optionen bzw. Auswahlmöglichkeiten anzubieten.

Auch bei einer GPT steht der Boot-Code in den ersten 440 Bytes des MBR. Der Aufbau des MBR hat sich nicht verändert, nur die Partitionentabelle enthält einen Dummy-Eintrag, der die gesamte Platte als belegt ausweist. Die erste GPT beginnt ab Sektor 1 (und die zweite befindet sich am Ende der Platte).

Das Problem steht im 1. Teil Deines letzten Beitrags: Eine BIOS-Boot-Partition hat kein herkömmliches Dateisystem, und sie darf nie eingehängt sein. Dort speichert GRUB2 seinen Boot-Code (der MBR enthält im Wesentlichen nur einen Sprungbefehl dorthin), und der wird zerstört, wenn irgendetwas außer GRUB2 dort schreibt. Hast Du den Partitionentyp nachträglich geändert? Hast Du die Partition nachträglich formatiert?

 

[susejunky]

Hallo Geier0815,

... Partitionsname: primary │
│ Partitions-UUID: 6B8FCA6B-456C-462A-9AB8-D1DD7F08C9A5 │
│ Partitionstyp: BIOS boot (21686148-6449-6E6F-744E-656564454649) │
│ Attribute: LegacyBIOSBootable │
│Dateisystem-UUID: 30b0190f-a8b9-41f4-87ff-8e77d1b74c3a │
│ Dateisystem: ext3 │
│ Einhängepunkt: /boot (eingehängt)

wenn ich das bereits zitierte GRUB2-Handbuch richtig verstehe, dann schreibt grub2-install die zweite Stufe des Bootloaders (früher "stage2"?) in eine mit GUID "21686148-6449-6E6F-744E-656564454649" gekennzeichnete Partition.

Ich bezweifle, dass ein in dieser Partition angelegtes ext3-Dateisystem danach noch richtig funktioniert/ genutzt werden kann.

Viele Grüße

susejunky

 

[Geier0815]

Das Problem steht im 1. Teil Deines letzten Beitrags: Eine BIOS-Boot-Partition hat kein herkömmliches Dateisystem, und sie darf nie eingehängt sein. Dort speichert GRUB2 seinen Boot-Code (der MBR enthält im Wesentlichen nur einen Sprungbefehl dorthin), und der wird zerstört, wenn irgendetwas außer GRUB2 dort schreibt. Hast Du den Partitionentyp nachträglich geändert? Hast Du die Partition nachträglich formatiert?

Aha, und dein /boot-Verzeichnis bei einer Installation ohne boot-Partition ist nicht lesbar? Merkwürdigerweise kannst Du deine vmlinuz und die initrd sehen, was nach deiner beschriebenen Logik ja nicht möglich sein dürfte. Und nein, ich habe die Partition nicht nachträglich formatiert aber per fsck reparieren lassen. Und den Partitionstyp hab ich auch nicht verändert aber zusätzlich das flag bios_grub gesetzt, legacy_boot war schon/noch gesetzt.

Ok, ich werde Montag mal die ersten 440 Byte mit Nullen überschreiben und dann nochmals grub2-install und grub2-mkconfig laufen lassen. Wenn das auch nichts bringt, werden die wichtigsten Konfigurationen und der content gesichert und die Kiste dann neu aufgesetzt.
Trotzdem finde ich es lustig das meine Suche nach dem Fehlerbild (auch per Bildersuche) zwar etwas gebracht hat, aber keine direkte Beschreibung ala "wenn Du nur noch so etwas siehst, fehlt dies oder das ist kaputt".

 

[susejunky]

Hallo Geier0815,

Das Problem steht im 1. Teil Deines letzten Beitrags: Eine BIOS-Boot-Partition hat kein herkömmliches Dateisystem, und sie darf nie eingehängt sein. Dort speichert GRUB2 seinen Boot-Code (der MBR enthält im Wesentlichen nur einen Sprungbefehl dorthin), und der wird zerstört, wenn irgendetwas außer GRUB2 dort schreibt. Hast Du den Partitionentyp nachträglich geändert? Hast Du die Partition nachträglich formatiert?

"... Some newer systems use the GUID Partition Table (GPT) format. This was specified as part of the Extensible Firmware Interface (EFI), but it can also be used on BIOS platforms if system software supports it; for example, GRUB and GNU/Linux can be used in this configuration. With this format, it is possible to reserve a whole partition for GRUB, called the BIOS Boot Partition. GRUB can then be embedded into that partition without the risk of being overwritten by other software and without being contained in a filesystem which might move its blocks around.

When creating a BIOS Boot Partition on a GPT system, you should make sure that it is at least 31 KiB in size. (GPT-formatted disks are not usually particularly small, so we recommend that you make it larger than the bare minimum, such as 1 MiB, to allow plenty of room for growth.) You must also make sure that it has the proper partition type. Using GNU Parted, you can set this using a command such as the following:

# parted /dev/disk set partition-number bios_grub on

If you are using gdisk, set the partition type to ‘0xEF02’. With partitioning programs that require setting the GUID directly, it should be ‘21686148-6449-6e6f-744e656564454649’.

Caution: Be very careful which partition you select! When GRUB finds a BIOS Boot Partition during installation, it will automatically overwrite part of it. Make sure that the partition does not contain any other data. "

Quelle: https://www.gnu.org/software/grub/manual/grub/grub.html#BIOS-installation

Wenn ich das so lese, dann gelange ich zu der Überzeugung, dass die oben zitierte Aussage von josef-wien durchaus zutrifft.

Den MBR zu überschreiben wird das Problem also sehr wahrscheinlich nicht beseitigen.

Die schnellste und einfachste Lösung wäre meines Erachtens den aktuellen Inhalt von sda2 (das Verzeichnis /boot mit seinem kompletten Inhalt sofern unbeschädigt) nach sda3 zu verlagern, fstab anzupassen und dann per chroot-Umgebung nochmals grub2-install laufen zu lassen.

Alternativ könntest Du

• sda2 (mit /boot auf ext3-Datei-System) überprüfen und ggf. reparieren, dann etwas verkleinern und mit dem Partitionstyp "0x8300" versehen
• eine neue 1MB große BIOS-Boot-Partition mit dem Partitionstyp "0xEF02" ohne Dateisystem anlegen
• grub2-install nochmals durchführen (chroot)

Oder, wenn Du keine BIOS-Boot-Partition nutzen/anlegen kannst/willst, kannst Du natürlich auch versuchen den zweiten Teil des Bootloaders in die Lücke zwischen dem MBR und der ersten Partition zu speichern. Ob und wie das bei GPT geht, kann ich Dir jedoch nicht sagen (Vielleicht macht grub2-install das automatisch, wenn es keine 0xEF02-BIOS-Boot-Partition findet).

Viele Grüße

susejunky

 

[josef-wien]

Und den Partitionstyp hab ich auch nicht verändert aber zusätzlich das flag bios_grub gesetzt

Der Teil vor dem "aber" widerspricht dem Teil nach dem "aber". Du hast eine normale Linux-Partition als BIOS-Boot-Partition gekennzeichnet und damit GRUB2 gegenüber als dessen alleiniges Eigentum deklariert. Folgerichtig hinterlegt GRUB2 seinen Programmcode dort in den laut Handbuch ersten 31 KiB. Was Ext3 am Anfang speichert, kann ich nicht sagen (da wirst Du robi fragen müssen), aber offensichtlich wird spätestens beim Schließen des Dateisystems dort geschrieben und somit der GRUB2-Programmcode unbrauchbar gemacht. Die Verzeichnisse und Dateien liegen weiter hinten, diesbezüglich sieht also auf den ersten Blick alles normal aus.

Definiere den Partitionentyp wieder als normale Linux-Partition (danach muß

sgdisk -i 2 /dev/sda

Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)

zeigen), repariere das Dateisystem, und installiere GRUB2 in den MBR. Du bist bisher ohne BIOS-Boot-Partition ausgekommen, Du wirst sie auch in Zukunft mit an Sicherheit grenzender Wahrscheinlichkeit nicht brauchen (der Sprungbefehl im MBR zeigt dann wieder auf den logischen Sektor, in dem die GRUB2-Datei im Dateisystem von /dev/sda2 beginnt). Selbstverständlich kannst Du auch eine BIOS-Boot-Partition anlegen, aber die gehört dann exklusiv GRUB2 (zur Minimierung des Restrisikos, falls aus irgendwelchen Gründen die GRUB2-Datei im Dateisystem in einen anderen logischen Sektor verlegt wird).

Lücke zwischen dem MBR und der ersten Partition

Die erste GPT beginnt ab Sektor 1

 

[susejunky]

Hallo josef-wien,

...

Lücke zwischen dem MBR und der ersten Partition

Die erste GPT beginnt ab Sektor 1

Danke für den Hinweis! Aber wie ich bereits sagte: "Vielleicht .."

Seit mindestens 3 Jahren nutze ich ausschließlich UEFI-boot und zu BIOS-Boot-Zeiten habe ich GPT-Partitionierung immer nur mit separater BIOS-Boot-Partition benutzt. Aber in meinen Unterlagen von damals habe ich noch diesen Link gefunden:

https://en.wikipedia.org/wiki/File:GNU_GRUB_on_GPT_partitioned_hard_disk_drives.svg

Viele Grüße

susejunky

 

[susejunky]

Hallo josef-wien,

... installiere GRUB2 in den MBR. Du bist bisher ohne BIOS-Boot-Partition ausgekommen, Du wirst sie auch in Zukunft mit an Sicherheit grenzender Wahrscheinlichkeit nicht brauchen (der Sprungbefehl im MBR zeigt dann wieder auf den logischen Sektor, in dem die GRUB2-Datei im Dateisystem von /dev/sda2 beginnt).

"... On a BIOS/GPT configuration, a BIOS boot partition is required. GRUB embeds its core.img into this partition."

Quelle: https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_(GPT)_specific_instructions

???

Viele Grüße

susejunky

 

[Geier0815]

Das Rätsel ist gelöst bzw das Problem erledigt. Eine weitere Partition hatte das flag legacy_boot gesetzt. Der nächste Punkt war/ist das diese Konfiguration mit boot-Partition und MBR sich mit grub2-install offensichtlich nicht so einfach bauen läßt. Ich habe das bios_grub flag wieder auf off gesetzt und damit ist grub2-install auf die Nase geflogen, Fehlermeldung irgendwas mit "will not proceed with blocklists" (dieser Fehler war der ursprüngliche Grund bios_grub zu setzen). ABER über yast wird grub jetzt ohne Fehlermeldung und Probleme installiert/konfiguriert und das System bootet jetzt wieder ganz normal.

Danke an alle die sich an einer möglichen Problemlösung beteiligt haben!