Leserartikel Linux manipuliert Bootrec-Einträge bei Installation

Es geht um das Thema, wie verhält sich Linux, wenn bereits am ersten Datenträger bereits ein Windows installiert vorliegt, und man Linux auf einem separaten Datenträger installieren möchte.

Nachdem man wieder mal hier ungerechtfertigt angegangen wird mit falschen Behauptungen, siehe M2 SSD vor Linux Installation deaktivieren, und die Diskussionen immer wieder mit Halbwahrheiten und Falschbehauptungen gespickt werden, habe ich mir mal 2 Tage Zeit genommen, meinen Spielerechner dafür auseinandergenommen, um Fakten zu präsentieren. Die Diskussion ist schon älter und zieht sich durch diverse andere Themen, siehe auch
https://www.computerbase.de/forum/t...hr-zurueck-ins-windows.2049127/#post-26183250
https://www.computerbase.de/forum/t...nux-mich-wollen.1960849/page-11#post-25785006
https://www.computerbase.de/forum/t...o-die-erfahrung.2097248/page-35#post-27170098
https://www.computerbase.de/forum/t...nux-mich-wollen.1960849/page-10#post-25781690

und die Antworten danach. Tatsache ist, daß immer wieder nach diversen Linux Installationen Probleme auftauchen, siehe auch hier

Linux Mint & Windows - Windowspartition/Festplatte lässt sich nicht mehr als Bootplatte wählen
Windows 10 Dual Boot mit Fedora
Nach Pop!_Os Installation kann ich nicht mehr zurück ins Windows
'Grub vermutlich auf falscher Partition?

Doch kaum einer stellt es mal konkret nach, und es werden nach wie vor Dinge behauptet, die so nicht stimmen. Und ich bitte die Mods hier ein besonderes Auge darauf zu haben, daß bitte die Diskussionen sachlich bleiben und es nicht von Anfeindungen und falschen Behauptungen überhäuft wird. Eventuelle Fehler bitte ich aufgrund der Zeitnot zu entschuldigen, da ich ab morgen wieder unterwegs bin und regulär arbeiten muß. Ebenso sind meine Erkenntnisse natürlich nicht der Weisheit letzter Spruch oder gar als absolut zu sehen, es sind meine Erkenntnisse, die ich hier hoffentlich nachvollziehbar wie transparent dargestellt habe. Es können gerne Ergänzungen und Erwiderungen hinzugefügt werden, vorausgesetzt, sie sind nachvollziehbar und belegbar dokumentiert.

Ich habe es mir erlaubt, gerade auch als Hilfestellung für künftige Hilfesuchende, die Sache mal genauer zu beleuchten und ausführlicher zu dokumentieren. Dabei habe ich selbstverständlich in Rahmen meiner Kenntnisse und Möglichkeiten mehrere verschiedene Varianten und Wiederholungen getestet, ob das Ergebnis auch wirklich nachvollziehbar ist.

Testszenario

Testsystem

