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.

 

[PHuV]

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).

Dann nochmals gefragt, warum installiert dann einige Linux Installer nochmals eine ESP? Und warum installiert dann Grub trotz direkter Angabe auf dem Laufwerk den Eintrag wieder in die Windows ESP, siehe hier:

Sorry, das ist so jemals weder richtig getestet noch überdacht worden. Und ob es nur eine ESP geben darf oder mehrere erlaubt sind, ist anscheinend den Entwickler doch nicht so klar.

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.

Warum ignorierst Du jedes Mal meine Links von Hilfesuchenden und das, was mir da 2021 passierte? Es gibt sehr wohl in einigen Fällen Bootprobleme. Und Du ignorierst meinen Hinweis:

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:

Daher, nicht weiter behaupten und reden, stell es bitte selbst mal sauber mehrmals (!!!) verschieden nach. Und Du wirst dann ebenso auch mal nach einer Linux Installation vor einem schwarzen Bildschirm stehen und Dich wundern, daß gar nichts passiert. Aber dank meiner Hilfe weißt Du ja dann, was Du tun mußt.
☺️

 

[riversource]

Dann nochmals gefragt, warum installiert dann einige Linux Installer nochmals eine ESP?

Hab ich ja oben beschrieben, dafür kann es Gründe geben. Die kommt zum Einsatz, wenn die erste Partition verschwindet. Und nachträglich einrichten ist schwer. Also besser vorher anlegen. Und nur weil die Partition da ist, heißt das ja nicht, dass sie auch aktiv als ESP genutzt wird.

Und warum installiert dann Grub trotz direkter Angabe auf dem Laufwerk den Eintrag wieder in die Windows ESP

Weil die Bootloader in der primären ESP gesammelt werden sollen. So wie es Windows auch macht.

Warum ignorierst Du jedes Mal meine Links von Hilfesuchenden und das, was mir da 2021 passierte?

Ich ignoriere das nicht. Aber da muss man im Einzelfall analysieren, was schief gegangen ist, oder was falsch gemacht wurde. Deine Versuche zeigen ja, dass es im Normalfall nicht zu solchen Problemen kommt.

Daher, nicht weiter behaupten und reden, stell es bitte selbst mal sauber mehrmals (!!!) verschieden nach.

Glaub mir, wenn du noch so viele Dual Boot Linux/Windows Installationen erzeugen musst, wie ich, dann musst du fleißig sein. Die Zahl ist hoch dreistellig, wenn nicht vierstellig. Besondere Herausforderung bei uns ist, dass die Linux Installation immer nativ und in einer VM unter Windows lauffähig sein muss. Und das auch auf Notebooks, wo die zweite Platte zuweilen nur als USB Laufwerk verfügbar gemacht werden kann. Da lernt man zwangsläufig, sich mit EFI und seinen Eigenarten auseinanderzusetzen.

Ein Punkt dabei ist, dass es den Bootrec, wie du ihn beschreibst, in dieser Form nicht mehr gibt. Da wird auch nichts zerschossen, und kann auch nicht zerschossen werden. Sowohl EFI Bootloader als auch NVRAM Einträge werden hinzugefügt. Das ist der große Vorteil von EFI: da wird ein Filesystem gelesen, und Dateien direkt geladen, ohne Bootblock, MBR oder sowas. Wenn man das verstanden hat, dann funktioniert das in 100% aller Fälle.

 

[PHuV]

Weil die Bootloader in der primären ESP gesammelt werden sollen. So wie es Windows auch macht.

Nochmals das Bild:

Da steht es deutlich: Gerät für die Bootloader-Installation:
Und ich wähle die Linux SSD auf /dev/sda. Zu was dient dann diese Abfrage bitte?

Ich ignoriere das nicht. Aber da muss man im Einzelfall analysieren, was schief gegangen ist, oder was falsch gemacht wurde. Deine Versuche zeigen ja, dass es im Normalfall nicht zu solchen Problemen kommt.

Das Problem ist dann, wenn der Bildschirm schwarz bleibt, und der Boot-Prozess - wo auch immer - hängt. Die Frage ist hier, und vielleicht weißt Du eine Lösung, wie man dann den Fehler sehen und beheben kann? Der Rechner bootet, sollte dann eigentlich 2 Einträge im BIOS für den Bootvorgang haben, und startet weder vom ersten Eintrag, der nach wie vor Windows-Bootmanager sein sollte, da es die erste Installation war, noch vom neuen 2.Eintrag im BIOS Bootmanager vom neu installierten Linux, hier ubuntu:

