Die Zahl der Computer, die noch das alte BIOS (oft auch „Legacy BIOS“ genannt) mit einem MBR (Master Boot Record) verwenden, geht zwar immer weiter zurück, weil neue Rechner hauptsächlich unter dem Druck von Microsoft seit Einführung von Windows 8 UEFI mit GPT nutzen. Aber es gibt immer noch Oldies, die nachhaltig ihren Dienst tun. Als Computer-Besitzer sollte man tunlichst wissen, mit welcher Bootmethode man es zu tun hat – spätestens dann, wenn das BIOS nach dem Einschalten steckenbleibt und kein Betriebssystem mehr startet. Da auf meinem betagten Zweit-Laptop Windows und Linux in mehreren Partitionen einer Platte koexistieren (sogenannter „Dual Boot“), habe ich alle möglichen Methoden für beide Welten durchgespielt und meine Erfahrungen hier aufgeschrieben.

Falls sich nun jemand wundert: Freiwillig habe ich das nicht getan. Dazu ist es nur gekommen, weil ich anstelle des altbekannten Ubuntu mal ein frisches, rollendes Arch Linux installieren wollte. Während nun aber der Ubiquity-Installer von Ubuntu bei mir niemals Boot-Probleme verursachte, ganz egal ob mit altem BIOS oder aktuellem UEFI, machte der Calamares-Installer der von mir verwendeten Distribution Garuda Linux Ärger. Klammer auf: Ja, vor der Installation wird man gewarnt („No EFI System Partition was found. This system will likely not be able to boot successfully …“); und ja, auch eine Installation neben Windows mag Garuda nicht „offiziell“ unterstützen. Also selber schuld. Klammer zu.

Nach Abschluss der Installation und Neustart des Computers bootete dann jedenfalls nichts mehr. Das BIOS meldete in plain English: „BootDevice Not Found“.

Wann immer ein solches Problem auftritt, ist die Diagnose klar: Wenn der PC vorher startete und nachher kein Betriebssystem mehr findet, und wenn nicht ausgerechnet in diesem Moment die Hardware das Zeitliche gesegnet hat, dann muss die letzte zuvor getätigte Amtshandlung den MBR zerschossen haben. Eine gute Nachricht gibt es immerhin: Die Daten sind in einem solchen Fall nicht weg. Sobald der Bootsektor repariert ist und der Rechner wieder startet, sollte alles wieder so sein, wie es vorher war. Ansonsten hat man ja auch noch Backups, nicht wahr?

Welche Methoden gibt es, den Bootsektor zu reparieren?

• Wer ein reines Windows-System betreibt, sollte den PC auch mit Windows-Bordmitteln reparieren. Da der Computer selbst nicht mehr das Windows auf der Festplatte booten will, nutzt man eine vorhandene Windows-DVD oder einen präparierten USB-Stick und startet den Computer von diesem Rettungsmedium.
• Auch mit einer Linux-Live-Umgebung, wie sie praktisch alle Distributionen zum Ausprobieren bereitstellen, lässt sich der Bootsektor reparieren. Hier hilft das Tool boot-repair, das diese Aufgabe sogar automatisiert erledigen kann. Aufwändiger ist es, sich per chroot in das nicht mehr startende Linux-System zu beamen und dort den Linux-eigenen Bootmanager Grub, der auch Windows booten kann, neu zu installieren.
• Schließlich gibt es eine Reihe von Festplatten-Managern (Paragon, Easeus etc.) und Boot-Disks, die eine automatische Reparatur von Systemstartproblemen versprechen. Spoiler: Das funktionierte in meinem Fall gar nicht und ich gehe im folgenden Text nicht weiter darauf ein.

Unter dem Strich habe ich beim Versuch, meinen Laptop wieder funktionstüchtig zu machen, nach dem „Versuch macht klug“-Prinzip nicht weniger als drei Anläufe unternehmen müssen, bis der Kollege Computer wieder startete. Wenn Ihr Rechner ähnliche Probleme macht, dann schaffen Sie es nach dieser Lektüre wahrscheinlich schneller, weil Sie nicht alles ausprobieren müssen.

Methode 1: Das Linux-Tool boot-repair einfach machen lassen

Da ich mir meinem Laptop mit einer Linux-Installation zerschossen hatte, war mein erster Gedanke, den MBR von einer Linux-Live-CD zu reparieren. Eine schnelle, automatisierte Problemlösung verspricht das Tool boot-repair. Sie können es sich direkt beim Entwickler als Disk-Image besorgen oder Sie installieren es in einem vorhandenen Live-Image von Ubuntu über ein direkt vom Entwickler bereitgestelltes PPA. Die Installation geht in letzterem Fall so:

sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install boot-repair

Starten Sie das Tool mit „boot-repair“, und es erscheint eine einfache GUI (grafische Benutzeroberfläche), in der Sie per Klick auf „Recommended Repair“ das System ganz einfach reparieren lassen können.

In meinem Fall war das allerdings doch nicht so einfach, denn nach dem Herunterfahren und Entfernen des USB-Sticks mit dem Live-Linux startete nach dem Wiedereinschalten immer noch – nichts.

Methode 2: Per chroot den Bootmanager Grub reparieren

Der quasi amtliche Bootmanager in Linux ist Grub, und wenn das System nicht mehr bootet, liegt es nahe, Grub einfach neu zu installieren. Also habe ich erneut den Computer vom Stick mit dem Live-Linux gestartet und darin eine chroot-Umgebung eingerichtet, um von außen in das nicht mehr startende Linux-System auf der Platte hineinzugreifen (chroot steht für „change root“). Zunächst muss bekannt sein, auf welcher Partition sich das Root-Filesystem von Linux überhaupt befindet. Wer das nicht weiß, findet es mit Festplatten-Tools wie gparted (grafisch) oder im Terminal mit fdisk -l heraus. In meinem Fall lag die Linux-Partition auf sda5. Also habe ich in der Konsole zunächst diese Partition in mein Live-System eingehängt („gemountet“):

sudo mount /dev/sda5 /mnt

Wird eine separate Boot-Partition genutzt, so muss diese zusätzlich nach /mnt/boot eingehängt werden.

Da das von mir zuvor installierte Garuda-Linux allerdings das Dateisystem Btrfs nutzt, das wiederum Subvolumes verwendet, muss man das Kommando entsprechend anpassen. Das Subvolume @ verweist auf das Root-Verzeichnis:

sudo mount -o subvol=@ /dev/sda5 /mnt

Handelt es sich um eine verschlüsselte Partition mit Luks – im Beispiel heißt sie Linuxsystem -, entschlüsselt man sie zunächst mit der Passphrase und mountet sie dann:

sudo cryptsetup luksOpen /dev/sda5 Linuxsystem
sudo mount -o subvol=@ /dev/mapper/Linuxsystem /mnt

Als nächstes leiht man sich noch die für ein funktionierendes System notwendigen Verzeichnisse proc und dev aus dem Live-System aus und beamt sich schließlich per chroot in das System auf der Platte hinein:

sudo mount -t proc /proc /mnt/proc
sudo mount -o bind /dev /mnt/dev
sudo chroot /mnt

Einmal per chroot drin, braucht man nun nur noch eine Neuinstallation von Grub auf der gewünschten Festplatte anzustoßen. Dies ist in meinem Fall sda – man verzichtet hier bewusst auf eine Partitionsnummer, da Grub direkt im Bootsektor am Anfang der Festplatte installiert werden soll und nicht auf einer der dahinter liegenden Partitionen. Noch einmal: Wir reden hier von einem System mit Legacy-Bios und MBR. Auf modernen UEFI-Systemen wird dagegen von einer speziellen efi-Partition gebootet!

grub-install /dev/sda

Grub sucht anschließend selbst nach Betriebssystemen auf allen Partitionen und erstellt mit diesen Informationen ein Bootmenü. Bei einem Dual-Boot-System werden also Einträge sowohl für Linux als auch für Windows erzeugt. Grub ist dabei nicht sektiererisch, aber doch so patriotisch, dass er Linux automatisch starten wird, sofern man nicht einen anderen Booteintrag auswählt.

Leider wurde auch nach dieser schrittweisen Auffrischung von Grub beim Neustart des Rechners kein System gefunden. Ich hatte zwar das Gefühl, irgendetwas übersehen zu haben, aber da ich mit Linux nicht weiterkam, versuchte ich mein Glück nun mit Windows.

Methode 3: Reparatur mit einer Windows-DVD

Windows auf DVD gibt’s heutzutage immer seltener – man muss sich zur Not also eines mit dem Media Creation Tool erstellen oder ganz auf eine per PE-Builder selbstgebaute Rettungsumgebung zurückgreifen. In meinem Fall tat es auch noch eine alte Windows 8 DVD, obwohl sich auf der Platte bereits Windows 10 befand. Nach dem Systemstart von der DVD wählt man statt einer Neuinstallation die „Computerreparaturoptionen“ aus und hangelt sich über „Problembehandlung“ und „Erweiterte Optionen“ zur „Eingabeaufforderung“ durch. Dort helfen folgende Befehle weiter, die man nach dem Motto „viel hilft viel“ auch alle nacheinander ausführen kann:

