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:

1661886396331.png


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
1661886625131.png


Ansicht mit Visual BCD

1661887728267.png


1661886772894.png


1661886545369.png


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.

1661886797486.png


1661886898402.png

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

1661886917338.png


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

1661887202360.png


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


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.

1661889964295.png


Hier einmal direkt über Linux Terminal als Root Benutzer:
1661887467364.png


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

1661886748784.png


Im Loader ist Ubuntu nun eingetragen
1661887485993.png


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:

1661938579254.png


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.

1661888250014.png


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:
1661888792678.png


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.
 

Anhänge

  • 1661887749704.png
    1661887749704.png
    50,7 KB · Aufrufe: 235
  • 1661886597070.png
    1661886597070.png
    420,3 KB · Aufrufe: 244
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus, Capet, BeBur und 10 andere
Tanzmusikus schrieb:
Hast Du denn in deinem Szenario "SecureBoot" überhaupt aktiviert gehabt?
Ich nutze das u.a. aus solchen Gründen gar nicht.
Da ich Windows 11 mit Kernisolierung verwende, benötige ich per se schon Secure Boot und TPM 2.0. Bisher hatte es auch weiter bisher selten Probleme, bis auf booten, gemacht. Und ja, für manche USB-Sticks muß man leider Secure Boot deaktivieren, weil sie noch alt über MBR und Co. arbeiten (Hiren und Ultimate Boot Disc etc).
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Hmm, nachdem ich hier mitgelesen habe und mir heute ein dual-Boot-System aus Win10 und Ubuntu 18.04 mit einer Neuinstallation von Ubuntu 22.04 vorgenommen habe (die Windows10-Installation blieb unangetastet), kann ich hier zumindest ergänzen, dass es für diese konkrete Konstellation kein Problem mit Windows nach der Installation von Ubuntu gibt und ich auch mit früheren Ubuntu-Versionen nie eines hatte.

Secure-Boot ist aktiv. Ich installiere generell beide Betriebssysteme nebeneinander auf eine SSD, zusätzlich eine SSD für /home und eine SSD nur für den Windows-Spielekram.

Beide OS nutzen die EFI-Partition, die auf der OS-SSD liegt, vor der Neuinstallation und danach. Die Installation habe ich von einem Ubuntu-USB-Stick gemacht, mit der Installeroption "Etwas anderes", da ich dort letztlich festlegen musste, dass für / die alte /-Partition genutzt und formatiert wird, sowie das alte /home als neues /home eingebunden wird. Als Platte für den Bootmanager wurde die Platte ausgewählt, auf der beide OS liegen.

Installation lief durch, Grub-Bootmenü mit Einträgen für Ubuntu und Windows ist da, beide OS lassen sich starten.

1662220529153.png

1662220545693.png
 
  • Gefällt mir
Reaktionen: BeBur, AGB-Leser und PHuV
Ja, Dualboot auf dem gleichen Datenträger habe ich auch oft erfolgreich durchgeführt.
Auf meinem Läppi läuft jetzt noch ein Lubuntu (ehemals 20.04) neben einer 10er Windose.

Ich wähle seit Jahren eigtl. immer die manuelle Installation (bzw. "Etwas anderes" ;)).
Das Einzige, was ich mit dem Acer-Notebook Besonderes habe, ist ein doppelter Booteintrag (shim+ubuntu) in der ESP sowie natürlich im UEFI-Bootmenü mittels [F12]. Funktionieren tun beide, egal ob SecureBoot aktiv ist oder nicht.

Den Fall mit dem Bootloader auf der falschen Platte hatte ich auch manchmal und deshalb entferne ich für Windows-Installationen alle anderen Platten vom Mainboard. Mit MBR damals ja - mit UEFI, weiß ich nicht mehr.

Grüße
 
Meine Erfahrung damit: traue keinem MS-Programm und schon lange keinem beliebigen Automatismus! Beobachte das tatsächlich auch schon seit ich mit Dualboot dabei bin. Das verrückteste war mal, dass MS beim Update nicht nur Linux, sondern sich auch selber zerschossen hat (nur das eigene EFI zum Glück) - aber trotzdem ärgerlich.

Eigentlich sollte laut Therorie die ESP tatsächlich von allen gemeinsam genutzt werden, ohne sich zu stören - ABER in der praxis ist es am besten zumindest eine "Notfall" ESP zu haben - sodass man dann safe sein Linux wieder zum laufen bekommt und danach sich um den eigentlichen ESP "kümmern" kann. Man sollte mitlerweile wirklich auf BIOS/MBR verzichten (EFI/GPT), um es einfacher zu haben bzw. auch wartungsfreundlicher.
Ich habe diesen erwähnten "Canonical-Bug" schonmal geforscht (schon lange lange her und ich weiß nicht mehr ob offiziell - ich glaub das war der "Boot-Repair"-Programmierer, den ich versehentlich verdächtigte) - die Antwort war auf Gutdeutsch, dass MS-Programme für den Dualboot benutzt werden müssen, MS von dem Problem wisse und man nichts machen könne.

Wenn man sich an die Vorgabe hält ist man also der gelackmeierte - deswegen gehen viele andere Distros/Installer ihre eigene Wege. Wichtig: Bei derartigen Problemen muss man, wie bereits mehrmals darauf hingewiesen wurde, immer im Detail gucken.

Ich weiß, dass klingt jetzt bisschen MS lästernd, aber da hab ich wirklich immer wieder "Scherereien" erlebt, ob nun gewollt oder nur unglücklich ist, sei mal dahingestellt. Zumindest auch ein großes Lob an die Entwickler von "chkdsk" - ohne Sie würde vermutlich auch kein Windows (so zuverlässig) laufen. Und es geht tatsächlich relativ einfach sich auch selber was einzutüten, was früher, später oder sofort zum Problem wird.
 
