2025

Bisher war Secure Boot kein Thema für mich. Sowohl Gentoo Linux als auch Windows 11 lassen sich im Dual Boot Setup mit dem Bootloader GRUB problemlos bei deaktiviertem Secure Boot starten.

Windows 11 verwende ich grundsätzlich nur für einige wenige Computerspiele, die nicht unter Linux funktionieren. Hauptursache sind meistens die Anti-Cheat-Komponenten, welche die Linux-Kompatibilität verhindern. Nun haben die ersten Spielestudios im Kampf gegen Cheater angekündigt, dass sie zukünftig ein aktiviertes Secure Boot für ihre Spiele voraussetzen werden. Und so wurde dieses Thema plötzlich für mich relevant.

Die Problematik

Secure Boot soll die Systemsicherheit erhöhen, indem nur kryptographisch signierte Programmteile vom Bios bzw. UEFI geladen werden. Und das durchgehend. In meinem Fall muss eine Kette von mindestens 3 Teilen berücksichtigt und signiert werden:

1. Der Kernel im Pre Boot Authorization System von SEDUTIL zum entsperren der per TCG OPAL Hardwareverschlüsselung gesperrten NVME-Speichermedien
2. Der Bootloader GRUB zur Auswahl des Betriebssystems
3. Der Kernel vom eigentlichen Gentoo Linux System bzw. vom Windows System

1. Vorbereitung im BIOS

Im BIOS bleibt Secure Boot zunächst deaktiviert. Hier beim ASUS Bios/UEFI ist dazu die Option "OS Type" auf den Wert "Other OS" gesetzt.

Allerdings muss Secure Boot in den Setup Modus versetzt werden, damit SBCTL (siehe Schritt 2) die Schlüssel installieren kann. Hier im ASUS Bios/UEFI setzt man dazu die Option "Secure Boot Mode" auf "Custom" und führt anschließend im Untermenü "Key Management" die Operation "Clear Secure Boot Keys" aus.

2. Vorbereitungen in Linux

Nachdem die Vorbereitungen im Bios abgeschlossen sind, kann das Linux System mit dem Tool SBCTL für Secure Boot vorbereitet werden. Das geht mit folgenden Befehlen:

Weitere Informationen zu diesem Vorgehen siehe: Gentoo Wiki: sbctl

3. Installieren und signieren von GRUB für Secure Boot

Damit GRUB bei aktiviertem Secure Boot korrekt booten kann, ohne dass alle GRUB- und Kernel-Module signiert werden müssen, muss es auf eine bestimmte Art und Weise installiert und anschließend signiert werden. Das Signieren eines bereits vorhanden GRUB EFI Images ist ggf. nicht ausreichend, da ein dynamisches Nachladen von nicht signierten Modulen oder Fonts durch GRUB zu dem Fehler "error: prohibited by secure boot policy" führen kann (siehe dazu auch: EndeavourOS Forum: GRUB & Secure Boot).

Die Installation von GRUB kann wie folgt durchgeführt werden:

Zusätzlich sollte ggf. geprüft werden, ob das neue GRUB-Image an allen magischen Orten installiert ist, siehe letzter Punkt in meinem Artikel zur Einrichtung von SEDUTIL.

Anschließend müssen alle GRUB-Images (ggf. mehrere, falls an verschiedenen magischen Orten abgelegt) signiert werden, z.B. wie folgt:

4. Signieren der Gentoo Linux Kernel für Secure Boot

Auch die verwendeten Kernel des Gentoo Systems müssen signiert werden, z.B. wie folgt:

Daran muss auch nach jeder neuen Kernelinstallation gedacht werden. Ggf. ist dass im Installationsscript der Distributionskernel schon enthalten oder kann per USE-Flag aktiviert werden. Ich selbst benuzte allerdings noch das Tool GENKERNEL für die manuelle Kernelerstellung.

5. Signieren und installieren des Kernels im Pre Boot Authorization System von SEDUTIL für Secure Boot

Nun wird es etwas komplizierter: Wenn man wie ich ein Pre Boot Authorization System im Shadow MBR eines per TCG OPAL verschlüsselten NVME-Laufwerkes installiert hat, muss natürlich auch der Kernel dieses Systems signiert werden. Mit Hinweisen aus dem Fehlerbericht 259: [HowTo] SecureBoot support konnte ich jedoch eine Lösung finden.

