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.

 

[Beelzebot]

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.

Schade, mich würde interessieren ob das bei Arch auch auftritt, sowohl manuell als auch evtl. mit archinstall.

 

[PHuV]

Schade, mich würde interessieren ob das bei Arch auch auftritt, sowohl manuell als auch evtl. mit archinstall.

Es steht Dir frei, das selbst auszuprobieren. 🙂

 

[Garmor]

Andere Linux Distributionen, die auf Debian basieren,

Ist der ganze Punkt nicht, dass Ubiquity das Problem ist bzw. hat, wenn Anaconda das anscheinend nicht macht? Wobei ich immer das ungute Gefühl hatte, dass Anaconda ab und zu aus der Reihe tanzt, ohne dass man Dinge wirklich reproduzieren kann.

 

[netzgestaltung]

Anaconda hat bei mir die letzten 10 Fedora installationen (ca 3-4 Jahre, verschiedene Geräte) keine seltsamen Sachen mehr gemacht wie früher. Ich hab aber schon wirklich lang kein Windows mehr gehabt, froh das thema nicht mehr beachten zu müssen ;-)

Ich war schon von Win(95/XP D:\) gewohnt immer manuell zu partitionieren, da lässt sich das dann schon vermeiden. Ich glaub ich hab noch nie nicht manuell installiert.

 

[Nowareeng]

Meine Erfahrung : Xubuntu - kein Problem
EndevaourOS - kein Probelm

Asrock A520 HDPV/Dash

Herangehensweise : EFI/boot partition + / partition erstellen ..

Hab Win + Linux auf der selben Nvme Platte inkl. 3 EFI

Könnte noch weitere BS am PC installieren und Win bootmananger bekommt nichts davon mit.....
EFI eintrag vom EndevaourOS ist noch im Bios , da ich die 3 EFI nicht entfernt hab....

Ergänzung (31. August 2022)

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:

Es gibt mittel und wege ( zb. dd )um Datenträger / partitionen 1:1 zu sichern und wiederherzustellen .....spart viel zeit und nerven mit bootrec gefrickel .......Aber ich kenn dass , hatte auch so meine probleme mit linux installationen...........

 

[KDE_Fan]

Tatsache ist, daß immer wieder nach diversen Linux Installationen Probleme auftauchen,

Meine Konfiguration ist der deines Rechners ähnlich.
ASUS ROG STRING B660-I ITX Board
I5-12600K
32 GB DDR5 RAM
Samsung 980 Pro NVMe SSD für Linux
Samsung 970 Pro NVMe SSD für Windows

Ich hatte bisher noch nie Probleme in der Art wie von Dir beschrieben.
Mein Windows ist die 11er Version.
Linux habe ich bisher schon einige getestet (meistens mit Plasma).
Bisher alles top.

 

[svkra1973]

Was mir nicht ganz klar ist. Meiner Meinung nach gehört die EFI-Boot-Partition (ESP) keinen OS (weder Windows noch Linux), sondern existiert unabhängig davon.

So steht es zumindest auch in der ArchWIKI: https://wiki.archlinux.org/title/EFI_system_partition:

The EFI system partition (also called ESP) is an OS independent partition that acts as the storage place for the EFI bootloaders, applications and drivers to be launched by the UEFI firmware.

Ableiten lässt sich das auch durch den Wikipedia Eintrag https://en.wikipedia.org/wiki/EFI_system_partition:

"The EFI (Extensible Firmware Interface) system partition or ESP is a partition on a data storage device (usually a hard disk drive or solid-state drive) that is used by computers having the Unified Extensible Firmware Interface (UEFI). When a computer is booted, UEFI firmware loads files stored on the ESP to start installed operating systems and various utilities."

Ich konnte jetzt auf die Schnelle keine Stelle finden, ob es prinzipiell erlaubt ist auf mehreren Platten verschiedene ESP-Boot-Partitionen zu haben und ob das dann auch von allen UEFI-Firmwares unterstützt werden muss.

Es wird also eigentlich meiner Meinung nach nichts an der Windows-Installation geändert, da die ESP eigentlich nicht zu Windows gehört. (sie wird nur initial durch Windows oder Linux angelegt wenn sie noch nicht vorhanden ist).

Natürlich bleibt unbestritten, dass wenn man hier nicht vorsichtig agiert, Windows nicht mehr gebootet werden kann (z.B. beim archinstall script habe ich es tatsächlich geschafft die ESP zu löschen, somit war Windows nicht mehr bootbar, wenn auch physikalisch noch vorhanden).

Nicht hilfreich ist hier auch das manche Linux Installer die ESP unter /boot/efi, manche unter /boot und wieder andere unter /efi gemountet haben wollen (je nachdem welcher bootloader grub, systemd-boot etc. Einsatz findet)