Selbst wenn Linux nicht funktioniert, sollte Windows als Ersteintrag booten. Anders herum ist Windows kaputt, sollte der 2.Eintrag booten. Aber es bootet... nix. So, wie debugge ich das jetzt? Wenn Du da eine Idee hättest, könnte ich das gerne nochmal nachstellen, bis das Problem wieder auftaucht. Ich hab ja die SSDs noch hier liegen, die muß ich eben nur wieder einbauen und nochmals testen.

Meine Vermutung ist, daß Grub (auf der ESP von Windows) aus irgend einem Grund ins Leere greift, und man das unter Umständen erst sieht, wenn man diesen Datenträger abziehen. Dann sieht man, daß Grub leer startet:

Hier weiß man wenigstens, woran man ist, und kann es mit Windows- wie Linuxmitteln lösen.

Glaub mir, wenn du noch so viele Dual Boot Linux/Windows Installationen erzeugen musst, wie ich, dann musst du fleißig sein. Die Zahl ist hoch dreistellig, wenn nicht vierstellig. Besondere Herausforderung bei uns ist, dass die Linux Installation immer nativ und in einer VM unter Windows lauffähig sein muss. Und das auch auf Notebooks, wo die zweite Platte zuweilen nur als USB Laufwerk verfügbar gemacht werden kann. Da lernt man zwangsläufig, sich mit EFI und seinen Eigenarten auseinanderzusetzen.

Welches Linux verwendest Du dann? Und Du verwendest hier vermutlich dann auch einen anderen Installations- oder Verteilungsweg?

Ein Punkt dabei ist, dass es den Bootrec, wie du ihn beschreibst, in dieser Form nicht mehr gibt.

Kann man jetzt unterschiedlich sehen und ist eine philiosophische Diskussion. Bootrec steht für Boot Record und ist erstmal neutral als Eintrag (Record). Du meinst vermutlich MBR als Master Boot Record, den haben wir in der Tat bei GTP nicht mehr. Davon rede ich aber nicht, sondern so, wie alle es beschreiben, wenn es um die Korrektur des BCDs geht, siehe
https://www.heise.de/tipps-tricks/Windows-10-Bootmanager-reparieren-so-geht-s-4268553.html#Reparatur des Bootmanagers: GPT

6. Schritt:
bootrec /FixBoot
Geben Sie dann "bootrec /fixboot" ein und drücken Sie [Enter]. Es wird Ihnen mitgeteilt, dass der Vorgang erfolgreich abgeschlossen wurde.

Der Befehl heißt nun mal bootrec. Und darauf beziehe ich mich.

Da wird auch nichts zerschossen, und kann auch nicht zerschossen werden. Sowohl EFI Bootloader als auch NVRAM Einträge werden hinzugefügt. Das ist der große Vorteil von EFI: da wird ein Filesystem gelesen, und Dateien direkt geladen, ohne Bootblock, MBR oder sowas.

Das ist nun auch wieder eine Perspektive der Betrachtung. Wenn Du Linux, so wie ich es nachstellte, etwas einstellt, was danach dann so nicht mehr - warum auch immer - so wie vorher funktioniert, ist es zerschossen, verändert, kaputt, nenne es wie Du es möchtest. Wenn Windows oder Linux nicht ordnungsgemäß davon booten, halte ich die letztliche Benennung - verzeih mir das bitte - irrelevant. Der normale Anwender sieht nur einen schwarzen Bildschirm, und weiß nicht mehr weiter, er bekommt ja nicht mal irgend eine Fehlermeldung oder einen Hinweis, es ist total intransparent für den üblichen Anwender oder selbst erfahrene Linuxer wie mich.

Wenn man weder EFI genau kennt wie Du oder ich, der sich mit Unix/Linux auskennt, und so das Problem finden kann, ist man erst mal aufgeschmissen. Und mal so schnell ein BCD in der EFI Partition zu korrigieren ist ja nun auch nicht die alltägliche Tätigkeit eines normalen Anwenders.

Wenn man das verstanden hat, dann funktioniert das in 100% aller Fälle.