Wichtig ist, dass hier als Ausgangslage das gleiche RESCUE-Image verwendet wird, welches auch bei der Ersteinrichtung der Pre Boot Authorization (PBA) System verwendet wurde, da es sonst zu Inkompatibilitäten kommen kann, siehe dazu auch Anmerkung weiter unten. Ich hatte für meine Systeme die Version RESCUE64-1.15.1-44-ge29fbb1.img.gz aus dem Repositoy von ChubbyAnt genutzt. Das Vorgehen sollte für alternative Rescue-Images von SEDUTIL identisch sein.

Zunächst muss das RESCUE-Image eingebunden werden, um Zugriff auf das vorkonfekionierte PBA-Image zu erhalten:

Hinweis: Das angegebene Offset berechnet sich über die Sektorgrösse und den Startsektor des Dateisystems im Image, welches mit dem Befehl fdisk -l RESCUE64-1.15.1-44-ge29fbb1.img inspiziert werden kann.

Anschliessend wird das PBA-Image aus dem CPIO-Paket des RESCUE-Images extrahiert, eingebunden, der enthaltene Kernel signiert und das veränderte PBA-Image wieder ausgehängt:

Jetzt hat man mit der Datei /tmp/usr/sedutil/UEFI64-1.15.1-44-ge29fbb1.img ein aktualisiertes PBA-Image vorliegen, das einen signierten Kernel enthält. Dieses muss nun mit SEDUTIL in den Shadow-MBR der NVME-Laufwerke geladen werden. Wenn im laufenden Linux System die korrekte Version von SEDUTIL (also aus dem gleichen Paket, aus dem auch das PBA stammt) installiert ist, funktioniert das mit folgendem Befehl:

Sollte das laufende Linuxsystem kein kompatibles SEDUTIL besitzten, kann das neue PBA-Image in das ursprügliche CPIO-Paket im RESCUE-Image gepackt werden, dieses auf einen USB Stick geschrieben und dann zur Verwendung des PBA-Images mit der korrekten SEDUTIL Version gebootet werden.

6. Nachbereitung im BIOS (Aktivieren von Secure Boot)

Im ASUS Bios/UEFI kann abschliessend Secure Boot aktiviert werden. Bei ASUS funktioniert das mit der Option "OS Type" und dem Wert "Windows UEFI mode".

Anschliessend den Rechner einmal vollständig ausschalten, damit auch das PBA-System erneut aufgerufen wird und die gesamte Kette getestet werden kann. Im Fehlerfall einfach Secure Boot im Bios/UEFI wieder deaktivieren.

Unter Linux lässt sich das aktivierte Secure Boot wie folgt prüfen:

Unter Windows mit dem Tool msdiag32.

7. Sonstige Anmerkungen