Warum CentOS das nun anders handhabt (vielelicht auch besser) , weiß ich nicht (Möglicherweise installiert CentOS im MBR mode und nicht GTP/EFI, das würde es erklären)

 

[@mo]

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,

Hier liegt eben der Pferdefuss deiner Behauptung. Du suggerierst, dass das so Standard ist, weil dir das auf deiner Hardware passiert. Mir ist das seit Jahren auf verschiedenster Hardware nicht (mehr) passiert. Der Windows Bootmanager arbeitet immer zuverlässig weiter und muss im schlechtesten Fall in der Bootreihenfolge angepasst werden.
Wäre das Usus, wäre es in den meisten gängigen Wikis/Dokus etc. entsprechend dokumentiert. Ist es aber nicht, aus dem schlichten Grund, weil es eben nicht so ist.
Als erfahrener Nutzer hier, solltest du wissen, dass man individuelle Erfahrung auf keinen Fall verallgemeinern sollte.

Dass Ubiquity nicht der Weisheit letzter Schluss ist, ist allgemein bekannt.

 

[Evil E-Lex]

Im BIOS verweisen beide Einträge auf die Windows EFI Partition auf dem Windows Datenträger Samsung 950 Pro.

Das ist vollkommen korrekt. Es gibt keine Windows EFI-Partition, sondern exakt eine EFI System Partiton (ESP). Die wird von allem Betriebssystemen genutzt, um dort den jeweiligen Bootloader abzulegen.

 

[7vor10]

Vor ein paar Jahren hatte ich mal im Internet gelesen, dass der Ubiquity-Installer (Ubuntu) und ggf. auch andere Linux-Installer bei der Installation eines Linux-OS, den EFI-Eintrag grundsätzlich in der ersten (gefundenen) EFI-Partition absetzen - auch dann wenn der Nutzer explizit dafür eine andere EFI-Partition gewählt hat.

Ich wollte es genau wissen und hatte daraufhin eine Test-VM kreiert für ein Dualboot mit Windows und Ubuntu auf jeweils einer eigenen (virtuellen) Disk. Beide Disks wurden in GPT mit einer vorbereiteten EFI-Partition erstellt. Dann wurde zunächst Windows auf die erste Disk installiert (mit EFI-Eintrag ebenda). Anschließend erfolgte die Installation von Ubuntu. Und zwar ausdrücklich über die manuelle Option ('Etwas Anderes'). Der Installer sollte Ubuntu auf die zweite Disk schreiben mit einem EFI-Eintrag in die EFI-Partition der zweiten Disk. So war es gewählt und vom Installer bestätigt. Trotzdem landete der EFI-Eintrag auf der ersten EFI-Partition!?

Dieses Verhalten ist für mich kein Feature sondern ein Fehler. Ob das immer noch so ist, weiß ich nicht. Denn ich hatte seitdem nur Installationen von Linux auf realer EFI-Hardware bei nur einer EFI-Partition. Das heißt, es war von mir so beabsichtigt, dass der EFI-Eintrag auf die EFI-Partition der internen Disk geleitet wird.

Diese 'seltsamen' Empfehlungen, die jeweils anderen Platten während der Installation abzuklemmen, kommen also nicht ganz von ungefähr. Es ist ja nicht so, dass User grundsätzlich zu dämlich sind für Installationen in einem geringfügig komplexeren Installations-Szenario. Oder sich für sowas erst mal tüchtig Mut antrinken müssen und dann sturzbesoffen auf irgendeinen falschen Button klicken.

Wer keine Lust darauf hat, das Rechnergehäuse aufzuschrauben, um eventuell gefährdete Datenträger zwischenzeitlich zu deaktivieren, kann das auch einfacher haben, indem er vor der Installation diese Datenträger (z.B.) per GParted als nicht boot-fähig markiert. Und zwar durch Entzug der von GParted so genannten Markierungen (boot,esp).

Auf dieser Basis hatte ich das obige VM-Experiment wiederholt, mit dem Unterschied, dass vor der Installation von Ubuntu die EFI-Partition auf der ersten Disk in vorgenannter Weise ausmaskiert wurde. Resultat: diesmal landete nicht nur Ubuntu selbst, sondern auch sein EFI-Eintrag wie gewünscht auf der zweiten Disk.

Meiner Meinung nach gehört die EFI-Boot-Partition (ESP) keinen OS (weder Windows noch Linux), sondern existiert unabhängig davon.

Ganz klar, so ist es!

Ich kann mich des Gefühls nicht erwehren, dass bei Themen dieser Art gern Boot-Start im (EFI-)BIOS mit den Bootloadern diverser OSe verwechselt werden. Letzteres ist quasi Stufe 2 eines Boot-Vorgangs.