Nützt leider nichts, wenn das an 2 Stellen bis heute von einigen Linux Installern seit Jahrzehnten so falsch gemacht wird, wie wir das ja leidlich feststellen konnten. Da haben es wohl die entsprechenden Entwickler nicht verstanden. 😉 Und das es an 2 Stellen (!!!) (doppelte EFI Partition und Maske für Eintrag auf eine andere Platte, die dann ignoriert wird) seit Jahrzehnten falsch läuft, und keinem das so weiter auffällt oder interessiert, finde ich... bedenklich.

 

[riversource]

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.

Ergänzung (1. September 2022)

Noch mal: Linux verhält sich korrekt und spezifikationskonform. Da wird nichts verändert, überschrieben oder zerschossen. Alle Dateien werden dort abgelegt, wo sie hingehören. Due unnötige ESP ist kein Problem und sorgt auch nicht für Boot Probleme.

Wenn du wieder diesen schwarzen Bildschirm hast, dann analysiere bitte, warum. Du machst da irgendwo einen fundamentalen Fehler. Von allein komnt es nicht dazu.

W8r nutzen übrigens Lubuntu LTS.

 

[PHuV]

Noch mal: Linux verhält sich korrekt und spezifikationskonform.

Entschuldige bitte meine Penetranz, das halte ich so nicht für systemkonform:

Ergänzung (1. September 2022)

Wenn du wieder diesen schwarzen Bildschirm hast, dann analysiere bitte, warum. Du machst da irgendwo einen fundamentalen Fehler. Von allein komnt es nicht dazu.

Wo kann ich bei dem geführten Installationsprozess einen Fehler machen? Ich habe die Screenshots dokumentiert, und Du kannst es genau so nachstellen. Mehr oder anderes mache ich nicht. Somit kann ich an dieser Stelle bewußt weder was verstellen noch falsch machen. Ebenso mache ich nach der Installation im BIOS nichts. Ich starte den Installer, warte bis der durchgeht, und das System will dann neu gestartet werden.

Ich schaue mir gerade nochmal die Partitionierung von Linux über einen anderen Rechner an:

und wollte mir hier die EFI-Partition nochmal genauer anschauen, und sie ist... leer.

DISKPART> select disk 6

Datenträger 6 ist jetzt der gewählte Datenträger.

DISKPART> select partition 1

Partition 1 ist jetzt die gewählte Partition.

DISKPART> assign letter=J

Der Laufwerkbuchstabe oder der Bereitstellungspunkt wurde zugewiesen.

PS C:\> j:
PS J:\> dir

ESP wird von Linux Ubuntu angelegt, oben als schreibend für den Booloader eingetragen, und es steht nichts drin. In meinen Augen klar ein Fehler.

Ansonsten, ich würde ja gerne zugeben, wenn ich einen Fehler machen würde, aber wo?

 

[Evil E-Lex]

ESP wird von Linux Ubuntu angelegt,

Ja, und die wird nicht genutzt. Spielt also für die weitere Betrachtung keine Rolle.

oben als schreibend für den Booloader eingetragen

Das behauptet der Installer zwar, macht aber etwas ganz anderes. Er schreibt stattdessen den Bootloader in die vorhandene ESP, was UEFI-konform ist.

Der Installer vereinfacht und abstrahiert zu stark. Dabei fällt zum einen der Unterschied BIOS/UEFI unter den Tisch. Zum anderen halt, das durchaus gängige Szenario, dass es weitere Betriebssysteme auf einem anderen Datenträger gibt.

Mir scheint, der Installer kennt nur zwei Szenarien:

• Als zweites OS neben Windows auf dem gleichen Datenträger
• Als einziges OS auf einem Datenträger

 

[MisC]

Das Drop-Down Menü ist für klassische Bootsektoren. Daher werden hier auch die Geräte gelistet und nicht alle verfügbaren ESPs.

Auf welche ESP die Grub Dateien kommen legst du fest indem du der Partition /boot/efi als Einhängepunkt zuweist. Ist das nicht gemacht wird offensichtlich die erste ESP genutzt.

Das eine weitere ESP erstellt wird liegt wohl daran, dass du die Partitionierung automatisch durchführen lässt hier wird einfach ein Profil umgesetzt. Würde bei Dual-Boot Systemen grundsätzlich immer manuell Partitionieren.

