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.

 

[Tanzmusikus]

@PHuV
Klasse Leserartikel & sehr erfreulich, dass Du dieses schwierige Thema hier ein bisschen mehr erhellst! ☀️
Sehr schön detailliert als auch kompakt sowie nachvollziehbar umgesetzt. 🙂

Samsung 950 Pro NVMe SSD für Windows GPT

Bitte die Datenträgergröße der NVMe im 1. Beitrag angeben. Könnte für das bessere Unterscheiden (z.B. in der Windows Datenträgerverwaltung oder in Linux Gparted) hilfreich sein.

Wie im Screenshot zu sehen war, sollte es eine 500GB oder 512GB NVMe-SSD sein.

---

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

Bitte noch die Klammer schließen: " (SATA6G_1) ". Danke!

---

Ich gehe die Installation so durch, so wie sie jeder Linux Anfänger oder normale Anwender durchgehen würde.

Dann zeige doch bitte einen Screenshot, wo die "Normale Installation" angehakt ist, nicht nur die minimale.
Dies würden sehr wahrscheinlich die meisten Linux-Anfänger bzw. normale Anwender tun.

---

Nur CentOS 8 Stream installiert alles brav auf dem Datenträger, welchen man im Installer eingetragen hatte.

Ist bei Pop!_OS (Ubuntu-Derivat) allerdings anders als beim klassischen Ubuntu - jedenfalls mittlerweile .
Dort werden schön säuberlich diverse Partitionen (ESP, swap, System, Recovery) ähnlich wie bei Windows auf dem zu installierenden Datenträger (in deinem Fall wäre das die 2,5" SSD auf /dev/sda) angelegt.
Es nutzt auch gar kein GRUB beim Installieren im UEFI-Mode, sondern systemd-boot.

Als Anfänger hatte ich damals auch Ubuntu genutzt - nur gab's damals noch kein UEFI-Boards.

Grüße

 

[riversource]

Wie prüft man dann, ob es "spezifikationskonform" ist? Hier würde ich dann auch erwarten, daß ein Installer mir beim Prozess ansagt, ob er erfolgreich diverse Sachen schreiben kann oder nicht, bzw. entsprechende Logs generiert.

Das ist eine Herausforderung, keine Frage. Das Problem ist ja auch, dass der Linux Installationsprozess sich vielleicht keiner Schuld bewusst ist, aber trotzdem im Ergebnis irgendwas dabei herauskommt, dass den Windows Bootloader davon abhält, zu starten. Dann müsste man den Windows Bootloader fragen, was ihn stört.

 

[BeBur]

Das ist aber schon eine seltsame Philosophie, Windows bootet nicht mehr nachdem Linux installiert wurde und dann wird gesagt "ja, da stimmt ja mit Windows vielleicht was nicht, da müsste man mal schauen, ob da bei Windows nicht vielleicht was kaputt ist".
Einige scheinen es undenkbar zu finden, dass Linux Distros was falsch machen. Ich würde sogar soweit gehen, das man im Sinne der Nutzer doch wohl dafür sorgen sollte, dass das mit Abtsand am häufigsten genutzte Desktop-Betriebssystem in jedem Falle weiterhin bootet so wie vorher.

 

[Beelzebot]

Ich hatte mir gestern mal den Spass gemacht und Arch-Linux via archinstall auf eine SSD komplett zu installieren (ohne manuelle Partitionierung). Windows11 ist bereits auf der internen NVME mit entsprechenden ESP.
Arch-Linux erstellt dann ebenfalls eine eigene ESP, aber im Gegensatz zu Ubuntu wird auch die neu erstellte ESP verwendet und auch das BIOS findet beide Boot-Einträge im NVRAM.

Besten Dank für die Meldung! Ich war zu faul einen Versuchsaufbau aufzusetzen.

Einige scheinen es undenkbar zu finden, dass Linux Distros was falsch machen.

Weniger die Distro, eher der grafische Installer. Und die kommen von der Stange.
Wer es selber macht, also mit Arch (und da ja sogar das Install-Skript), Fedora oder dem Manjaro Architect, bekommt dieses Problem garnicht erst.
Die ganze Diskussion dreht sich eigentlich nur um miese grafische Installer.
Insofern ist halt auch der Titel ungünstig, weil das nicht "Linux" provoziert, sondern so wahrscheinlich einfach nicht im Anwendungshorizont der Installer veranlagt ist.

 

[BeBur]

Weniger die Distro, eher der grafische Installer. Und die kommen von der Stange.

Der ist doch Teil der Distro?

Und die kommen von der Stange.

Was genau meinst du damit? Ja, wenn du dir selber deine Installationsroutine auf deinen Anwendungsfall selber zusammenbaust bzw. programmierst oder schlicht einen anderen installer verwendest, dann mag das nicht auftreten. Aber das ist ja gerade das Problem, dass dieser oft verwendete Installer offenbar einen nicht sehr ungewöhnlichen use case nicht korrekt umsetzt.

sondern so wahrscheinlich einfach nicht im Anwendungshorizont der Installer veranlagt ist.

Ja, genau. Ist jetzt aber kein super ungewöhnlicher use case, bei mir ist das z.B. auch so.

 

[AGB-Leser]

So, jetzt habe ichs durchgelesen und verstehe irgendwie die Aussage nicht so richtig. Oder was das Problem sein soll. Das klingt für mich nach einem normalem Verhalten.
Ich hatte im Gegenteil immer Probleme mit Windows nach einer großen Aktualisierung: die hat mir immer den mbr/efi überschrieben. Aber dank efi kann man ja direkt Linux starten, im Terminal dann update-grub und gut war.

 

[Evil E-Lex]

Ich hab mir jetzt die Mühe gemacht, die Debian-Installer Repositories (von Ubuntu hab ich die Repos nicht gefunden) zu clonen und dort nach bcd bzw. BCD durchzugreppen. Soweit ich sehen kann, gibt es zwei Stellen, an denen der Suchbegriff im Quellcode auftaucht:

1. win32-loader: Ein Windows Programm, dass den Installer dem Windows-Bootmenü hinzufügt
2. os-prober: Baut die Grubkonfiguration zusammen und durchsucht die Partitionen nach Bootloadern.

Ich kann mir anhand des Quellcodes nicht erklären, wie die behauptete Änderung des BCD ablaufen soll. Vielleicht bin nur zu blöd, die Stelle zu finden.

 

[riversource]

So, jetzt habe ichs durchgelesen und verstehe irgendwie die Aussage nicht so richtig. Oder was das Problem sein soll. Das klingt für mich nach einem normalem Verhalten.

Ja, das geht, glaube ich, vielen so. Hier gingen halt einige Sachen durcheinander.

Das eigentliche Problem ist, dass es einige gibt, wo nach der Linux Installation Windows nicht mehr bootet. Aber auch da ist es nicht jedes Mal reproduzierbar, sondern kommt nur sporadisch vor. Die exakten Umstände, die zum nicht bootenden Windows führen, sind nicht bekannt. Außerdem ist das exakte Fehlerbild nicht bekannt: Verschwinden NVRAM Einträge? Werden UEFI Boot-Loader Informationen überschrieben? Führen irgendwelche hinzugefügten Dateien dazu, dass der Windows Bootloader nicht mehr starten kann? Wird er überhaupt noch aufgerufen, wenn Windows starten soll? Das alles weiß man nicht.
Und solange das nicht klar ist, sind alle Annahmen über die Ursache pure Spekulation.

Was durchaus sein kann: Linux installiert den NVRAM Eintrag und startet grub. Wenn grub aber das Boot Menu nicht anzeigt, sondern Linux direkt startet (z.B. weil der os-prober nicht ausgeführt wurde), dann mag es für den unerfahrenen Nutzer so aussehen, dass Windows nicht mehr startet.

Was ich bestätigen kann: An den Windows Boot Dateien wird durch Linux nichts verändert oder gelöscht. Es werden lediglich die Linux Boot-Loader Dateien hinzugefügt und ein entsprechender NVRAM Eintrag wird erzeugt. Ich hab das hunderte Male durchgeführt, und der Ablauf war nie anders. Allerdings waren die Systeme vor der Linux Installation auch üblicherweise in einem fabrikneuen Zustand. Häufig handelte es sich um Systeme, die mit einem vorinstallierten Windows ausgeliefert wurden.

Also der Aufruf an alle, die das mal ausprobieren wollen: wenn es euch gelingt, ein nicht bootendes Windows zu erzeugen, dann analysiert, was genau passiert, und warum Windows nicht mehr bootet. Nicht einfach eine Bootloader Reparatur ausführen und sich freuen, dass es wieder geht.

Das ist aber schon eine seltsame Philosophie, Windows bootet nicht mehr nachdem Linux installiert wurde und dann wird gesagt "ja, da stimmt ja mit Windows vielleicht was nicht, da müsste man mal schauen, ob da bei Windows nicht vielleicht was kaputt ist".

Es ist nun mal Windows, was nicht mehr startet. Deshalb muss man auch die Fehleranalyse bei Windows beginnen. Es hilft nicht, das funktionierende Betriebssystem zu untersuchen.

 

[BeBur]

Es ist nun mal Windows, was nicht mehr startet. Deshalb muss man auch die Fehleranalyse bei Windows beginnen.

Also wenn mein Computer problemlos funktioniert und ich dann eine Software installiere und es danach ein Problem gibt, dann suche bzw. vermute ich das Problem erstmal bei der Software und nicht anderswo bei dem Computer. Aber klar, man muss dann schauen, welche Veränderungen die Software an anderen Teilen des System durchgeführt hat, die das Problem verursacht haben. Trotzdem stimmt dann mit der Software was nicht und hier im Thread klingt das kurioserer weise aber gar nicht danach, sondern es wird gesagt "die Software hat das Problem ja vielleicht verursacht, aber vermutlich hat sie das nicht verursacht, sondern alles richtig gemacht und diese andere Software ist doch bestimmt Schuld".

 

[Nowareeng]

Ich würde auch sagen , erstmal schauen warum das betroffene BS nicht mehr Startet .Fehlt ein Eintrag oder passt das Ziel vom Eintrang nicht (also Fehlersuche zu erst) und dann versuchen herauszufinden warum dass so ist und was den Fehler verurascht hat . Ob das installationsprogamm vom Linux was Falsch gemacht hat liegt hier zwar nahe und ist warscheinlich...aber das warum .....meistens/bei anderen funktioniert es ja.........

 

[AGB-Leser]

Ich finde EFI mittlerweile echt einfacher als BIOS. Denn beim BIOS war die Wiederherstellung wesentlich komplizierter. Denn man konnte, wenn Windows den bootloader ausgetauscht hat, nicht einfach mehr Linux starten.
Bei EFI gehe ich einfach ins Startmenü, wähle Linux aus und der Rest siehe oben. Das ist ja der Vorteil einer eigenen EFI-Partition. Und diese wird auf JEDEM Datenträger angelegt, von dem aus gestartet werden soll. Auch von einem USB-Stick. Das macht das ganze ja robuster, weil das EFI diese Partition erwartet.

 

[Nowareeng]

Hab gerade in Virtual Box getestet ....
Windows11 frische installation..
Xubuntun22.04 lts - Xubuntu neben Windows imstallieren ausgewählt - inkl. updates während installation herunterladen....
Egebnis : Boot in die Grub BS Auswahl ...Windows Eintrag vorhanden und startet auch.....
Im Uefi ist auch alles vorhanden....
....

 

[@mo]

Es ist nun mal Windows, was nicht mehr startet. Deshalb muss man auch die Fehleranalyse bei Windows beginnen. Es hilft nicht, das funktionierende Betriebssystem zu untersuchen.

So ist das!

Wenn bei einem vorinstalliertem Windows es zunächst größere Probleme beim Dualboot gab, was ziemlich selten vorkam, habe ich in letzter Instanz dann einen Clean Install von Windows gemacht und dann ging das problemlos. Bestimmte UEFI-Firmware und vorinstalliertes Windows bedingen das leider manchmal. Ist jetzt aber schon eine Weile her, dass das der Fall war. Kommt aber immer noch vor. Bei Ubuntuusers hatten wir letztens Mal wieder einen Medionrechner, Erazer irgendwas, wo der Nutzer das/ein IRST Problem nicht lösen konnte. Und BIOS Updates gibt es für die Dinger natürlich auch nicht. Der stand dann blank da als nichts mehr ging. Ob man jetzt ursächlich, die Idee ein Dualboot zu installieren, oder eben die verwixte Firmware als Schuldigen ausmacht, ist dann auch schon egal.

 

[PHuV]

Witzigerweise führt unsere Besonderheit, Linux nativ und in der VM zu booten, zu deinem Wunschszenario: die Bootloader von Windows und Linux liegen in getrennten ESP Partitionen. Grund ist, dass man in Windows einen Datenträger als Offline markieren muss, um ihn in einer VM als Raw VMDK einzubinden. Das geht aber fürs aktuelle Bootlaufwerk nicht. Folglich hat die VM keinen Zugriff auf die Windows ESP und braucht ihre eigene. Aber alle UEFIs, die ich kenne, haben kein Problem damit.

Mir ist nun übrigens wieder eingefallen, warum es doch besser ist, wenn Linux eine eigene ESP hat. Man baut den primären Windows-Datenträger aus oder er geht kaputt: Man kann immer noch von Linux booten bzw. es ist lauffähig. Man hat ja den Effekt auch, wenn man alles abklemmt und dann nur Linux darauf installiert.

Daher bleibe ich dabei, eine separate ESP für jedes OS auf jeden Datenträger ist in einigen Punkten die bessere Lösung. OS Selektion funktioniert über BIOS genau so gut oder sogar besser, weil einerseits der separate Datenträger besser sichtbar wird, und eben nicht nur auf eine ESP gesetzt wird. Die Systeme bleiben damit auch sauberer getrennt. Daher würde ich mal sagen, der Standard bzw. Spezifikation ist hier nicht vernünftig durchdacht worden, und geht vermutlich von dem Fall aus, wenn mehrere Betriebssystem auf einem Datenträger landen, wo dann nur eine ESP für alles an dieser Stelle sinnvoll ist.

Die Leue, die über Multiboot arbeiten wollen, können sich das jederzeit eh so einrichten, wie Du es vorher richtig sagtest, die zusätzlich ESP auf jeden Datenträger stört ja nicht weiter.

 

[Tanzmusikus]

Man kann sogar mehrere ESP-Partitionen auf einem Datenträger (GPT) für mehrere Betriebssysteme ablegen.
Das ist zwar nicht unbedingt notwenidig, schafft aber zusätzliche Sicherheit durch Trennung.
Ein späterer Datenträgerwechsel ist somit evtl. auch einfacher praktikabel.

Das Separieren der Betriebssysteme auf dem jeweilgen Datenträger ist mir selbst am liebsten, da ich viel damit bastle. Bei einer Neuinstallation kann es dann sehr hilfreich sein alle anderen Datenträger verübergehend zu entfernen. So landet der entsprechende Bootloader (ESP) ziemlich sicher dort, wo er auch hin soll.

Grüße

 

[riversource]

Man baut den primären Windows-Datenträger aus oder er geht kaputt: Man kann immer noch von Linux booten bzw. es ist lauffähig.

Ja, das ist ein gutes Argument. Ich glaube auch, dass das der Grund ist, warum Linux eine eigene ESP Partition anlegt, obwohl sie leer bleibt. Wenn man gezwungen ist, den Bootloader neu zu installieren, eben weil die primäre Platte weg oder kaputt ist, dann ist es erheblich einfacher, den einfach in eine bereits vorhandene ESP zu installieren, als vorher noch die ganzen Partitionen verkleinern und verschieben zu müssen, um Platz für eine neue ESP zu bekommen.

Trotzdem stimmt dann mit der Software was nicht und hier im Thread klingt das kurioserer weise aber gar nicht danach, sondern es wird gesagt "die Software hat das Problem ja vielleicht verursacht, aber vermutlich hat sie das nicht verursacht, sondern alles richtig gemacht und diese andere Software ist doch bestimmt Schuld".

Das habe ich so ja nie gesagt. Ich habe gesagt, ich würde da mit der Fehleranalyse anfangen, wo das Problem auftritt. Das funktionierende System zu untersuchen, macht meines Erachtens weniger Sinn. Wo das Problem am Ende liegt, kann man doch überhaupt nicht sagen. Es ist denkbar, dass die neue Software was falsch gemacht hat, aber auch ein Fehler in der vorhandenen Software ist denkbar, die mit Dingen nicht zurechtkommt, die die neue Software erzeugt hat, und die eigentlich komplett spezifikationskonform sind.

 

[PHuV]

Aha: Heise -Bootloader-Signaturen per Update zurückgezogen: Microsoft bootet Linux aus

Microsoft hat etliche Bootloader-Signaturen per Windows Update zurückgezogen. Faktisch hat das Unternehmen damit Linuxe lahmgelegt.
:
Es erinnert an den Betriebssystemkrieg "Microsoft gegen Linux" zur Jahrtausendwende: Mit dem Windows-Sicherheitsupdate vom 9. August hat Microsoft über 100 Linux-Bootloader auf die schwarze Liste gesetzt. Seither verhindert UEFI Secure Boot, dass etliche Linux-Distributionen booten. So konnten wir bei Redaktionsschluss das noch immer aktuelle Ubuntu 20.04 LTS und auch Manjaro Linux nicht mehr installieren – außer, man schaltet Secure Boot im BIOS-Setup ab. Auch Live-Linux-Systeme wie etwa Desinfec't booteten nicht mehr auf PCs, bei denen zuvor das Windows-Update automatisch eingespielt wurde.

Gerade das Ubuntu 20.04 legte bei mir damals mein System lahm.

Damit lagen riversource wie andere wohl richtig, daß es letztlich doch an Windows liegt.

Ergänzung (3. September 2022)

Bitte die Datenträgergröße der NVMe im 1. Beitrag angeben. Könnte für das bessere Unterscheiden (z.B. in der Windows Datenträgerverwaltung oder in Linux Gparted) hilfreich sein.

Bitte noch die Klammer schließen: " (SATA6G_1) ". Danke!

Danke für die Hinweise, korrigiert.

 

[Tanzmusikus]

Es ist nun mal Windows, was nicht mehr startet. Deshalb muss man auch die Fehleranalyse bei Windows beginnen. Es hilft nicht, das funktionierende Betriebssystem zu untersuchen.

Wobei es ja nicht um die Funktion der Betriebssysteme an sich geht, sondern um die Funktion des Bootens des entsprechenden BS.

Als Allegorie verwende ich mal:
Einstiegsprobleme in ein Auto werden nicht gelöst, indem man die Funktion des Fahrens eines Autos überprüft.

Gerade das Ubuntu 20.04 legte bei mir damals mein System lahm.

Damit lagen @riversource wie andere wohl richtig, daß es letztlich doch an Windows liegt.

Es liegt doch aber nicht an Windows, sondern den Signaturen auf den Servern von Microsoft.
Außerdem startet dann ja Ubuntu nicht ... und nicht wie in deinem Fall das Windows (10/11).
Und wenn sogar der Bootvorgang des Ubuntu behindert wird, hat diese Meldung nichts mit diesem Thema zu tun.

---

Ich finde außerdem, dass die Überschrift zum Thema nicht ganz passend gewählt ist, denn ich sehe nirgendwo den Beweise bzw. die Herleitung, wer oder was diese Manipultion in welchem Umfang getätigt hätte.

Also ich sehe das Problem, dass hier beschrieben wird, finde es aber nicht im Einklang mit der Überschrift.
Ich würde es tendenziell als Frage formulieren, wenn die Ursachen nicht eindeutig bekannt sind.

"Warum findet dieses Verhalten der Debian/Ubuntu-Installer (Calamaris) so statt?"
"Was kann dazu führen?" und "Wie kann ich das Problem verhindern oder nachträglich beseitigen?"

Grüße

 

[PHuV]

Dann hätten wir trotzdem eine Erklärung

1. Linux installiert Grub auf ESP von Windows und schiebt sich an die erste Stelle für Starts
2. Reboot, ESP will mit hinterlegtem Grub auf Linux zugreifen, ist aber per BIOS und den fehlenden Signaturen über Secureboot nicht zugreifbar

Schon bleibt der Bildschirm schwarz, und keiner weiß warum. Sobald man die Einträge der BCD über bootrec und Co wieder korrigiert, gehts wieder, Windows kann wieder starten.

Ich bau mal wieder meinen Spielerechner auseinander...

 

[Tanzmusikus]

Okay, dann müsste doch aber Ubuntu 20.04 vor dem 09.08.2022 installiert worden sein, oder?
Denn eine spätere Installation würde schon am Secure Boot scheitern.

Hast Du denn in deinem Szenario "SecureBoot" überhaupt aktiviert gehabt?
Ich nutze das u.a. aus solchen Gründen gar nicht.

Als Laie mit aktiviertem SecureBoot steht (äh sitzt) man natürlich *** da.
Mittels Bootmenü-Taste (oder Änderungen im UEFI) können sich erfahrene Nutzer evtl. selbst helfen.

Grüße