[Almalexia]

Was läuft da eigentlich schief, wenn ich im UEFI den Boot-Manager händisch auswählen muss? Hat das Board einen Schaden oder der Boot-Manager?
Installiert ist ein Dual-Boot-System mit Windows 8.1 und Windows 10.

Board ist ein MSI X79GD45 Plus.

[foobar]

Ich bin mir nicht sicher, ob ich die Frage richtig verstehe, aber das klingt völlig normal. Bei UEFI-Boot muss man in der Mainboard-Firmware auswählen, welcher der hinterlegten Bootloader (es können ja mehrere sein) nun gestartet werden soll. Gehört zum Konzept. Jedes Betriebssystem legt seinen Bootloader in einer versteckten Partition auf der Platte ab und trägt ihn in der Firmware ein. Und Benutzer wählt dann, welchen er haben will.

Wenn du es klassisch haben willst, dass direkt ein im MBR hinterlegter Boot-Manager gestartet wird und du dort deine Auswahl triffst, brauchst du die alte BIOS-Bootmethode.

Siehe auch den Link in meiner Sig zum Thema UEFI- vs. BIOS-Boot.

[Almalexia]

Nein.
Es ist also normal, das der Computer in die EFI Shell bootet? Endweder kommt da ein toter Grub, weil ich da mal ein altes Linux installiert habe, oder die EFI Shell oder es hängt.

Es ist normal das ich das UEFI aufrufen muss und manuell den Bootloader auswählen muss? Weil das UEFI den Bootloader nicht findet? Normaler müsste Windows starten und da dürfte kein GRUB oder keine EFI Shell auftauchen.

Wenn ich F11 aufrufe um irgendwas zu booten, habe ich da nur die EFI Shell oder das UEFI. Erst wenn ich die Bootoptionen im UEFI aufrufe, erscheint da dann ein Windows Boot Manager.

[foobar]

Also normal kommt die EFI-Shell nur, wenn irgendwas schief läuft.

Zur Sicherheit mal eine kurze Zusammenfassung, wie die beiden Methoden eigentlich funktionieren.

BIOS-Boot

Im alten, früher üblichen Modus lädt das BIOS einfach die allerersten 442 Bytes von der Festplatte, als wären sie ein Programm, und führt sie aus. Die sind Teil des Master Boot Records (MBR), in dem auch die klassische Partitionstabelle steckt. Deren Job ist es dann, das restliche Betriebssystem zu laden. Wie sie das anstellen, interessiert das BIOS nicht weiter. Da man in 442 Byte nicht viel Code unterbringen kann und moderne Rechner etwas komplizierter sind als noch zu MS-DOS-Zeiten, gehen viele moderne Bootloader (wie z.B. Grub) her und parken dort nur das absolut notwendige (die sogenannte Stage 1). Die Stage 1 geht her und lädt die anderswo auf der Platte liegende Stage 1.5. Die befindet sich i.d.R. in der sogenannten MBR-Lücke, einem normalerweise nicht belegten Bereich der Platte zwischen dem Ende des MBR und dem Anfang der ersten Partition. Da ist genug Platz für zumindest einen Dateisystemtreiber, so dass die Stage 1.5 nun in der Lage ist, das Dateisystem der Linux-Partition und die dort befindliche Stage 2 zu laden. Die macht dann den ganzen Rest (weitere Dateisystemtreiber laden, Menü und ggf. Hintergrundbild malen, ausgewählten Kernel starten, und so weiter).

Weil es historisch gewachsen ist, ist die Lösung etwas kompliziert und es gibt Konflikpotential bei mehreren Betriebssystemen (es kann immer nur einen MBR geben), aber dafür das Verfahren steinalt, entsprechend erprobt und relativ robust.


UEFI-Boot

Beim UEFI-Boot gibt es eine versteckte Partition auf der Platte und dort kann jedes Betriebssystem seinen eigenen Bootloader hinterlegen. Man muss sich nicht mehr um den einen MBR zanken. Soweit noch ok. Das doofe ist nun, dass die UEFI-Firmware nicht einfach hergeht, diese Partition einliest und dann alle Bootloader (aka Betriebssysteme) anzeigt. Nein, das wäre ja zu einfach. Statt dessen muss jeder dieser Bootloader zusätzlich nochmal in der Firmware des Mainboards registriert werden. Und nur diese werden dann angezeigt. Es müssen also zwei verschiedene Dinge zusammen passen: Der Eintrag im Mainboard-Firmware-Speicher und die Bootloader auf der Festplatte. Ansonsten geht es nicht. Das heißt unter anderem eben auch, dass man nicht einfach eine funktionierende Platte in einen neuen Rechner einbauen oder mal eben das Mainboard tauschen kann, wenn es kaputt ist. Denn dann stimmen Firmware-Einträge und Bootloader ja nicht mehr zusammen. Die restlichen Nachteile sind u.a. hier im Spoiler beschrieben.


