[gelöst] Installation versehentlich MBR bei UEFI Boot beschrieben

[willithepimp]

Hallo,
bei der Installation von Leap auf einem Rechner mit OS13.2 und Windows habe ich die Option Grub in den MBR schreiben aktiviert. Hab nicht dran gedacht, dass der Rechner mit UEFI und Secure Boot arbeitet. :-(

GNU GRUB version 2.02~beta2

Minimal BASH-like line editing is supported. For The first word, TAB lists possible command completions. Anywher else TAB lists possible device or file completions.

grub> _

Ich will nichts falsch und noch ne neue Installation machen. Daher meine Frage. Wie kann ich das reparieren. Gehe ich in das UEFI und aktiviere die SSD, auf der der MBR beschrieben wurde, startet das System normal.
1. Wie bekomme ich den MBR wieder "sauber"?
2. Was muss ich tun, um die Bootsequenz in die Bootpartition zu schreiben. Das mach ich doch über Yast? Jedenfalls habe ich da den Eintrag schon gefunden.
3. Windows hat es bei der Installation nicht erkannt. Wie trage ich das nachträglich ins Bootmenü ein?
Gruß

 

[Herz-von-Hessen]

Hallo willithepim,

bei der Installation von Leap auf einem Rechner mit OS13.2 und Windows habe ich die Option Grub in den MBR schreiben aktiviert. Hab nicht dran gedacht, dass der Rechner mit UEFI und Secure Boot arbeitet. :-(

Erstens hat das Secureboot keine Auswirkung darauf wo Dein Bootloader ist und zweitens ist auch UEFI kein Hindernis, denn sonst könntest Du ja nicht:

Gehe ich in das UEFI und aktiviere die SSD, auf der der MBR beschrieben wurde, startet das System normal.

booten.
Wenn es doch bootet, warum belässt Du es nicht wie es ist?

Wie kann ich das reparieren.

Du könntest, wenn Du das System gebootet hast, den Bootloader in den MBR der Festplatte installieren auf die zuerst zugegriffen wird.

1. Wie bekomme ich den MBR wieder "sauber"?

Den Teil des MBR in welchem der Bootloader untergebracht ist, zu leeren ist einfach:

dd if=/dev/zero of=/dev/sdX bs=446 count=1

Das X ist durch die richtige Devicekennung zu ersetzen.

2. Was muss ich tun, um die Bootsequenz in die Bootpartition zu schreiben. Das mach ich doch über Yast? Jedenfalls habe ich da den Eintrag schon gefunden.

Das kann man auch mit YAST machen, muss es aber nicht.

3. Windows hat es bei der Installation nicht erkannt. Wie trage ich das nachträglich ins Bootmenü ein?

mit grub2-mkconfig würde ich sagen.

Lieben Gruß aus Zuhaus

 

[josef-wien]

habe ich die Option Grub in den MBR schreiben aktiviert. Hab nicht dran gedacht, dass der Rechner mit UEFI und Secure Boot arbeitet.

Ich kenne die Installationsroutine von openSUSE nicht, aber ich habe das Gefühl, daß Du nicht im UEFI-Modus, sondern im BIOS-Modus installiert hast. In dem Fall kommt natürlich der "normale" GRUB2 zum Zug und nicht GRUB2-EFI. Daß GRUB2 ein im UEFI-Modus installiertes Windows nicht erkennen kann, wundert mich nicht. Bei Windows gibt es nur "entweder - oder", Linux kannst Du ohne weiteres sowohl im BIOS-Modus als auch im UEFI-Modus starten (sofern beides eingerichtet ist). Da ich mich mit GRUB2 nicht beschäftige, kann ich Dir aber nicht sagen, wie GRUB2-EFI nachträglich eingerichtet werden kann.

 

[uhelp]

Was für gefährliches Halbwissen!!
Wie tödlich die Ratschläge!!!

Den Teil des MBR in welchem der Bootloader untergebracht ist, zu leeren ist einfach:

dd if=/dev/zero of=/dev/sdX bs=446 count=1

Das ist zwar richtig, aber wird lediglich die komplette Verwaltungsinformation der jeweiligen Platte vernichten. Damit schreibt man schlicht Nullen auf die ersten 446 Bytes der Festplatte Nullen (mit LBA Adressierung). Da dort eine Partitionstabelle liegt, sind danach alle Partitionen auf dieser Platte weg. Das wiederherzustellen ist zwar möglich, aber nicht ganz so trivial.
MACH DAS NICHT!!!
Es ist unnötig.

Eine UEFI Maschine bootet mit UEFI. Man kann sie nicht auf "BIOS- Booten" umstellen.
Entweder IST die Hardware (U)EFI, oder nicht.
Diese Tatsache ist vielen nicht bewußt.
Ein UEFI Board kann aber die Möglichkeiten bieten, den Bootvorgang in einem Kompatibilibtätsmodus laufen zu lassen.
Das meinen wohl die meisten.

Der Bootvorgang selbst ist bei beiden Methoden sehr ähnlich.
Für einen echten UEFI SecureBoot ist eine GPT (GloballyuniqueidentifactionPartitionTable) erforderlich.
Diese Partitionstabelle kann 128 Einträge (und hat noch ein paar Verwaltungseinträge).
Der erste EIntrag IST eine MBR- Tabelle.
Die ist ein reiner Dummy, der nur dazu da ist, den Leuten, die mit gefährlichem Halbwissen daran rumdoktoren, die direkte Katastrophe zu ersparen.
Da muss niemand aufräumen, egal, was dort reingepfuscht wurde. Es wird nicht und nimmermehr gelesen, oder gar verwendet.

Da die Kiste bootet, ist alles gut.
Lediglich dem Bootmenu wäre noch Windows hinzuzufügen.

Und es ist sinnvoller bei UEFI Maschinen den Grub immer nach /boot zu installieren.
Macht das Leben leichter.
Meist genügt es mit YaST nocheinmal Grub nach /boot schreiben zu lassen, dann sollte sogar Windows im Menu auftauchen.
Geht das nicht, fehlt ein wenig Information.
Dann bitte komplette Partitionsbelegung ALLER Platten posten.

 

[josef-wien]

Was für gefährliches Halbwissen!!

Endlich ist da jemand mit realistischer Selbsterkenntnis.

Damit schreibt man schlicht Nullen auf die ersten 446 Bytes der Festplatte Nullen (mit LBA Adressierung). Da dort eine Partitionstabelle liegt, sind danach alle Partitionen auf dieser Platte weg.

Dein Wissen über den Aufbau des MBR ist äußerst mangelhaft; nach 440 Bytes für den Bootloader kommen 4 Bytes Disk-Signatur (seit Windows 2000) und 2 Bytes Nullen. Mehr will Herz-von-Hessen auch nicht löschen (auch wenn es unnötig ist).

Für einen echten UEFI SecureBoot ist eine GPT (GloballyuniqueidentifactionPartitionTable) erforderlich.

Dein Wissen über die UEFI-Spezifikation ist ebenfalls verbesserungswürdig; die Art der Parltitionentabelle ist ebenso belanglos wie die Position der EFI-Systempartition (auch wenn Windows wie üblich spezifikationswidrige Wege geht).

Es wird nicht und nimmermehr gelesen, oder gar verwendet.

Selbstverständlich wird der Boot-Code im MBR verarbeitet, wenn der

Kompatibilibtätsmodus

(unter "BIOS-Modus" können sich die Leute bloß mehr vorstellen) aktiviert ist.

 

[willithepimp]

Dank erst mal für Eure Hilfe. Ja, den MBR leer machen macht natürlich die Platte platt.
Die Installation von GRUB2 ist hier sehr hilfreich. Durch mein fälschliches Beschreiben des MBR in der Installationsroutine wurde der installiert. GRUB-EFI ist hier natürlich richtig und ich habe es umgestellt. Dennoch änderte sich nichts an der Lage. Lasse ich den Rechner normal starten, kommt statt dem Bootmenü immer noch der schwarze Bildschirm mit der Meldung (siehe auch oben):

GNU GRUB version 2.02~beta2

Minimal BASH-like line editing is supported. For The first word, TAB lists possible command completions. Anywher else TAB lists possible device or file completions.

grub> _

Das möchte ich gern durch das normale Bootmenü berichtigen.
Sonst muss ich bei jedem Start ins UEFI um die jeweilige Disk, bzw das Windows-Bootmenü anzuwählen. Funktioniert zwar, aber ist doch umständlich und nervig. :???:

 

[spoensche]

Eine UEFI Maschine bootet mit UEFI. Man kann sie nicht auf "BIOS- Booten" umstellen.
Entweder IST die Hardware (U)EFI, oder nicht.
Diese Tatsache ist vielen nicht bewußt.
Ein UEFI Board kann aber die Möglichkeiten bieten, den Bootvorgang in einem Kompatibilibtätsmodus laufen zu lassen.
Das meinen wohl die meisten.

Nö.

Hardware kann niemals eine Software sein ausser bei der Virtualisierung. Der Bios-Boot ist auch kein Kompatibilitätsmodus, da du für UEFI immer eine EFI Partition benötigst, in der der Bootloader installiert wird.

@willthepimp:

Wie sieht den dein Partitionlayout aus? Hast du eine EFI Partition? Hast du grub-efi nur installiert oder hast du auch den Bootloader vollständig neu schreiben lassen?

 

[Anonymous]

1. Wie bekomme ich den MBR wieder "sauber"?

Hi,
du kannst auch die GRUB2-Sicherungskopie im Verzeichnis /boot zurückschreiben. sdX ist an deine SSD anzupassen.

dd if=/boot/backup_mbr of=/dev/sdX bs=512

Ich kenne die Installationsroutine von openSUSE nicht, aber ich habe das Gefühl, daß Du nicht im UEFI-Modus, sondern im BIOS-Modus installiert hast. In dem Fall kommt natürlich der "normale" GRUB2 zum Zug und nicht GRUB2-EFI. Daß GRUB2 (im BIOS-Legacy-Modus, Anm. LUH 3417) ein im UEFI-Modus installiertes Windows nicht erkennen kann, wundert mich nicht..

Dem schließe ich mich an, und außer einer Neuinstallation fällt leider spontan nichts anderes ein. spoensche vielleicht.
Das wäre ja auch keine richtige Arbeit. Die fängt erst nach der Installation an.

 

[josef-wien]

du kannst auch die GRUB2-Sicherungskopie im Verzeichnis /boot zurückschreiben.

Welchen Zweck soll das erfüllen? Der Boot-Code im MBR paßt ja und startet 42.1 korrekt.

 

[Anonymous]

Welchen Zweck soll das erfüllen?

Einfach nur den alten Stand wiederherstellen.
Für UEFI-Boot ist evtl. vorhander MBR-Bootcode wahrscheinlich irrelevant, aber das kann ich nicht beweisen.

 

[uhelp]

**soifzzz**

Hardware kann niemals eine Software sein ausser bei der Virtualisierung.

Das ist schlicht total falsch.
Software und Hardware sind fast beliebig austauschbar.
Bei DOS1.0 musste man sich sogar zuerst die Com und Parallel Ports selbst kompilieren.
PFGAs gäbe es demnach auch nicht.
Tatsächlich wird meist neue Hardware erst gebaut, wenn sie bereits als Software implementiert worden ist.
Und auch der Rückweg ist möglich. Virtualisierung eben.

Der Bios-Boot ist auch kein Kompatibilitätsmodus, da du für UEFI immer eine EFI Partition benötigst, in der der Bootloader installiert wird.

Genau das, was ich sage: Es ist ein Kompatabilitätsmodus und eben kein "BIOS- Boot", was ich immer in Anführungszeichen setze, weil das Wort selbst schon irreführend ist.

@josef-wien Die Spezifikatio von UEFI selbst schreibt das natürlich nicht vor. Nach der könnte man auch vom Mars ohne jede Partitionierung booten.
Wenn man kann.

Nur durch Windows wurde es halt zum Standard.
Und es dürfte im SOHO Bereich kein einziges Board zu finden sein, das solche Implementierungen aufweist.
Außerdem habe ich nichts über die Struktur des MBR geschrieben. Der Effekt in der Realität reicht.
Möchtest du Aufführungen, die allen Specs und jeder Kunst entsprechen, schreibe ich dir gerne eine kleine 600-seitige Abhandlung über den Bootvorgant, so dass selbst du kein Argument mehr zusammenstöpseln kannst.

 

[Anonymous]

@uhelp
Fruchtbringender wäre, wenn du willithepimp hilfst, seine openSUSE-Installation von BIOS-Legacy-Boot nach UEFI-Boot umzubauen. Ehrlich.

 

[uhelp]

Ich habe schon geschrieben, was er als erstes probieren sollte.
Und welche Information benötigt wird, um weiterzuhelfen, wenn das immer noch nicht geht.
Gerne helfe ich weiter. Mit diesen Informationen

Oder wolltest du gar diesen Post an alle anderen adressieren?
Warum so einseitig?

 

[josef-wien]

das kann ich nicht beweisen

Mit dem Beweis wirst Du warten müssen, bis Du ein UEFI-Board hast. Im BIOS-Modus führt UEFI den Boot-Code im MBR aus, was es an Partitionen gibt, ist irrelevant, eine EFI-Systempartition muß nicht existieren. Im UEFI-Modus führt UEFI das im UEFI-Boot-Menü (das im NVRAM gespeichert ist und im "Rohzustand" das Programm \EFI\BOOT\BOOTX64.EFI ausführt) als 'standardmäßig zu starten' definierte Programm aus (und wo man übrigens Linux auch direkt, also ohne zwischengeschalteten Boot-Manager, starten kann), der MBR ist irrelevant.

Aber das Ganze ist zwar für die Nachwelt interessant, hilft aber willithepimp nicht. Die Aussage

bei der Installation von Leap auf einem Rechner mit OS13.2 und Windows

ist nicht eindeutig. Hast Du 42.1 zusätzlich zu 13.2 installiert? Wenn Du nämlich 13.2 durch 42.1 ersetzt hast, sind die Automatismen wohl nicht in der Lage, GRUB2-EFI einzurichten, da wird dann Handarbeit notwendig sein (bei der ich Dir aber bei GRUB2 nicht helfen kann). Funktioniert im anderen Fall der Start von 13.2?

 

[Anonymous]

Oder wolltest du gar diesen Post an alle anderen adressieren?

Nein. War an dich gerichtet und nett gemeint.

Mit dem Beweis wirst Du warten müssen, bis Du ein UEFI-Board hast.

Das DH87RL hat UEFI. Aber ich habe im Firmware-Setup UEFI-Boot normalerweise immer deaktiviert, weil es es nicht brauche.
Wenn ich BIOS-Legacy- und UEFI-Boot aktiviere, habe ich bei UEFI-Bootmedien immer zwei Einträge im DH87RL-Bootmenü.

Im UEFI-Modus führt UEFI das im UEFI-Boot-Menü (das im NVRAM gespeichert ist und im "Rohzustand" das Programm \EFI\BOOT\BOOTX64.EFI ausführt) als 'standardmäßig zu starten' definierte Programm aus (und wo man übrigens Linux auch direkt, also ohne zwischengeschalteten Boot-Manager, starten kann), der MBR ist irrelevant.

Aber das Ganze ist zwar für die Nachwelt interessant, hilft aber willithepimp nicht.

Danke. Und dabei belassen wir es hier auch, außer willithepimp fragt danach.

 

[willithepimp]

Hallo und Dank für all Eure Bemühungen. Aber ich denke, meinen Fehler muss ich wohl selbst ausbaden. Die (geringe) Hoffnung muss ich wohl in den Wind schreiben, durch geeignete Maßnahmen den MBR wieder zu bereinigen.
Meine Situation sei hier noch mal kurz dargestellt. Auf dem Rechner lief bereits im UEFI-Modus Windows 7 und Opensuse 13.2. Also nichts mit BIOS usw. Beides lief seit längerem tadellos. Ich habe bereits mehrere Rechner im UEFI-Modus aufgebaut. Ich weiß nicht was mich geritten hat, während der Installation von Leap den Bootlader von "MBR nicht beschreiben" in beschreiben zu ändern. Meine Dämlichkeit.
Update: Installationen mache ich über manuelle Partitionierung. Ich vergaß, die 100 MB für /boot/efi einzubinden. Deshalb wurde mir nur Grub2 angeboten und ich konnte den MBR beschreiben. :-( Ich fass es nicht!
Daher hab ich die Leap-Installation noch mal neu angeschoben. Jetzt sagt mir der Bootmanager während der Installation:

Nicht unterstüzte Kombination von Hardwareplattform x86_64 und Bootlader grub2-efi

Ich glaube mich zu erinnern, dass ich bei meiner ersten UEFI-Installation den Hinweis gefunden habe, dass bei allen im Rechner verbauten Hd / SSD der MBR leer sein muss. Sonst gibts Probleme. Und das dürfte hier der Fall sein.
Ich sehe also die Lösung meines Problems nur darin, den MBR und damit die ganze SSD platt zu machen und neu zu installieren bzw. die Images wieder aufzuspielen.
Falls noch jemand was besseres einfällt, sollte er es bis übermorgen kund tun. Dann ist es zu spät.
Gruß
willithepimp

 

[josef-wien]

Ich sehe also die Lösung meines Problems nur darin, den MBR und damit die ganze SSD platt zu machen

Das halte ich für übertrieben, 42.1 neu zu installieren muß reichen. Der MBR stört nicht, und daß sogar Windows trotz MBR startet, sollte Dir Beweis genug sein. Im übrigen bewirkt das "Plattmachen" nur des MBR lediglich, daß Du 42.1 nicht mehr starten kannst, die GPT ist davon nicht betroffen (und das UEFI-Boot-Menü ist ohnehin im NVRAM), d. h. Windows funktioniert immer noch.

Mitschuldig am Problem ist das fragwürdige "Design" von GRUB2-EFI, der seine Dateien auf zwei Partitionen verteilt. Der eine Teil auf der EFI-Systempartition stammt noch von Deiner 13.2-Installation (und führt derzeit "nur" zur Eingabeaufforderung von GRUB2-EFI), der andere Teil auf der openSUSE-Systempartition stammt von der Installation des Pakets "grub2-efi" von 42.1. Zwischen diesen beiden Teilen gibt es derzeit keine Verbindung, aber vielleicht findet sich noch ein GRUB2-Kundiger, der diese Verbindung herstellen kann. Nachtrag: Aber durch

Update:

scheint das wohl gegenstandslos zu sein.

 

[willithepimp]

Hallo,
@josef-wien
was hälst Du davon, in der Systembootsektion (FAT) einfach den Ordner samt Inhalt "opensuse" zu löschen und danach den Bootlader aus Leap oder OS13.2 neu zu installieren. Dann sollten doch die Unstimmigkeiten beseitigt werden?
Update
Bringt auch nichts. Hab den Opsensuse-Ordner entfernt und gesichert. Dann aus Opensuse Leap per Yast den Bootlader neu schreiben lassen. Danach (ohne Neustart) nochmal nachgesehen und musste feststellen, dass nur der Ordner microsoft vorhanden war. Inzwischen habe ich den opensuse-Ordner wieder zurück geschrieben.
Endlich hab ich gefunden, wie ich meinen Rechner bei der ersten UEFI-Installation herrichten musste. (Noch mal leerer MBR) Hier das Zitat mit dem Befehl:

Starte "CMD" als Administrator, an der Eingabe = Diskpart eingeben, "list disk" ausführen, die Platte auswählen, die gelöscht werden soll mit select disk x (X = Disknummer die bei list disk angezeigt wird, aufpassen das die richtige ausgewählt wurde), "clean all" eingeben und warten bis es fertig ist. Danach kannst Du unter Windows neu Partitionieren und formatieren.

Erst nachdem ich alle drei SSD's mit leeren MBR versehen hatte, lief die Installationen von Windows, OS 13.2 und Leap im UEFI Modus ab und funktioniert bis heute.
Gruß

 

[josef-wien]

Zur Verwendung von GRUB2 darfst Du mich nichts fragen. Ein Versuch kann nicht schaden, aber da Dein 42.1 derzeit ohne EFI-Unterstützung im Kernel startet, könnte sich die Automatik durchaus weigern, da sie keine Eintragung im UEFI-Boot-Menü vornehmen kann.

Wenn Dein UEFI über eine eingebaute EFI-Shell verfügt, kannst Du Kernel und initrd mit

cp /boot/vmlinuz /boot/efi/vmlinuz
cp /boot/initrd /boot/efi/initrd

auf die EFI-Systempartition kopieren und dann Linux über die EFI-Shell starten:

fs0:\vmlinuz ' initrd=\initrd '

Dann sollten die GRUB2-Automatismen funktionieren. Eine extern zur Verfügung zu stellende EFI-Shell kann ich Dir per Ferndiagnose nicht einrichten.

 

[willithepimp]

Hallo,
hier hatte ich meine ersten Erfahrungen mit UEFI zusammengefasst:
http://www.linux-club.de/forum/view...7&p=770429&hilit=erfahrungen+mit+uefi#p770429
Ich weiß nicht mehr, wo ich es gelesen hatte, aber ein sauberer MBR scheint zwingend notwendig zu sein. Daher denke ich, dass ich um das Plattmachen des MBR meiner SSD nicht herumkommen werde.
@josef-wien
Kommt mir grad ne Idee, wie ich Grub wieder aus dem MBR werfen könnte. Auf der betroffenen SSD ist am Ende eine Partition, die ich nicht brauche. Die könnte ich teilen oder in der Größe verändern. Damit würde doch der MBR neu mit der Partitionstabelle beschrieben? Oder liege ich hier falsch?
Gruß