Das ist ja gewissermassen das Haupt-Feature von UEFI. Dass man nämlich mehrere Bootloader auf ein und demselben Datenträger verankern kann!

Jedes Betriebssystem ist dabei berechtigt, 'seinen' Bootloader neben (nicht anstatt) anderen Bootloader in derselben EFI-Partition abzusetzen - muß aber nicht. Windows 10 und Windows 11 werden wohl gemeinsam den Windows BootManager benutzen. Linux Mint verwendet den EFI-Eintrag von Ubuntu (wenn schon vorhanden). Das heißt, wenn schon ein ubuntoides System auf dem Datenträger vorhanden ist, trägt es sich nur in dessen Bootloader ein (Grub); kann also nicht zusätzlich direkt aus der EFI-GUI gestartet werden.

Grub sammelt dabei alle während der Installation erkannten OSe, sodass man auch ein installiertes Windows aus Grub starten kann. Umgekehrt trägt der Windows BootManager - meiner Erfahrung nach - keine Linux-OSe in sein Auswahlmenü ein.

 

[PHuV]

Warum CentOS das nun anders handhabt (vielelicht auch besser) , weiß ich nicht (Möglicherweise installiert CentOS im MBR mode und nicht GTP/EFI, das würde es erklären)

Die Datenträger sind alle als GPT initialisiert.

Ergänzung (31. August 2022)

Was mir nicht ganz klar ist. Meiner Meinung nach gehört die EFI-Boot-Partition (ESP) keinen OS (weder Windows noch Linux), sondern existiert unabhängig davon.
:
Ich konnte jetzt auf die Schnelle keine Stelle finden, ob es prinzipiell erlaubt ist auf mehreren Platten verschiedene ESP-Boot-Partitionen zu haben und ob das dann auch von allen UEFI-Firmwares unterstützt werden muss.

Es wird anscheinend so unterstützt. Jede Installation legt immer eine eigene EFI Partition auf dem leeren Datenträger an, und legt dann aber seine Grub-Dateien aber immer auf dem primären Datenträger von Windows ein.

Das ist vollkommen korrekt. Es gibt keine Windows EFI-Partition, sondern exakt eine EFI System Partiton (ESP). Die wird von allem Betriebssystemen genutzt, um dort den jeweiligen Bootloader abzulegen.

Wieso legen dann alle von mir getesteten Linux Varianten eine eigene EFI Partition auf den 2.Datenträger an? Das BIOS erkennt übrigens prima für jeden Datenträger eine eigene EFI Partition und trägt das dann auch als Vorschlag für die Bootreihenfolge ein.

Ergänzung (31. August 2022)

Hier liegt eben der Pferdefuss deiner Behauptung. Du suggerierst, dass das so Standard ist, weil dir das auf deiner Hardware passiert.

Nein, da hast Du etwas mißverstanden. Es geht nicht um genau diese Hardware, sie ist nur ein Beispiel.

Mir ist das seit Jahren auf verschiedenster Hardware nicht (mehr) passiert.
.
Als erfahrener Nutzer hier, solltest du wissen, dass man individuelle Erfahrung auf keinen Fall verallgemeinern sollte.

Du machst hier genau das gleiche. Und Du hast es vermutlich ebenso nicht genau in dieser Konstellation ausgetestet. Bei mir und Kollegen auf Arbeit (die Linux neben Windows haben wollten) ist das sehr wohl über die Jahrzehnte immer passiert. Dazu kommen hier noch die oben zitierten Anfragen von Hilfesuchenden. Dann sag uns doch mal allen bitte genau, was hier falsch läuft, und erkläre mit weiterhin, warum es so viele Dokumentationen zum Thema Löschen Grub Windows gibt.

Genau aus diesem Grund habe ich den Installationsprozess von Ubuntu so genau hier dokumentiert, um zu zeigen, daß man als normaler Anwender gar keine Chance hat, die Grub Installation bzw. das Zerschiessen des Bootblocks zu verhindern. Die Menüauswahl gibt es gar nicht her. Und wenn ich irgendwo den kompletten Datenträger leer angebe, wo ich da Linux hinhaben möchte, gehe ich davon aus, daß alles dort landet, wo es soll, und nicht irgendwo was. Das halte ich für extrem unsauber.

 

[svkra1973]

Es wird anscheinend so unterstützt. Jede Installation legt immer eine eigene EFI Partition auf dem leeren Datenträger an, und legt dann aber seine Grub-Dateien aber immer auf dem primären Datenträger von Windows ein.

Ok, verstehe das Problem nun besser (danke).

Dann ist das Grundproblem hier wahrscheinlich das /boot/efi (oder /efi oder /boot je nach Bootloader) nicht auf die neue erstellte ESP verweist, sondern auf die vorher existente ESP (hier durch Windows erzeugt).