Wie du dir dein UEFI Windows zerschießt mit einer UEFI Linux Installation kann ich dir auch nicht sagen, allerdings ist mir das seit UEFI trotz dutzender Dual-Boot Installationen mit diversen Distributionen nicht mehr passiert. Solltest du evtl. mal genauer analysieren mittels Vorher-Nachher Vergleich der ESP und des NVRAM.

Es mag ein paar Schönheitsfehler im Installationsprozess geben, aber da es Open-Source Software kannst du hier selbst Einfluss darauf nehmen und Verbesserungsvorschläge geben oder selbst einen Patch schreiben.

Zu beachten ist natürlich auch, dass Linux auf sehr vielen verschiedenen Hardwarekonfigurationen läuft auch auf einigen sehr alten. Es kann daher gut sein, dass es irgendwelche Gründe hat warum das Drop-Down Menü angezeigt wird oder bei der automatischen Selektion der ESP die erste bevorzugt wird.

 

[svkra1973]

Auch wenn ich jetzt wieder auf der ESP "rumhacke".
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.
Also ist es vollkommen in Ordnung mehrere ESP im System zu haben und scheint der Spezifikation zu entsprechen.
Ubuntu bzw. die Debian-Derivate haben hier scheinbar einen, aus meiner jetzigen Sicht fehlerhaften oder zumindest fragwürdigen, installer.

Auf welche ESP die Grub Dateien kommen legst du fest indem du der Partition /boot/efi als Einhängepunkt zuweist. Ist das nicht gemacht wird offensichtlich die erste ESP genutzt.

Das scheint generell nicht so zu sein. Siehe arch-linux, ist also eher debian-spezifisch.

 

[riversource]

Ansonsten, ich würde ja gerne zugeben, wenn ich einen Fehler machen würde, aber wo?

Ich glaube, der Fehler passiert nicht bei der Installation, sondern bei den Aufräumarbeiten zwischendurch. Wer weiß, wie sauber du ESP zurücklässt und was diese BCD Tools im NVRAM anrichten. Da kann alles mögliche passieren.

Also ist es vollkommen in Ordnung mehrere ESP im System zu haben und scheint der Spezifikation zu entsprechen.

Ja, das funktioniert problemlos. Hab ich ja auch auf meinen Installationen. Aber standardmäßig nutzen die meisten Installer die primäre ESP. Windows ja auch.

 

[Capet]

Was ich dieser Diskussion nicht so recht entnehmen konnte:
Betrifft diese Problematik speziell die Konstellation, dass im System eine NVMe-SSD eingesetzt wird, oder auch Systeme, die rein mit normalen SATA-Platten bestückt sind?

 

[MisC]

Das scheint generell nicht so zu sein. Siehe arch-linux, ist also eher debian-spezifisch.

Meine Aussage bezog sich auf den Ubuntu Installer nicht auf einen allgemeinen Standard. Hätte ich evtl. deutlicher machen können.

 

[riversource]

Betrifft diese Problematik speziell die Konstellation, dass im System eine NVMe-SSD eingesetzt wird, oder auch Systeme, die rein mit normalen SATA-Platten bestückt sind?

Ich denke, es betrifft alle Laufwerkstypen.

 

[PHuV]

Was ich dieser Diskussion nicht so recht entnehmen konnte:
Betrifft diese Problematik speziell die Konstellation, dass im System eine NVMe-SSD eingesetzt wird, oder auch Systeme, die rein mit normalen SATA-Platten bestückt sind?

Alle. SATA Datenträger sind genauso betroffen wie NVMe.

Ergänzung (2. September 2022)

Ich glaube, der Fehler passiert nicht bei der Installation, sondern bei den Aufräumarbeiten zwischendurch. Wer weiß, wie sauber du ESP zurücklässt und was diese BCD Tools im NVRAM anrichten. Da kann alles mögliche passieren.

Was kann da passieren? Wenn das Windows sauber mehrfach bootet, ist alles in Ordnung. Wenn es das nach der Linux Installation nicht mehr tut, ist der Fehler dann eher der Installation zuzuschieben. Zudem haben ich die BCD vorher entsprechend exportiert bzw. gesichert, so daß ich sie jederzeit auf den frisch installierten neuen Stand zurücksetzen konnte. Weiterhin kann man an sich davon ausgehen, daß Windows die BCD korrekt zurücksetzt, wenn man die oben genannten Reparaturschritte per bootrec durchführt. Da passiert doch zwischendrin keine Magie oder zusätzlich Schritte meinerseits, die als Fehlerquelle noch dienen könnten.