• In Windows 11 sind keine Einstellungen erforderlich. Windows 11 bootet, unabhängig davon ob Secure Boot eingeschaltet oder ausgeschaltet ist. Auch gibt es keine Probleme, wenn Secure Bootnachträglich im Bios/UEFI wieder deaktiviert wird. Ob Secure Boot in Windows 11 aktiv ist, sieht man im Programm msinfo32.
• Soweit mir bekannt ist, sind ein korrekt eingerichtetes Booten per GRUB im EFI Modus und die Nutzung von GPT-Partitionstabellen grundlegende Voraussetzungen für Secure Boot. Beides sollte aber mittlerweile Standard sein.
• Alle Angaben ohne Gewähr! Macht Backups! Insbesondere wenn mit der Hardwareverschlüsselung etwas schief geht, muss im schlimmsten Fall per PS-ID-Revert das komplette Medium unwiderruflich gelöscht werden. Auf jeden Fall das PBA UEFI Image nutzen, welches auch ursprünglich verwendet wurde (ich z.B. verwende einer Version von ChubbyAnt/SEDUTIL.COM, welche aufgrund eines veränderten Password-Hash-Verfahrens mit dem Original SEDUTIL/PBA der Drive-Trust-Alliance und anderen Forks inkompatibel ist. Aber wenn man sowas wie SEDUTIL nutzt, sollte man eigentlich ohnehin immer einen Recovery USB Stick mit exakt der gleichen Version bereithalten, die man zum Zeitpunkt der Verschlüsselung genutzt hatte.

In den letzten Tagen habe ich mich mit dem Undervolting meines Prozessors und meiner Grafikkarte beschäftigt. Undervolting bei CPUs und GPUs bedeutet, dass man die Betriebsspannung (Voltage) der Prozessoren absenkt, ohne dabei (idealerweise) die Leistung spürbar zu beeinträchtigen. Ziel ist es, den Stromverbrauch und die Hitzeentwicklung zu reduzieren.

Undervolting des Prozessors AMD Ryzen 9950X3D

Hierzu stehen direkt im UEFI (Bios) verschiedene Tools zur Verfügung, unter anderem der Curve Optimizer und der Curve Shaper. Ich habe mich an dem Video von ParteeMike Tech orientiert, aber nur das Undervolting umgesetzt und keine Overclocking-Maßnahmen vorgenommen. Dabei habe ich festgestellt, dass mein Prozessor bei -30mV auf allen Kernen stabil läuft, und daher auch nur im Curve Optimizer entsprechende Einstellungen vorgenommen. Stabilität kann man u.a. mit dem kostenlosen Tool CoreCycler testen, darf aber neben der Stabilität unter Last auch das Verhalten im Leerlauf nicht vernachlässigen.

Die Ergebnisse können sich durchaus sehen lassen: Durch diese eine Einstellung verbraucht der Prozessor im Einzelkernbetrieb 21% weniger Energie bei 2% höherer Performance im Vergleich zu den Werkseinstellungen. Im Mehrkernbetrieb mit allen 16 Kernen sind es zwar nur 4% Energieersparnis, aber immerhin 4% Performancesteigerung. In der Praxis wird die relative Energieersparnis/Leistungssteigerung wohl irgendwo dazwischen liegen, da beispielsweise in Spielen nur 8 der insgesamt 16 Kerne verwendet werden.

Cinebench R23 - Single Core	Performance Punkte	Performance relativ	Leistungs- aufnahme Watt	Leistungs- aufnahme relativ
Werks- einstellungen	2.215	100 %	70 W	100 %
Core Optimizer: All Cores @ -30mV	2.269	102 %	55 W	79 %

Cinebench R23 - Multi Core	Performance Punkte	Performance relativ	Leistungs- aufnahme Watt	Leistungs- aufnahme relativ
Werks- einstellungen	42.328	100 %	200 W	100 %
Core Optimizer: All Cores @ -30mV	44.066	104 %	193 W	96 %

Undervolting der Grafikkarte Nvidia GeForce 5090FE

Im Bereich der Grafikkarten ist der kostenlose MSI Afterburner das etablierte Tool fürs Undervolting. Beim den Grundlagen und der Bedienung dieses Werkzeugs hat mir zunächst das Video von Panjno geholfen; speziell beim Undervolting der 5090FE habe ich dann aber die Einstellungen aus dem Video von Eiga übernommen. Diese laufen auch bei mir zuverlässig und stabil.

Auch bei der GPU kann man mit Undervolting sehr viel rausholen: Je nach Einstellung z.B. 1% mehr Performance bei 15% geringerer Leistungsaufnahme – was immerhin 86 Watt entspricht. Alternativ 2% weniger Performance bei 21% geringerer Leistungsaufnahme – satte 115 Watt. Zusammen mit dem Undervolting der CPU macht sich das nicht nur beim Stromverbrauch, sondern auch bei der Wärmeentwicklung im Gehäuse bemerkbar.

3DMark Demo Steel Nomad	Performance Punkte	Performance relativ	Leistungs- aufnahme Watt	Leistungs- aufnahme relativ
Werks- einstellungen	14.048	100 %	577 W	100 %
UV 2737MHz @ 885mV	14.181	101 %	490 W	85 %
UV 2572MHz @ 870mV	13.708	98 %	458 W	79 %

Nach etwas mehr als fünf Jahren habe ich mir einen neuen PC zusammengestellt. Diesmal habe ich mir einen High-End-Rechner gegönnt und ihn in dem kompakten NCASE M2 Round Silver-Gehäuse im klassischen Layout verbaut.

Hardware:

• CPU: AMD Ryzen 9950X3D
• GPU: Nvidia GeForce RTX 5090FE
• CPU-Kühler: Thermalright Peerless Assassin 120 Mini Black (PA120Mini)
• Mainboard: ROG STRIX B850-I GAMING WIFI
• RAM: 2× Corsair Pro 32 GB DDR5-5600
• SSD: 2× Samsung 990 Pro 4 TB
• Netzteil: Corsair SF1000
• Gehäuselüfter: 5× Arctic P14 Slim PWM PST
• Sonstiges: Gummischrauben für Lüfter, 3 mm Kühlkörper für hintere SSD (nicht im Bild), 5 mm Abstandshalter für Bodenlüfter, einfacher Anti-Sag-GPU-Halter, zusätzliche Lüfterhalterung für das NCASE M2

Verwendungszweck / Ziele:

• Dual-Boot-System mit Gentoo Linux für Produktivität und Windows 11 für Gaming
• Fast lautloser Betrieb im normalen Desktop-Einsatz (Web-Browsing, Videos)
• Kann beim Gaming lauter sein, da ich ein Headset benutze

Bau-Erlebnis:

Der Zusammenbau verlief unkompliziert und ohne größere Probleme.

Der CPU-Lüfter ist als Lufteinlass konfiguriert. Die oberen und seitlichen Lüfter sind als Luftauslass eingestellt. Die Bodenlüfter sorgen für zusätzliche Frischluftzufuhr.

Wie auf den Bildern zu sehen, hatte ich ursprünglich einen zusätzlichen 90-mm-Gehäuselüfter hinten als Lufteinlass montiert, habe ihn aber wegen der Lautstärke entfernt. Ich denke, er bringt nicht genug, um den zusätzlichen Lärm zu rechtfertigen. Vielleicht befestige ich ihn später direkt am CPU-Kühler, aber momentan bin ich mit den CPU-Temperaturen zufrieden.

Die 5090 FE kommt mit ihrer eigenen Kühlung gut zurecht. Die Bodenlüfter unterhalb der GPU sind nur dafür da, die Temperatur unter 52°C zu halten. Das ist die Schwelle, ab der die Lüfter der 5090 FE anspringen – und wenn das passiert, sind sie ziemlich laut. Damit das nicht passiert, müssen die Bodenlüfter so nah wie möglich an der GPU positioniert werden. Deshalb habe ich Abstandshalter unter die Lüfter gesetzt, um sie näher an die GPU zu bringen. So laufen sie sehr leise und langsam (~28 % PWM), sodass die GPU-Lüfter während Web-Browsing, YouTube oder im Idle nie anspringen.

Mit meinen aktuellen Lüftereinstellungen (siehe Anhänge) bleibt das System beim Surfen, YouTube oder im Idle angenehm leise, bei einer Raumtemperatur von etwa 22°C. Beim Spielen eines anspruchsvollen Spiels wie Indiana Jones mit maximalen Einstellungen zieht das System ca. 700 Watt und das Gehäuse wird spürbar heiß – fast wie ein großer Kühlkörper. Nach der Gaming-Session kühlt es aber schnell wieder ab. Natürlich werden die Lüfter dabei deutlich hörbar, aber da meine 5090 FE sowieso hörbares Spulenfiepen hat und ich mit Kopfhörern spiele, stört mich das nicht weiter.

Temperaturen & Optimierungen:

Im HWInfo-Screenshot sieht man die Temperaturen nach über einer Stunde Gaming. Insgesamt bin ich zufrieden, außer mit dem SSD-Controller-Chip meiner primären SSD. Diese Samsung SSD ist vorne am Mainboard montiert, zwischen GPU und CPU. Es gibt wohl ein bekanntes Problem mit diesem SSD-Kühlkörper: Der SSD-Controller-Chip sitzt etwas tiefer als die Flash-Speicher, sodass ein kleiner Spalt zwischen Controller und Kühlkörper entsteht. Eine mögliche Lösung besteht darin, Wärmeleitpads mit unterschiedlichen Dicken zu verwenden: 0,5 mm für die Flash-Speicher und 1 mm für den Controller. Ich habe solche Pads bestellt, aber sie sind gerade nicht lieferbar. Sobald sie ankommen, werde ich testen, ob sie helfen, die Temperatur unter 70°C zu halten.

Ich habe weder Overclocking noch Undervolting oder EXPO-Profile aktiviert. Mir ist Systemstabilität wichtiger als eine kleine Leistungssteigerung. Deshalb habe ich auch bewusst JEDEC-konformen DDR5-5600 RAM gewählt, statt des oft empfohlenen DDR5-6000 „Sweet Spots“. Möglicherweise probiere ich aber in Zukunft Undervolting aus, um die Temperaturen weiter zu senken.

Und ja, mein Kabelmanagement ist schrecklich – bitte nicht beurteilen!

Übersicht der vorgenommenen Bios-Einstellungen:

Probleme und Lösungen:

Der im Mainboard integrierte Netzwerkadapter Intel I226-V ist leider als Problemkind bekannt. Ich hatte damit zwei verschiedene Probleme:

• Unter Windows war die Übertragungsgeschwindigkeit sehr langsam (nur 10–100 Mbit/s statt der erwarteten 1000 Mbit/s). Ich habe zahlreiche Einstellungen ausprobiert – insbesondere bei den Energiesparfunktionen im BIOS und im Netzwerktreiber – sowie verschiedene Treiberversionen installiert. Irgendwann funktionierte es schließlich. Leider kann ich nicht mehr genau sagen, woran es letztlich lag. Da ich die Energiesparfunktionen inzwischen wieder aktiviert habe, dürften sie nicht die Ursache gewesen sein. Vermutlich hat die Installation des aktuellen Treibers aus dem Intel Ethernet Adapter Complete Driver Pack geholfen.
• Unter Linux hat sich der Adapter gelegentlich nach einiger Zeit komplett deaktiviert, mit der Fehlermeldung: "lPCIe link lost, device now detached". Dieses Problem scheint tatsächlich mit den Energiesparfunktionen zusammenzuhängen. Laut diesem Beitrag können sie durch die Kernel-Parameter pcie_port_pm=off und pcie_aspm.policy=performance deaktiviert werden.

Mit SEDUTIL lässt sich die Hardwareverschlüsselung nach dem TCG-OPAL-Standard für kompatible SSDs aktivieren. Der große Vorteil: Die Lösung funktioniert betriebssystemunabhängig und kann zudem unkompliziert ein- oder wieder ausgeschaltet werden.

Das Grundprinzip: Im gesperrten Zustand stellt die SSD einen kleinen, unverschlüsselten, alternativen Bootbereich zur Verfügung. In diesem wird ein minimalistisches Linux-System installiert, das beim Start direkt eine Eingabeaufforderung zur Passworteingabe öffnet. Nach erfolgreicher Authentifizierung wird die SSD entsperrt und das eigentliche Betriebssystem neu gestartet.

Installation

Die Installation ist auf sedutil.com gut dokumentiert. Dort findet sich auch ein Build, das mit Ryzen-CPUs kompatibel ist – diese Version verwende ich selbst seit über fünf Jahren. Hier eine Kurzfassung der wichtigsten Befehle für die Installation nach dem Booten von der bootbaren Installations- bzw. Recovery-Disk (inkl. Beispielausgaben):

Test

Nun folgt ein wichtiger Test des Unlocking-Tools mit dem festgelegten Probepasswort "debug". Die Ausgabe für die betreffende SSD muss dabei "is OPAL Unlocked" lauten. Falls stattdessen eine andere Meldung erscheint, sollte OPAL wieder deaktiviert werden, um Probleme beim späteren Zugriff auf die Daten zu vermeiden.

Echtes Password setzen und Shadow-MBR aktivieren:

Mit den folgenden Befehlen wird das Probepasswort "debug" durch ein eigenes Passwort ersetzt. Zudem wird der Shadow-MBR aktiviert, sodass die verschlüsselte SSD das zuvor installierte Linux-System zur Passworteingabe als bootbare Partition bereitstellt.

Deaktivierung von OPAL:

Falls erforderlich, kann mit den folgenden Schritten OPAL deaktiviert werden. Dabei ist "debug" das zuvor gesetzte Probepasswort. Falls bereits ein eigenes Passwort vergeben wurde, muss es entsprechend ersetzt werden.

Troubleshooting und Hinweise

Kompatibilität

Die SEDutil-Version von sedutil.com ist nicht kompatibel mit der Originalversion der Drive Trust Alliance, da sie für die Passwort-Hash-Berechnung SHA-512 anstelle von SHA-1 verwendet.

Initialsetup meldet "NOT AUTHORIZED"

Wie im Fehlerbericht #291 dokumentiert, schlagen bei einigen NVMe-SSDs die "initialsetup"-Operationen mit dem Fehler "NOT AUTHORIZED" fehl. In vielen Fällen kann dieses Problem durch das vorherige Ausführen des "PSIDrevert"-Befehls behoben werden:

(Der PSID-Code der SSD befindet sich auf einem Aufkleber auf dem Laufwerk selbst.)

Achtung: Der Befehl PSIDrevert ist gefährlich! Er löscht normalerweise alle Daten auf dem Gerät. Daher sollte vorher unbedingt ein vollständiges Backup durchgeführt werden.

In meinem Fall – sowie in anderen Fällen, die im verlinkten Fehlerbericht dokumentiert sind – wurde das Laufwerk jedoch nicht gelöscht. Stattdessen wurde dadurch die "initialsetup"-Operation freigeschaltet. Ich vermute, dass bei meinem Laufwerk der PSIDrevert-Befehl die Festplatte nur löscht, wenn die OPAL-Sperre aktiviert ist, und ansonsten lediglich den Schutz für die Aktivierung der Verschlüsselung aufhebt. Mittlerweile habe ich das ebenfalls getestet: Meine gesperrte SSD ließ sich auf diese Weise vollständig löschen und entsperren.

Windows Update überschreibt den Linux Bootloader bei Dual-Boot-Systemen

Im Fehlerbericht 27 habe ich meine Lösung für das Problem dokumentiert, dass Windows Update den Grub-Bootloader bei einer Dual-Boot-Konfiguration von Windows und Linux beschädigt. Da mein UEFI-Setup die Standard-Fallback-Pfade verwendet, musste ich Grub an den Speicherorten /EFI/Boot und /EFI/Microsoft/Boot ablegen und den Windows-Bootloader in ein anderes Verzeichnis verschieben, z. B. /EFI/Windows.

Das Verschieben von Grub an diesen Speicherort war notwendig, wie in dem Fehlerbericht beschrieben (siehe z. B. den Kommentar von mesiu84). Der Grund ist, dass mein UEFI nach der Pre-Authentifizierung alle UEFI-Einträge von nicht verfügbaren Partitionen löscht und daher nie Grub am Standard-Speicherort (/EFI/gentoo in meinem Fall) startet, sondern immer auf die Fallback-Pfade /EFI/Microsoft/Boot oder /EFI/Boot zurückgreift.

Nun habe ich herausgefunden, dass mein UEFI nach der Pre-Authentifizierung und dem Entsperren der Laufwerke immer versucht, von der EFI-Partition des ersten Laufwerks zu booten. In meinem Setup habe ich zwei identische Laufwerke, beide mit aktiviertem Verschlüsselungsmechanismus.

Die Lösung: Windows Boot Manager auf ein zweites EFI-Volume verschieben

Meine Idee war: Was wäre, wenn ich den Windows Boot Manager auf eine zweite EFI-Partition auf dem zweiten Laufwerk verschieben könnte? Dann könnte ich Grub ausschließlich auf der EFI-Partition des ersten Laufwerks installieren und den Windows Bootloader von der zweiten EFI-Partition auf dem zweiten Laufwerk aus starten (Chainloading).

Der Vorteil: Windows Update würde nur die zweite EFI-Partition aktualisieren und nicht mehr die primäre EFI-Partition mit Grub überschreiben. Gleichzeitig würde mein UEFI nach dem Entsperren der Laufwerke weiterhin automatisch Grub von der EFI-Partition auf dem ersten Laufwerk starten.

Und tatsächlich funktioniert das! Meine Grub-Installation hat seitdem die Windows-Updates überlebt!

Mittlerweile weiss ich, dass diese Methode auch mit nur einem Laufwerk funktioniert, indem man dort zwei separate EFI-Partitionen anlegt.

Ausgangs-Partitionierung

• Laufwerk 1 (Disk 1):
  • EFI
  • Windows
  • Linux (System)
• Laufwerk 2 (Disk 2):
  • Linux (Daten)

Durchgeführte Schritte

1. Mit gparted die Linux-Partition auf Disk 2 verkleinert
2. Mit fdisk eine neue (leere) EFI-Partition auf Disk 2 erstellt (Partitionstyp 1, entsprechend dem Gentoo-Handbuch)
3. Windows starten
4. cmd als Administrator ausführen
5. Neue EFI-Partition auf Disk 2 mit diskpart als Laufwerk "Z:" einhängen:
   1. Verwende 'list disks', um eine Liste der Festplatten und deren Nummern anzuzeigen.
   2. Verwende 'sel disk <Nr.>', um das Laufwerk mit der neuen EFI-Partition auszuwählen.
   3. Verwende 'list par', um die Liste der Partitionen des ausgewählten Laufwerks anzuzeigen.
   4. Verwende 'sel par <Nr.>', um die EFI-Partition (Partition vom Typ "System") auszuwählen.
   5. Verwende 'assign letter="z"', um einen Laufwerksbuchstaben zuzuweisen.
   6. Verwende 'exit', um diskpart zu schließen.
6. Windows Bootloader mit bcdboot auf die neue EFI-Partition schreiben:
   bcdboot c:\windows /l de-de /s z: /f UEFI
7. Laufwerkbuchstaben der EFI-Partition mit diskpart im Administratormodus wieder entfernen:
   1. Verwende 'sel disk <Nr.>', um das Laufwerk mit der neuen EFI-Partition auszuwählen.
   2. Verwende 'sel par <Nr.>', um die EFI-Partition (Partition vom Typ "System") auszuwählen.
   3. Verwende 'remove letter="z"', um den Laufwerksbuchstaben zu entfernen.
   4. Verwende 'exit', um diskpart zu schließen.
8. Linux booten
9. Erste (ursprüngliche) EFI-Partition auf Disk 1 einhängen
10. Alle Dateien der EFI-Partition auf Disk 1 löschen
11. Grub neu installieren inklusive Removable Mode:
    linux ~ # grub-install --target=x86_64-efi --efi-directory=<Mountpoint der ersten EFI-Partition auf Disk 1>

    linux ~ # grub-install --target=x86_64-efi --efi-directory=<Mountpoint der ersten EFI-Partition auf Disk 1> --removable
12. Grub konfigurieren, um den Windows Bootloader auf Disk 2 zu starten
    1. UUID der zweiten EFI-Partition mit lsblk ermitteln (in meinem Fall: 6276-B891)
    2. Grub-Konfigurationsdatei anpassen und um den Chainload-Eintrag für die zweite EFI-Partition (Windows EFI) ergänzen:

       menuentry 'Windows 11 (disk2, /Microsoft/)' --class windows --class os $menuentry_id_option 'osprober-efi-6276-B891' --unrestricted '' {
               insmod part_gpt
               insmod fat
               if [ x$feature_platform_search_hint = xy ]; then
                 search --no-floppy --fs-uuid --set=root  6276-B891
               else
                 search --no-floppy --fs-uuid --set=root 6276-B891
               fi
               chainloader /EFI/Microsoft/Boot/bootmgfw.efi
       }
       

13. Sicherstellen, dass die Grub-EFI-Datei an allen "magischen" Orten auf der ersten EFI-Partition des ersten Laufwerks platziert sind (z.B. durch manuelles Erstellen der Verzeichnisse und Kopieren und Umbenennen der GRUB-EFI-Datei), die anscheinend wie folgt sind:
1. /EFI/BOOT/BOOTX64.EFI
2. /EFI/Microsoft/Boot/bootmgfw.efi
Dies kann das UEFI dazu bringen zu glauben, dass auf diesem Laufwerk ein Windows-Bootloader installiert ist, und es bevorzugt dann diese Partition gegenüber der zweiten EFI-Partition.