Also dess mit den GPT/EFI ist super praktisch....
Ich hab grad Win11 in Virtualbox installiert, eingerichtet und danach die als .vmdk angelegte "Virtuelle Platte" mit hilfe von:

https://stackoverflow.com/questions/22327728/mounting-vmdk-disk-image

"modprobe + qemu" befehle im Linux eingebunden und per dd auf meine ssd gezogen.....

Die EFI partition wurde vom UEFI automatisch erkannt u. W11 startete einwandfrei.Hab dann noch die aktuellen chipsatz und grafiktreiber (AMD) installiert.....

👍

Hab nun W10, Xubuntu und W11 zu meiner auswahl am PC
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Das klingt interessant!
Du hast also Windows zunächst in eine VM installiert, konfiguriert (Treiber, Programme) und dann die Image-Disk unter Linux gemountet, um sie auf eine Disk-Partition des Hosts zu kopieren und um so die Windows-Installation anschließend nativ betreiben zu können?

Zum Mounten hast Du dieses Verfahren aus dem verlinkten Artikel verwendet:
For .vmdk disks sudo modprobe nbd sudo qemu-nbd -r -c /dev/nbd1 ./linux_box/VM/image.vmdk notice that I use the option -r, that's because VMDK version 3 must be read only to be able to be mounted by qemu and then I mount it with mount /dev/nbd1p1 /mnt

Für den Fall, dass dies nicht funktionieren sollte, gäbe es ersatzweise auch noch das Verfahren mittels 'guestmount'.

Zum Kopieren hast Du dann das 'dd'-Kommando benutzt (oder alternativ das GUI-Tool 'Disks' ('Laufwerke') - sag' ich mal so).

Ich vermute, dass Du für Windows 11 eine separate SSD benutzt hast (also nicht die mit Windows 10 und Xubuntu). Wurden dann die anderen Windows11-Partitionen (insbesonders die EFI-Partition) in gleicher Weise einfach nur aus der virtuellen Disk heraus umkopiert?

Das reichte schon aus, dass es beim nächsten Reboot vom UEFI startfähig eingebunden wird?
(Klar, nativen Grafiktreiber muß man nachher noch einbinden, sonst hat man vorerst wohl nur VGA-Grafik.)

Wenn das alles so simpel sein sollte, ginge das auch mit älteren Windows-Versionen (10,7)?

Interessant wäre das alles, weil man durch Verschieben des Installationsvorgangs von Windows in eine VM, gegebenenfalls einigen Stolpersteinen aus dem Weg gehen könnte (keine Gefahr, dass bei Misslingen der Installation das Host-System in Mitleidenschaft gezogen wird).
 
Man braucht UEFI 2.3. Mit eingeschaltetem SecureBoot usw. ist es deutlich frikliger geworden - grundsätzlich gehts aber so einfach. Bei Windows 7 (RIP) braucht man das Service Pack 3 (?)
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 7vor10 und Nowareeng
Blöde Frage: warum sollte man Win11 erst in einer VM mit vmdk installieren, um es danach aufwendig von der vmdk auf eine SSD zu zuehen? Warum installiert man nicht direkt auf die SSD? Geht ja auch in der VM, wenn man es so will, aber auch direkt nativ.
 
Vielleicht umgeht man damit den Kontozwang. Denn Windows bekommt das ja mit, wenn es in einer vm läuft
 
Zum einen wollte meine letzte Windows Installation in einer VM auch ein Online Konto. Zum anderen könnte man es in der VM auch direkt auf die SSD installieren.
 
Auf jedenfall umgeht man so irgendwelche eigenheiten von den installern der Betriebssysteme........
 
  • Gefällt mir
Reaktionen: 7vor10
Sehe ich ja alles ein. Die Installation in einer VM kann durchaus Sinn machen. Aber wenn man es hinterher auf eine SSD kopieren will, warum dann nicht sofort auf die SSD?
 
......weils nebenbei geht , man den aktuellen Bootloader nicht beeinflusst ohne die SSD oder NVME's ausbauen zu müssen ...
Beispiel : Ich will win11 nativ Testen ...mein BS(Win10/Ubuntu) sind auf der NVME...ich hab keine Ahnung was Win11 beim installieren mit meinem aktuellen Bootloader macht.....will weder die NVME ausbauen noch die SSD und HDD abschliessen.....meine Freundin nutzt meinen PC mit eigenem Benutzerkonto....ich will mal alle neu aufsetzen , kann alles vorbereiten und einrichten und muss nicht an einem Abend fertig sein und sie kann den PC wie gewohnt weiterverwenden ...bis alles fertig ist ..usw....so stelle ich mir das halt vor....
 
  • Gefällt mir
Reaktionen: Tanzmusikus
So, hab nun festgestellt das sich das Win11 nach dem ersten Start sich immer wieder an erster Stelle in der Bootreihenfolge vom Uefi setzt 👎
 
Dann stimmen die Einträge im UEFI nicht. Du bootest vermutlich über die Default Laufwerkseinträge, und die werden vom Mainboard BIOS sortiert (nicht von Windows!).

Sorge für ordnungsgemäße NVRAM Einträge, die du dann mit den gängigen Tools auch entsprechend sortieren kannst, z.B. mit dem efibootmgr.
 
  • Gefällt mir
Reaktionen: Nowareeng
Wenn ich im UEFI mein Windows10 auf der nvme als erstes in der bootreihenfolge setzte und speichere ist das beim nächsten neustart geändert und die SSD von Win11 steht wieder als erstes in der Reihenfolge...... ausser ich lösche die EFI partition vom Windows11

efibootmgr muss ich mir noch ansehen....
 
Zurück
Oben