Das könnte man mit manueller Paritionierung wahrscheinlich ändern (da hier die mount-points explizit vergeben werden können, zumindest arch und fedora können das), ob dies aber das UEFI-BIOS vom Motherboard wieder kann, ist dann eine andere Frage und so oder so nicht für den unbedarften Anwender ersichtlich/anwendbar.

Das Frage ich mich sowieso, wenn mehrere ESP-Partitionen erlaubt sind, wie das UEFI-BIOS das dann erkennt und priorisiert. Wenn ich Zeit habe, probiere ich das mal aus. Wollte eh meine Linux-Installation nochmal platt machen.

Bei meinen bisherigen Installationen habe ich es immer bei einer ESP belassen.

 

[Evil E-Lex]

Wieso legen dann alle von mir getesteten Linux Varianten eine eigene EFI Partition auf den 2.Datenträger an?

Weil die Installer offensichtlich blöd sind. Wichtig ist nur, welche hinterher genutzt wird. Und das ist ja offensichtlich die ESP, die zuerst da war (die von Windows).

Davon ab könnte dein Beispiel praxisferner nicht sein. Niemand installiert Windows auf Datenträger 1 und lässt Datenträger 0 komplett leer. Anders herum macht das viel mehr Sinn.
Es wirkt, als würdest du cherry picking betreiben, um deine These zu bestätigen.

 

[@mo]

Und Du hast es vermutlich ebenso nicht genau in dieser Konstellation ausgetestet.

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!
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.
Ebenso die Abwesenheit entsprechender Anweisungen in den einschlägigen Wikis oder massenhafte Threads in den Linuxforen.

 

[riversource]

Die Frage ist: Wo ist denn das Problem, ob die Bootloader nun in einer oder in mehreren EFI Paritionen abgelegt werden? Entscheidend sind doch letztlich die Einträge im BIOS, und da ist das Ergebnis am Ende doch das gleiche. Die Bootloader überschreiben sich ja nicht gegenseitig, auch nicht in einer EFI Partition. Man kann ja auch jederzeit wieder den Windows Boot Manager standardmäßig booten, auch wenn ein ubuntu Ordner in der Windows EFI Partition liegt. Was da wie gebootet wird, ist ja letztlich nur Sache des Mainboard-BIOS. Wenn man dort darauf achtet, dass alle Einträge ordnungsgemäß an der richtigen Stelle liegen, dann ist der physikalische Speicherort der Bootloader vollkommen egal.

Übrigens macht Windows das genau so. Ich installiere nämlich häufiger auch mal anders herum: Linux vor Windows. Da schreibt Windows sich mit in den Linux EFI Ordner.

Davon ab könnte dein Beispiel praxisferner nicht sein. Niemand installiert Windows auf Datenträger 1 und lässt Datenträger 0 komplett leer. Anders herum macht das viel mehr Sinn.

Darauf hat man ja keinen Einfluss. Wenn ein Mainboard SATA vor NVME registriert, dann tauchen die Laufwerke in Windows in der Reihenfolge auf, wie hier beschrieben. Für den hier beschriebenen Problemfall ist das völlig irrelevant. Mit Praxisferne hat das gar nichts zu tun.

Meines Erachtens gibt es überhaupt nur einen Fall, wo die Fragestellung "Eine oder zwei EFI Partitionen" interessant wird. Wenn man nämlich neben dem klassischen Dualboot die Linux Partition auch in einer VM nutzen will (also die gleiche physikalische Installation), dann braucht die VM eine EFI Partition, da man die aktive Boot Partition üblicherweise nicht als physical Drive in VMWARE, Hyper-V oder VirtualBox eingebunden kriegt. Das ist übrigens auch ein guter Weg, zwei EFI Partitionen zu erzeingen: In VMWARE installieren, und dann den Booteintrag von Hand im BIOS erzeugen. Klappt hervorragend.

 

[Nowareeng]

 

[Evil E-Lex]

Darauf hat man ja keinen Einfluss. Wenn ein Mainboard SATA vor NVME registriert, dann tauchen die Laufwerke in Windows in der Reihenfolge auf, wie hier beschrieben. Für den hier beschriebenen Problemfall ist das völlig irrelevant. Mit Praxisferne hat das gar nichts zu tun.

OK, den Punkt sehe ich ein.

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

 

[Garmor]

Wo ist denn das Problem, ob die Bootloader nun in einer oder in mehreren EFI Paritionen abgelegt werden?

Wo das Problem ist, wenn ein Programm suggeriert, man könne etwas auswählen, aber es tut dann was anderes? Ich glaube, das nennt man "Defekt".

 

[riversource]

Hä? Man kann doch jederzeit die Einträge umsortieren, auswählen, ein Bootmenu aufrufen ...