bootrec /fixmbr
bootrec /fixboot

Mit fixmbr wird der Master Boot Record neu geschrieben, mit fixboot der gesamte Bootsektor (Details auf der Microsoft Supportseite). In meinem Fall wurde fixmbr klaglos quittiert, während fixboot eine Fehlermeldung produzierte: „Element nicht gefunden“. So lapidar dieser Kommentar war, brachte er mich doch auf die Lösung. Alle Versuche, den Bootloader neu zu schreiben und das System damit neuzustarten, waren offensichtlich nicht ausreichend, weil der Calamares-Installer von Garuda-Linux das Boot-Flag für die aktive Partition entfernt hatte. Also konnte ja gar nichts booten.

Aktive Partition unter Windows ermitteln/setzen

Da ich mich nun schon auf einer Windows-Eingabeaufforderung befand, startete ich Microsofts hauseigenes Kommandozeilen-Werkzeug diskpart, um zu prüfen, ob tatsächlich keine aktive Partition gesetzt war:

X:\Sources>diskpart
[…]
DISKPART>list volumes
[…]
DISKPART>select volume 1
[…]
DISKPART>detail partition
[…]

Wie man sieht, startet nach dem Aufruf von Diskpart eine interaktive Shell, in die man Kommandos eintippen darf. Zunächst lässt man sich alle Volumes (das entspricht Partitionen) anzeigen, um die Nummern herauszufinden. Dann wählt man mit select die Partition aus, die aktiv sein soll – üblicherweise die mit dem Windows Laufwerksbuchstaben C: -, und schließlich schaut man sich die Partition im Detail an.

In meinem Fall bestätigte sich der Verdacht: In der Ausgabe des letzten Befehls stand „Aktiv: nein“.

In diesem Fall setzt das Kommando

DISKPART>active

die zuvor ausgewählte Partition – hier also das Volume 1 – wieder aktiv. Und siehe da: danach bootete Windows wieder – Linux allerdings erwartungsgemäß noch nicht, denn der zuvor via bootrec installierte Windows-Bootmanager mag kein Linux, weshalb man auf Dual-Boot-Systemen wieder zu Methode 2 greifen sollte, um mit Grub erneut einen Dual Boot einzurichten.

Bootable flag unter Linux prüfen/setzen

Natürlich lässt sich eine Partition auch unter Linux aktivieren, und zwar mit einem der in Methode 2 genannten Partitionierungs-Werkzeuge. Exemplarisch hier der Umgang mit fdisk auf der Kommandozeile:

fdisk /dev/sda
[…]
Befehl (m für Hilfe): a
Partition number (1-5): 1
Die Bootfähig-Markierung auf Partition 1 ist nun aktiviert.
Befehl (m für Hilfe): w
Die Partitionstabelle wurde verändert.
Festplatten werden synchronisiert.

Zunächst wird fdisk mit der gewünschten Platte – hier im Beispiel sda – als Argument gestartet. Dann gibt man im interaktiven Frage-/Antwortspiel den Befehl „a“ wie aktiv und die Partitionsnummer – hier 1 für sda1 – ein. Bis dahin ist noch nichts passiert. Erst der Befehl „w“ wie write schreibt die Änderung in die Partitionstabelle im Bootsektor.

Fazit: Welche Methode ist die beste?

Viele Wege führen zur erfolgreichen Reparatur eines defekten Boot-Sektors. Wer ein Windows-System betreibt, sollte zu Windows-Mitteln (Methode 3) greifen. Unter Linux kann man es automatisiert (Methode 1) oder auch ganz klassisch (Methode 2) probieren. Auf Dual-Boot-Systemen ist Linux die erste Wahl, weil Grub sowohl Windows als auch Linux booten kann, während der Windows-Bootloader Linux rauswirft. Ja, auf Systemen mit Legacy-BIOS kann man auch den Windows-Bootloader dazu bringen, dass er Grub bootet, welcher dann wiederum Linux startet, aber das wäre doch doppelt gemoppelt. Vorbedingung für jeden erfolgreichen Systemstart ist aber eine aktive Partition mit Boot-Flag, und zwar genau eine. Sonst bootet gar nichts – wie ich schmerzhaft erfahren durfte.