Solange Du wie andere hier mir nicht genau sagen können, wo in dem (aus meiner Sicht gut) dokumentieren Prozess irgendwo ein Bedienfehler auftaucht, bleibe ich dabei, das die Linux Installationweise ein Problem hat.

Bitte nicht falsch verstehen, mir geht es überhaupt nicht ums Rechthaben, ich will den Fehler verstehen bzw. nachvollziehbar fassen können. Wenn nur mir das immer wieder passieren würde, könnte ich die Vorwürfe ja verstehen, aber es passiert tagtäglich mehr Leuten so.

 

[Evil E-Lex]

bleibe ich dabei, das die Linux Installationweise ein Problem hat.

Es gibt nicht die "Linux-Installationsweise". Das ist überhaupt das Problem an deinen, sonst guten, Beiträgen. Du pauschalisierst zu viel.
Das der Ubuntu- bzw. Debian-Installer nicht das Gelbe vom Ei ist, sollte mittlerweile klar sein. Im Rahmen der Aufklärung wäre ich an einer technischen Erklärung installiert, wie genau der Ubuntu- oder Debian-Installer den BCD bearbeiten können sollte. Meines Wissens nach gibt es dafür keine Linuxtools.
Ich kann außerdem keinerlei Bugreports finden, die auf ein grundsätzliches Problem hindeuten.

 

[PHuV]

Wie du dir dein UEFI Windows zerschießt mit einer UEFI Linux Installation kann ich dir auch nicht sagen, allerdings ist mir das seit UEFI trotz dutzender Dual-Boot Installationen mit diversen Distributionen nicht mehr passiert. Solltest du evtl. mal genauer analysieren mittels Vorher-Nachher Vergleich der ESP und des NVRAM.

ESP kann ich vergleichen, klar, aber wie vergleiche ich NVRAM?

Es mag ein paar Schönheitsfehler im Installationsprozess geben, aber da es Open-Source Software kannst du hier selbst Einfluss darauf nehmen und Verbesserungsvorschläge geben oder selbst einen Patch schreiben.

Machst Du das etwa, oder sonst wer hier? Unbezahlt mach ich da gar nichts, ich hab dafür gar keine Zeit.

Zu beachten ist natürlich auch, dass Linux auf sehr vielen verschiedenen Hardwarekonfigurationen läuft auch auf einigen sehr alten. Es kann daher gut sein, dass es irgendwelche Gründe hat warum das Drop-Down Menü angezeigt wird oder bei der automatischen Selektion der ESP die erste bevorzugt wird.

Dann könnte der Installer ja so intelligent sein und merken, daß bereits eine EFI Partition vorhanden ist, und das Menü ausblenden.

Ergänzung (2. September 2022)

Es gibt nicht die "Linux-Installationsweise". Das ist überhaupt das Problem an deinen, sonst guten, Beiträgen. Du pauschalisierst zu viel.

Wo pauschaliere ich hier bitte?

 

[Evil E-Lex]

Wo pauschaliere ich hier bitte?

Das fängt schon in der Überschrift des Themas an. Dann noch dein Beitrag aus dem anderen Thread:

Nope, alle Linuxe verändert auf dem Primärdatenträger immer den Bootblock,

Dazu kommen noch Übertreibungen wie "jahrzehntelang". UEFI gibt es im Massenmarkt erst ein knappes Jahrzehnt.

 

[riversource]

Wenn es das nach der Linux Installation nicht mehr tut, ist der Fehler dann eher der Installation zuzuschieben.

Nein, da machst du es dir entschieden zu einfach. Zum einen muss der Installer mit den vorhandenen Randbedingungen zurechtkommen, und wenn die nicht spezifikationskonform sind, ist das Ergebnis nicht vorhersehbar. Zum anderen wird Windows immer noch vom Windows Bootmanager gestartet, nicht vom Linux Bootloader. Wer weiß, was den Windows Bootmanager vom Booten abhält?