Was heißt das nun für dich?

Vermutlich stimmt bei dir die Firmware nicht mit den Bootloadern überein. Vielleicht, weil du dein Mainboard getauscht hast oder die Platte aus einem anderen Rechner stammt. Oder sonst irgendwas. Normalerweise müsste man die Einträge in der Firmware bearbeiten und prüfen können. Unter Linux geht das mit efibootmgr. Unter Windows mit bcdedit. Mit EasyUEFI gibt es auch eine grafische Lösung (hat AFAIK eine funktionell eingeschränkte Gratisversion). Alternativ kann man das Betriebssystem-Setup starten und von dort die Booteinträge reparieren lassen (müssten inzwischen alle Systeme draufhaben).

Oder halt einfach diesen UEFI-Scheiß vergessen und – solange es noch geht – weiter den BIOS-Bootmodus benutzen, der mir immer deutlich weniger Stress macht. Speziell, wenn man eh nur ein OS hat.

[Almalexia]

Ich glaube, Du verstehst mein Problem nicht.

Ich wiederhole mich: Ich habe ein Dual-Boot-System eingerichtet mit Windows 8.1 und Windows 10 Pro. So weit so gut. MBR-CSM bringt mir nichts, da Windows 8.1 und Windows 10 im UEFI-Modus installiert sind. Wozu soll ich CSM verwenden, wenn meine Betriebsystem eh mit UEFI umgehen können? Ich habe auch kein Mainboard getauscht. Wozu auch? Die SSD stammt auch nicht aus einem Rechner. Ich habe zwei SSDs eine Samsung 840 Evo und eine MX500. Von der Samsung habe ich das Windows 8.1 auf die MX500 rüber geklont und die alte SSD formatiert. Sobald das Betriebsystem geladen ist funktioniert der Rechner normal.

Mein Problem ist: Wenn ich neustarten will, dann kommt eben der GRUB-Mist, den ich irgendwie nie deinstalliert habe, weil es nicht nötig war oder die EFI Shell. Womit ich absolut nichts anfangen kann. Wenn ich aber in das UEFI gehe und in die Bootoptionen, kann ich den Windows Boot Manager auswählen. Das Problem ist: UEFI merkt sich das nicht und vergisst das nach einem Neustart wieder. Was definitiv nicht normal ist.

[Almalexia]

Es war der Windows Boot Manager der einen Schaden hatte. Ich habe den Windows Boot Manager neu geschrieben.

Das Ergebnis ist sehr überschaubar. Windows 8.1 lebt. Windows 10 ist tot.

Großartig.

[Almalexia]

Nun. Windows 8.1 lässt sich problemlos starten.

Aber wenn ich Windows 10 starten will, dann kommt 0xc0000001. Es fehlt irgendwas, was entfernt wurde. Aber was? Ich habe weder eine SSD abgesteckt noch eine HDD. Das versteh ich nicht. Was ich dann natürlich mache ist, vom USB-Stick zu booten und die Kommandozeile aufzurufen. Windows Starthilfe ist völlig überfordert und kann den Fehler nicht beheben... Ja, wie denn auch, wenn man schon den Boot Loader verhunzt. bootrec /fixmbr und /fixboot und dann startet er schon irgendwie.

Das kanns doch nicht sein. Ich habe Windows XP im Dualboot mit Vista gehabt. Mit Windows XP. Mit Windows 7. Sogar Windows 8.1 und XP. Natürlich mit eingeschalteten CSM ... aber bei meiner Mutter war es im Dualboot auch so lustig. Schießt Windows 10 einfach mal den Bootloader komplett ab. Ich durfte den dann wieder komplett neuerstellen.

EasyBCD war auch klasse. Lösch ich mir die BCD-Einträge raus. Zum Glück gibt es bootrec /rebuildbcd

Ist genauso der Witz warum der Computer in die EFI-Shell booten muss. Irgendwo wäre es doch sinnvoll, wenn er da automatisch in das UEFI-Einstellungsmenü bootet anstatt in die EFI-Shell. Ich kann noch erinnern, wie das vor UEFI war. Bitte legen sie ein bootbares Medium ein. Da startet der halt dann vom USB-Stick wenn er nix anderes findet. Mag sein das nur ich das Problem habe.

Ich weiß eh. Wie komme ich eigentlich auf die Wahnwitzige Idee ein Dualboot-System zu betreiben.

Warum frage ich hier nach einer Lösung? Weil mich das einfach nervt, bei jedem Neustart rumfrickeln zu müssen, das Windows 10 startet.