• Intel Core i9-12900k
• Asus ROG STRIX Z690-F GAMING WIFI (Bios aktuell 1720
• 32 GB Ram
• Samsung 950 Pro NVMe SSD für Windows GPT
• Samsung 850 Pro 1TB 2,5" SSD für Linux GPT

Verwendete Software und Programme

• Windows 11 21H2 auf NMVe SSD Samsung 950 Pro
• Linux
  • ubuntu-21.10-desktop-amd64.iso
  • ubuntu-22.04.1-desktop-amd64.iso
  • debian-11.4.0-amd64-DVD-1.iso
  • CentOS-Stream-8-x86_64-20220816-dvd1.iso
• Ventoy ventoy-1.0.79 für ein Multi Boot Stick
• Paragon Festplattenmanager Pro 17
• EasyBCD
• Visual BCD
• Windows Powershell
  • Diskpart
• Linux Shell

Vorgehensweise

Es wird ein neues Windows 11 auf der NVME Samsung 950 Pro installiert. Danach werden testweise verschiedene Linux-Derivate auf dem 2.Datenträger Samsung 850 Pro (bereits als GPT vorbereitet) installiert, welches dann hier dokumentiert wird. So sieht die Datenträgerverwaltung vor der Linux-Installation aus:

Nach jeder Installation wird der Datenträger 0 für Linux wieder komplett geleert, und alle Überreste von Datenträger 1 wieder auf vorherigen Stand gebracht, sei es per Diskpart, Sicherung der BCDs per EasyBCD und VisualBCD, Entfernen von Grub auf EFI Partition Datenträger 1 usw.
Ansicht mit EasyBCD vor der Installation

Ansicht mit Visual BCD

Installation von Ubuntu

Ich gehe die Installation so durch, so wie sie jeder Linux Anfänger oder normale Anwender durchgehen würde. Hier verwende ich die aktuelle Version Ubuntu 22.04.1 Desktop Amd64, die ältere Version 21.10 verhält sich hier identisch.

Da die Samsung 850 am ersten SATA0 (SATA6G_1 Port des Mainboards hängt, wird sie als /dev/sda von Ubuntu angesprochen

Geht man über den anderen Weg Etwas anderes, kann man das hier sehen:

Variante ist, eine EFI Partition manuell vorher anzulegen, ebenso die Root Partition:

Im Endergebnis spielt es aber keine Rolle. Weiterhin spielt es KEINE ROLLE, ob man den Datenträger vorher im BIOS Bootmenü deaktiviert oder nicht. Wenn, dann muß man hart den entsprechend verwendeten SATA Port im BIOS auf disable schalten. Für NVMe SSDs habe ich im BIOS diesbezüglich keine Möglichkeit gefunden, das zu tun.

Ergebnis der Installation

Es wird bei Ubuntu wie bei Debian IMMER ein Grub Eintrag in die Windows EFI Partition eingetragen! Im BIOS verweisen beide Einträge auf die Windows EFI Partition auf dem Windows Datenträger Samsung 950 Pro.

Hier einmal direkt über Linux Terminal als Root Benutzer:

EasyBCD kann das nicht darstellen, aber Visual BCD erkennt den neuen Eintrag und das ApplicationDevice - \Device\Harddisk\Volume1 änderte sich auf \Device\Harddisk\Volume2

Im Loader ist Ubuntu nun eingetragen

Nur CentOS 8 Stream installiert alles brav auf dem Datenträger, welchen man im Installer eingetragen hatte. Bei Ubuntu spielt es keine Rolle.

Seltsamerweise wird aber von jedem Installer auf dem neuen leere Datenträger 0 immer eine eigene EFI Partition angelegt:

Grub unter Windows entfernen

Damit man Grub wieder los wird, startet man diskpart mit der Powershell oder Eingabeaufforderung als Administrator, lokalisiert die EFI Partition und weist dieser einen Laufwerksbuchstaben (hier X:\) zu.

Spoiler: Textvariante für Cut&Paste EFI Partition Buchstabe zuweisen

PS C:\> diskpart Microsoft DiskPart-Version 10.0.22000.1 Copyright (C) Microsoft Corporation. Auf Computer: DESKTOP-H7CPG8E DISKPART> list disk Datenträger ### Status Größe Frei Dyn GPT --------------- ------------- ------- ------- --- --- Datenträger 0 Online 953 GB 0 B * Datenträger 1 Online 476 GB 1024 KB * DISKPART> select disk 1 Datenträger 1 ist jetzt der gewählte Datenträger. DISKPART> list vol Volume ### Bst Bezeichnung DS Typ Größe Status Info ---------- --- ----------- ----- ---------- ------- --------- -------- Volume 0 FAT32 Partition 512 MB Fehlerfre Versteck Volume 1 C NTFS Partition 476 GB Fehlerfre Startpar Volume 2 FAT32 Partition 100 MB Fehlerfre System Volume 3 NTFS Partition 609 MB Fehlerfre Versteck DISKPART> select volume 2 Volume 2 ist jetzt das gewählte Volume. DISKPART> assign letter=x Der Laufwerkbuchstabe oder der Bereitstellungspunkt wurde zugewiesen. DISKPART>

Danach kann man wiederum als Adminstrator in der Powershell wie Eingabeaufforderung im Verzeichnis EFI den Ubuntu-Eintrag löschen:

Spoiler: Textvariante für Cut&Paste löschen Grub in EFI

PS C:\> x: PS X:\> dir Verzeichnis: X:\ Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 30.08.2022 13:13 EFI PS X:\> cd EFI PS X:\EFI> dir Verzeichnis: X:\EFI Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 29.08.2022 18:34 Microsoft d----- 30.08.2022 11:53 Boot d----- 30.08.2022 13:13 ubuntu PS X:\EFI> rmdir ubuntu Bestätigung Das Element unter "X:\EFI\ubuntu" verfügt über untergeordnete Elemente, und der Recurse-Parameter wurde nicht angegeben. Wenn Sie fortfahren, werden mit dem Element auch alle untergeordneten Elemente entfernt. Möchten Sie den Vorgang wirklich fortsetzen? [J] Ja [A] Ja, alle [N] Nein [K] Nein, keine [H] Anhalten [?] Hilfe (Standard ist "J"):J PS X:\EFI> dir Verzeichnis: X:\EFI Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 29.08.2022 18:34 Microsoft d----- 30.08.2022 11:53 Boot PS X:\EFI>

Löschen unter Linux kann man oben als Screenshot ersehen. Hier einfach die EFI Partition mounten bzw. als Laufwerk verfügbar machen, danach kann man als root Benutzer auf dieses Verzeichnis ebenso direkt zugreifen und den Grub Eintrag löschen.

Fazit

Wie man hier (un)schön erkennen kann, Ubuntu wie Debian schreiben ungefragt in die Bootrec Einträge der Windows-Partition in die EFI Partition. Dabei spielt es keine Rolle, ob man die einfache Installation wählt, oder sogar manuell (wie hier behauptet wurde) vorgeht, indem man die EFI Partition wie die Root-Partition von Hand anlegt. Die vorherigen CentOS Versionen machten das auch nicht korrekt, aber CentOS 8 Stream läßt als einzige Linux Distrubution die Finger von der Windows Partition, so wie es sein soll. Andere Linux Distributionen, die auf Debian basieren, und damit auch Ubuntu, PopOS und Co., haben diese "Problem", seit Jahrzehnten. Das SATA0 als Startpunkt des BIOS bis heute für Laufwerke gilt, hatte ich hier bereits mal ausgeführt. Eigentlich sollte das mit EFI diese Dinge obsolet sein.

Das spiegelt auch meine Erfahrungen in all den Jahren mit Linux wieder, und man kann jetzt hier diskutieren, ob das nun ein Bug oder ein Feature ist. Tatsache ist, daß dieses Problem bis heute immer wieder auftritt, sobald ein primäres Windows auf einem Laufwerk vorhanden ist. Effekte sind davon, daß gar nichts mehr bootet, oder der Windows Boot nicht mehr möglich ist, weil die Bootrec zerschossen wurde. In meinen Tests ist das gestern wie heute auch 2 mal passiert, warum auch immer. Hier hilft dann nur den Bootmanager mit Windows Mitteln zu reparieren, siehe auch:
Heise - Windows 10: Bootmanager reparieren - so geht's
Deskmodder - Bootmenü reparieren wiederherstellen Windows 11 und 10

Um fair zu bleiben, anscheinend macht Windows das gleiche, wenn Linux als Erstinstallation vorhanden ist. Wer sich nicht sicher ist, sollte daher bei einer Linux Neuinstallation den Windows Datenträger deaktivieren oder entfernen.

Ich bitte um Verständnis, daß ich nun nicht weiter jede andere Linux Distribution testen werde. Für diesen "kleinen Test" habe ich hier auch 2 volle Tage verbraten.

 

[Garmor]

Es ging doch darum, dass Ubiquity eine eigene EFI-Partition anlegt und diese auch als Ziel für den Bootloader auswählen lässt, aber den Eintrag dann in eine andere EFI-Partition packt. Dann ist es schön, dass es zwar trotzdem funktioniert, aber es ist nicht das intendierte Verhalten.

 

[Beelzebot]

Naja, man sagt dem System ja auch nie "Nutz gefälligst die aktuell erstellte EFI-Partition!", sondern man erstellt sie bloß...
Macht man das manuell, wie unter Arch, kommt dieses Problem nicht zustande, weil man die erstellte Partition selber unter /mnt/efi einhängt. Das ist also eher ein Problem der KlickiBunti-Installer.
Und nachdem was ich so lese, soll es ja auch genauso sein, denn sowohl Linux als auch Windows handhaben das so.

 

[Evil E-Lex]

Es ging doch darum, dass Ubiquity eine eigene EFI-Partition anlegt und diese auch als Ziel für den Bootloader auswählen lässt, aber den Eintrag dann in eine andere EFI-Partition packt. Dann ist es schön, dass es zwar trotzdem funktioniert, aber es ist nicht das intendierte Verhalten.

So ist es. Mir scheint, als würde der Eintrag "Festplatte löschen" im Installer davon ausgehen, als wäre nur eine Festplatte im System verbaut. Daher die zusätzlich angelegte ESP. Das erklärt aber natürlich nicht, warum dann stattdessen die bereits existierende ESP genutzt wird.
Ich habe versucht eine Erklärung dafür in der Ubuntu bzw. Debian-Installer Dokumentation zu finden. Die gibt es natürlich nicht, weil die Doku Debian- und Ubuntutypisch katastrophal schlecht ist. Themen wie UEFI werden im Installation Guide für Ubuntu 20.04 nur mit allgemeinem Blah Blah behandelt. Dafür steht dort 90% unnützer Mist drin.
Technische Dokumentation für den Ubuntu-Installer im Sinne von "was passiert wenn dieser Button geklickt wird" existiert schlicht nicht. Ich hab sogar versucht im Quellcode von Ubiquity etwas zu finden, war aber erfolglos.

 

[Garmor]

Naja, man sagt dem System ja auch nie "Nutz gefälligst die aktuell erstellte EFI-Partition!", sondern man erstellt sie bloß...

Aber man kann ja wie oben zu sehen ein Device für den Bootloader angeben. Das impliziert ja schon irgendwie, dass dann eine bestimmte ESP präferiert werden sollte.

 

[NedFlanders]

Bin zwar Linux only User, aber Danke an PHuV für die ganze Arbeit. 👍

 

[riversource]

Ok, die zusätzliche EFI Partition wäre natürlich nicht nötig. Aber wenn ich den TE richtig verstanden habe, dann ging es um die Boot Einträge im NVRAM. Und da verhält sich Ubuntu meines Erachtens nicht falsch.

 

[Evil E-Lex]

Nicht falsch, aber inkonsistent. Die Erwartung ist:
Eigene ESP -> Diese nutzen, samt Eintrag im UEFI.
Fremde ESP -> Diese nutzen, samt Eintrag im UEFI und keine eigene ESP erzeugen.

Aber definitiv nicht:
Fremde ESP -> Diese nutzen, samt Eintrag im UEFI und trotzdem eine eigene ESP erzeugen.

Das ist zwar nicht weiter tragisch, da die eigene ESP schlicht ignoriert wird, aber dennoch unsauber.

 

[riversource]

Aber um die ESP geht es im Eröffnungspost doch gar nicht. Das habt ihr doch erst im Laufe des Threads eingebracht. Es ging um die Einträge ins NVRAM und darum, dass nach einer Linux Installation Windows angeblich nicht mehr bootet. Aber sowohl die Nutzung des ESP als auch die Einträge ins NVRAM sind ok.

Davon unabhängig ist das Anlegen der unnötigen ESP Partition. Ok, das ist unsauber. Aber vollkommen irrelevant für die ursprüngliche Fragestellung.

 

[PHuV]

Der "normale" Anwender oder Einsteiger wählt die Standardeinstellungen. Also "Normale Installation" statt "Minimal" und "Ubuntu neben Windows installieren" und nicht "Festplatte löschen".

Da kannst Du aber den Datenträger leider nicht weiter wählen und bestimmen.

Ergänzung (31. August 2022)

Warum sollte man/ich das tun?

Du gibst dir viel Mühe zu behaupten nach einer normalen Dualbootinstallation bootet Windows nicht mehr. Und das stimmt eben nicht!

Dann bilden sich die Hilfesuchenden in meinen angegebenen Link oben das alles nur ein? Und mit einer älteren Ubuntu Version ist genau das passiert.

https://www.computerbase.de/forum/t...nux-mich-wollen.1960849/page-10#post-25781690

Aus genau dem Grund hast du so viel Pfeffer geerntet in dem anderen Thread. Andernfalls wäre ich und alle die nun mal die Erfahrung gemacht haben, dass eine Standardisierte Dualboot Installation schlicht und ergreifend funktioniert, ziemliche Phantasten. Empirisch betrachtet nicht sehr realistisch.

Siehe genannte Themen der Hilfrésuchenden. Hier wieder ein aktuelles Beispiel:
https://www.computerbase.de/forum/t...o-die-erfahrung.2097248/page-59#post-27241977
Wer das noch als Phantasten bezeichnen mag, ist dann wohl eher selbst einer. Wie gesagt, in meinen Test ist es 2-3 mal vorgekommen, das gar nichts gebootet wurde, und man nur durch Reparatur weiter kam. Auch nur Einbildung?

 

[Nowareeng]

Siehe genannte Themen der Hilfrésuchenden. Hier wieder ein aktuelles Beispiel:
https://www.computerbase.de/forum/t...o-die-erfahrung.2097248/page-59#post-27241977
Wer das noch als Phantasten bezeichnen mag, ist dann wohl eher selbst einer. Wie gesagt, in meinen Test ist es 2-3 mal vorgekommen, das gar nichts gebootet wurde, und man nur durch Reparatur weiter kam. Auch nur Einbildung?

Will jetzt nichts schönreden aber da war ein Bug im Grub vom EndeavourOS dran Schuld....
Im Reddit link wurde gesagt man hat den Bug, der nicht oft auftrat, übersehen da nicht viele Tester Grub nutzen...(ok , was dann?)....und es ging iw um einen mehr oder weniger speziellen Laptop,....
mMn ein Grund mehr bei Xubuntu zu bleiben...ein paar PPAs eintragen ist kein Problem....

 

[Kuristina]

da nicht viele Tester Grub nutzen...(ok , was dann?)

Ich hatte am Anfang auch Grub, wo ich noch kein UEFI Boot hatte. Aber mit UEFI bin ich zum systemd-boot gewechselt. Den werden viele haben.

Mein System ist auch vollverschlüsselt, also Passwortabfrage noch vor dem Booten. Das war mit systemd problemlos. Ich weiß gar nicht, ob das mit Grub auch geht.

 

[Evil E-Lex]

Aber um die ESP geht es im Eröffnungspost doch gar nicht. Das habt ihr doch erst im Laufe des Threads eingebracht.

Richtig. Es zeigt aber, wie unsauber der Installer im automatischen Modus arbeitet.

 

[@mo]

@PHuV

Nope, alle Linuxe verändert auf dem Primärdatenträger immer den Bootblock, und Du darfst nach der Installation reparieren. Es hilf nur NVME SSD vorher ausbauen.

Das war dein Posting im anderen Thread, weswegen du ziemlichen Ärger bekommen hast und nun den hier zur eigenen Rechtfertigung eröffnet hast.
Da das nachweislich falsch ist, andernfalls müssten alle, die hier andere Erfahrungen gemacht haben absichtlich Blödsinn erzählen, macht es wenig Sinn sich hier im Kreis zu drehen, solange du das nicht wenigstens relativiert.

Support kann nicht sein, stur auf seiner Meinung zu beharren gegen besseres Wissen zahlreicher anderer Anwender.

 

[Garmor]

Richtig. Es zeigt aber, wie unsauber der Installer im automatischen Modus arbeitet.

Da fällt mir wieder ein: bei Linux Mint wird oder wurde bei einer MBR-Installation auch eine EFI-Partition erstellt.

 

[riversource]

Richtig. Es zeigt aber, wie unsauber der Installer im automatischen Modus arbeitet.

Was aber immer noch nichts daran ändert, dass es hier komplett offtopic ist.

Ich glaube, hier gehen einige Dinge durcheinander. Im Grunde ging es doch am Anfang darum, dass Systeme nach der Installation eines Linux nicht mehr booten, weil angeblich Bootloader oder Bootblocks oder sowas überschrieben werden. Jetzt plötzlich werden Beispiele herangezogen, wo Updates den Bootvorgang stören, was nachweislich auf einen Bug zurückzuführen war. Über das unnötige EFI Partitionsthema brauchen wir wohl erst recht nicht mehr zu diskutieren. Das ist unschön, aber letztlich kein Problem.

Grundsätzlich kann man wohl festhalten, dass Linux bei der Installation nicht einfach irgendwelche Bootblocks überschreibt. Das liegt vor allem daran, dass es diesen Bootblock bei EFI Installationen gar nicht mehr gibt. Was Linux allerdings macht: Es schreibt seine Bootloader - sei es grub oder systemd-boot oder was anderes - in eine ggf. vorhandene primäre EFI Partition und fügt einen entsprechenden NVRAM Eintrag hinzu. Diesen Eintrag setzt es auch gerne mal an die erste Stelle, so dass nach der Linux Installation auch Linux bootet, und nicht mehr Windows. Wenn man dann grub so einstellt, dass der os-prober nicht losläuft, dann kommt auch kein Grub Bootmenu, und der unerfahrene Nutzer mag glauben, dass er Windows nicht mehr booten kann. Geht natürlich trotzdem immer noch - ggf. über die Änderung der Boot-Reihenfolge im UEFI oder über das UEFI Bootmenu. Der Windows Bootmanager und auch die entsprechenden NVRAM Einträge sind nicht weg.

Unabhängig davon sind Probleme, die durch irgendwelche Updates ausgelöst werden. Den von EndeavourOS hatten wir gerade. Für Gesprächsstoff sorgte auch das Windows Update von vor 2 Wochen, dass unsichere UEFI Bootloader aussperrte:
https://www.heise.de/news/UEFI-Secu...re-Bootloader-per-Windows-Update-7220634.html
Auch das mag auf dem ein oder anderen System zu einer Fehlermeldung anstatt zu einem bootenden System geführt haben, obwohl SHIM meines Wissens nicht betroffen war. Aber all diese Dinge muss man differenziert von der Linux Installation betrachten.

 

[Evil E-Lex]

Über das unnötige EFI Partitionsthema brauchen wir wohl erst recht nicht mehr zu diskutieren. Das ist unschön, aber letztlich kein Problem.

Nein, kein Problem. Es wirft aber ein schlechtes Licht auf die Codequalität des Installers, wenn eine derartig triviale Situation nicht einfach mit einer Abfrage der Form "falls ESP vorhanden nutze die und erstelle keine weitere" gelöst wird. Das führt doch geradezu zu den Schlüssen des TE, dass man annehmen könnte, der Installer macht Dinge die er nicht machen soll.

Bei den anderen von dir angesprochenen Punkten, gebe ich dir uneingeschränkt recht.

 

[riversource]

Es wirft aber ein schlechtes Licht auf die Codequalität des Installers, wenn eine derartig triviale Situation nicht einfach mit einer Abfrage der Form "falls ESP vorhanden nutze die und erstelle keine weitere" gelöst wird.

Da du ja offenbar so versessen darauf bist: So einfach ist es nicht. Es kann ja durchaus Gründe geben, die später das Vorhandensein einer ESP Partition erfordern, z.B. beim Wegfall der ersten Platte. Und nachträglich eine solche Partition hinzuzufügen, ist schwierig. Von daher gehe ich davon aus, dass die Partition intentional angelegt wird.

Und es ist immer noch völlig offtopic.

 

[PHuV]

Das war dein Posting im anderen Thread, weswegen du ziemlichen Ärger bekommen hast und nun den hier zur eigenen Rechtfertigung eröffnet hast.
Da das nachweislich falsch ist, andernfalls müssten alle, die hier andere Erfahrungen gemacht haben absichtlich Blödsinn erzählen, macht es wenig Sinn sich hier im Kreis zu drehen, solange du das nicht wenigstens relativiert.

Ich habe in dem Artikel genau das erklärt, was hier passiert, was andere nicht gemacht haben. Wenn der Artikel falsch ist, dann sag bitte wo, und gleite nichts ins Unsachliche ab. Fakt ist, keiner hat genau erklärt, was das Problem ist, und keiner wußte vorher genau, wo das Problem ist. Das wurde jetzt durch meine Forschung mal genauer und sachlich aufgeklärt. Ich habe hier dann nur Bootrec geschrieben und Bootmanager. Von Bootblock rede ich doch gar nicht mehr. Und ja, Bootblock ist falsch, da hatte ich schlichtweg falsch formuliert bzw. noch das MBR im Kopf gehabt, besser wäre eben Bootrec, Bootmanager oder Bootprozess als Begriff gewesen.

Zudem unterläßt Du die Tatsache, daß viele so getan hatten, als ob es dieses Problem nicht gäbe und man mich versuchte als unfähig hinzustellen Aber es gibt doch diese Probleme und ich habe genau aufgezeigt, daß es bis heute nach wie vor dieses Problem gibt.

Ich glaube, hier gehen einige Dinge durcheinander. Im Grunde ging es doch am Anfang darum, dass Systeme nach der Installation eines Linux nicht mehr booten, weil angeblich Bootloader oder Bootblocks oder sowas überschrieben werden.
:
Grundsätzlich kann man wohl festhalten, dass Linux bei der Installation nicht einfach irgendwelche Bootblocks überschreibt. Das liegt vor allem daran, dass es diesen Bootblock bei EFI Installationen gar nicht mehr gibt. Was Linux allerdings macht: Es schreibt seine Bootloader - sei es grub oder systemd-boot oder was anderes - in eine ggf. vorhandene primäre EFI Partition und fügt einen entsprechenden NVRAM Eintrag hinzu. Diesen Eintrag setzt es auch gerne mal an die erste Stelle, so dass nach der Linux Installation auch Linux bootet, und nicht mehr Windows. Wenn man dann grub so einstellt, dass der os-prober nicht losläuft, dann kommt auch kein Grub Bootmenu, und der unerfahrene Nutzer mag glauben, dass er Windows nicht mehr booten kann.

Korrekt, und genau das zeige ich hier doch Schritt für Schritt auf und hab mir die Mühe gemacht, genau das Problem aufzuzeigen, damit man versteht, was da passiert, wenn der Bildschirm schwarz bleibt.

Geht natürlich trotzdem immer noch - ggf. über die Änderung der Boot-Reihenfolge im UEFI oder über das UEFI Bootmenu. Der Windows Bootmanager und auch die entsprechenden NVRAM Einträge sind nicht weg.

Und nun kommt der Knackpunkt bei der Geschichte: Als es mir damals mit dem Ubuntu 20.04 so passierte, konnte ich mitnichten einfach so wieder von Windows booten. Ich hatte sogar die Linux SSD einfach abgezogen, und der Bootmanager, so wie er im BIOS eingetragen war, funktionierte schlichtweg nicht mehr, und ich bekam immer nur die Fehlermeldung, daß kein valides StartOS vorhanden ist (was als Fehlermeldung ja Quatsch ist, es ist noch vorhanden, wie Du es sagtest). Es half dann nur die übliche Prozedur mit BCD Reparatur bootrec /fixboot und Co, siehe
https://www.heise.de/tipps-tricks/W...-4268553.html#Reparatur des Bootmanagers: GPT

Sprich, es ist auf den ersten Blick nicht ersichtlich, was eigentlich das Problem ist. Deshalb eben auch die Anzeigen über BDC Tools, damit man es sehen kann.

 

[BeBur]

Früher hat man gesagt "erst Windows, dann Linux installieren, weil das böse Windows zerschießt dir den Bootvorgang", traurig, dass das offenbar insofern nicht stimmt, als das Linux Distros gerne mal den selben Effekt erzeugen.

 

[riversource]

Die vorherigen CentOS Versionen machten das auch nicht korrekt, aber CentOS 8 Stream läßt als einzige Linux Distrubution die Finger von der Windows Partition, so wie es sein soll.

Die Aussage ist so nicht richtig. Das soll gerade nicht so sein, die Bootloader sollten auf einer Partition gesammelt werden, denn genau dafür ist die ESP Partition da. Sie heißt nicht umsonst "EFI System Partition". Macht Windows umgekehrt ja auch so, dass es sich in vorhandene ESP installiert. (Interessant wäre zu sehen, ob Windows auch eine zusätzliche leere ESP Partition anlegt).

Was aus deinem Artikel unklar bleibt, ist der Zusammenhang mit den verlinkten Problemfällen. Du hast ja gerade bewiesen, dass es nicht zu Bootproblemen kommt, wenn man Linux nach Windows installiert.