Deshalb ja meine Bitte: Prüfe nach, was genau dazu führt, dass Windows nicht mehr bootet. So lange wir das nicht wissen, ist jede Vermutung über die Ursache pure Spekulation.

Zudem haben ich die BCD vorher entsprechend exportiert bzw. gesichert, so daß ich sie jederzeit auf den frisch installierten neuen Stand zurücksetzen konnte.

Das betrifft dann aber nur den BCD, also nur die Konfiguration für den Windows Bootmanager (BCD = Boot Configuration Data). Nicht den Bootmanager an sich und nicht die daraus resultierenden NVRAM Einträge.

Weiterhin kann man an sich davon ausgehen, daß Windows die BCD korrekt zurücksetzt, wenn man die oben genannten Reparaturschritte per bootrec durchführt.

Ja, die BCD schon. Aber zum Boot-Setup gehört halt mehr.

 

[Capet]

Wäre es dann nicht am sinnvollsten, einfach mal einen bug-report auf Launchpad (https://bugs.launchpad.net/ubuntu) zu erstellen und das erkannte Verhalten zu beschreiben? Irgendeine Reaktion würde es dann ja seitens Ubuntu dazu geben.

 

[riversource]

Ich glaube, das hat wenig Zweck. In #47 ist schön beschrieben, wie es im Moment abläuft. Wenn man davon abweicht, macht man ein solch riesiges Fass an Variantenvielfalt auf, die man berücksichtigen müsste, dass kein Mensch da freiwillig rangeht, zumal der einzige Nachteil eine leere ESP Partition ist, die einem ein bisschen Speicherplatz von einer Platte klaut.

 

[PHuV]

Das fängt schon in der Überschrift des Themas an.

Was ist an der Überschrift falsch? Da ich (als ich den Artikel erstellte) beim Installieren des Bootloaders ein Laufwerk angab, und Grub sich dort nicht, wie vermutet, eintrug, lag der Titel so nahe.

Dazu kommen noch Übertreibungen wie "jahrzehntelang". UEFI gibt es im Massenmarkt erst ein knappes Jahrzehnt.

Das Problem besteht ja grundsätzlich schon seit MBR Zeiten, daher paßt das aus meiner Sicht sehr wohl auch.

Ergänzung (2. September 2022)

Nein, da machst du es dir entschieden zu einfach. Zum einen muss der Installer mit den vorhandenen Randbedingungen zurechtkommen, und wenn die nicht spezifikationskonform sind, ist das Ergebnis nicht vorhersehbar.

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 kannst Du doch bestimmt als erfahrener Installateur mir aus dem Stehgreif verraten, dann prüfe ich das mal lokal.

Zum anderen wird Windows immer noch vom Windows Bootmanager gestartet, nicht vom Linux Bootloader. Wer weiß, was den Windows Bootmanager vom Booten abhält?

Deshalb ja meine Bitte: Prüfe nach, was genau dazu führt, dass Windows nicht mehr bootet. So lange wir das nicht wissen, ist jede Vermutung über die Ursache pure Spekulation.

Meine Rede, nur sind hier meine Kenntnisse begrenzt. Ich kann die UEFI Booteinträge, ESP und EFI Einträge, BCD usw. prüfen und anschauen, und das wars. Was im NVRAM passiert, keine Ahnung, und ich wüßte auch nicht, wie oder was ich da prüfen könnte.

Das betrifft dann aber nur den BCD, also nur die Konfiguration für den Windows Bootmanager (BCD = Boot Configuration Data). Nicht den Bootmanager an sich und nicht die daraus resultierenden NVRAM Einträge.

Ich kenne das ja und habs nochmals hier nachgelesen:
https://docs.microsoft.com/de-de/wi...ows-11#windows-boot-manager-settings-for-uefi
Auch überhaupt kein Hexenwerk.

Ja, die BCD schon. Aber zum Boot-Setup gehört halt mehr.

Richtig, aber da wird von meiner Seite aus ja nichts weiter verändert oder manipuliert. Sprich, ich fasse die Dateien nicht an. Du bringst mich jetzt aber auf eine Idee, ich gehe einfach mal das ganze EFI Verzeichnis durch, merke mir die Zeitstempel und erzeuge für jede Datei eine Prüfsumme, dann sehe ich hier schnell, was und wie sich nach einer Installation geändert hat.