Hi
Hat schon mal jemand das oben genannte ausprobiert? Also auf eine mit eDrive verschlüsselten Windows-Installation noch eine Partition auf der SSD dahinter für Linux angelegt und die gebootet? Klappt das?
Immerhin scheint bei eDrive ja zwischen der Boot-Partition für Bootloader und Bitlocker-Verschlüsselung und der eigentlichen System-Partition unterschieden zu werden. Auf erstere kann zugegriffen werden, davon wird ja bis zur Passwortabfrage gebootet, auf letztere kann dagegen erst nach Eingabe des Passworts + TPM oder Eingabe des Wiederherstellungsschlüssels zugegriffen werden. Wie verhält es sich mit einer weiteren Partition und einer eventuellen Linux-Installation darin?
- - - Beitrag zusammengeführt - - -
OK, Versuch macht kluch, dachte ich mir, und habe es (nach einer Datensicherung) einfach ausprobiert:
- Partitionen verkleinern musste ich nicht, da ich hinter Windows eh noch etwas Platz freigelassen hatte (Over Provisioning)
- Mir Rufus das Ubuntu-ISO ausgewählt und manuell den ISO-Modus auf den DD-Modus umgestellt, so dann meinen Stick bespielt.
- Im UEFI ausgewählt, dass einmalig der Stick an erster Stelle der Bootreihenfolge stehen soll.
- Ubuntu gebootet und festgestellt, dass ich direkt auf die Windows-Partition zugreifen kann.
- Recher einmal ausgeschaltet und wieder eingeschaltet, wieder vom Stick gebootet, jetzt ist die Windows-Partition nicht mehr lesbar, nur die EFI- und die Recovery/Boot-Partition von Windows. OK, so soll es ja auch sein.
- gparted geöffnet und eine Root- und eine Swap-Partition in dem freien Bereich angelegt. Dabei zig mal die Fehlermeldung von gparted weggeklickt, dass es Probleme beim Zugriff auf die Partitionen gab (es kann halt auch die Windows-Partition nicht lesen). Die neu angelegten Partitionen können aber angesprochen werden. Cool - bis hier hin siehts schon mal gut aus
Windows wird weiterhin geschützt, Linux arbeitet ganz normal, wie es scheint.
- Ubuntu in die frisch angelegten Partitionen installiert. Das hat aber ewig gedauert, insbesondere die Punkte der Kernel-Installation, die Installation des Grub-Pakets und der update-grub-Befehl haben ewig gerödelt. Dabei leuchtete die HDD-Lampe am Gehäuse dauerhaft und in dem erweiterten Log, den man unten aufklappen kann, gab es im Sekundentakt Fehlermeldungen beim Zugriff auf den Datenträger. Nach einer knappen Stunde war aber alles durch, ohne dass ich irgendwo eingegriffen habe.
- Nach dem Reboot lud sofort wieder Windows.
- Bootreihenfolge im UEFI bestätigte, dass es nun zwei EFI-Einträge gibt und der Windows-Eintrag gerade vorne steht.
- Bootreihenfolge also auf "ubuntu" umgestellt und neu gestartet.
- Jetzt kommt die GRUB-Auswahl, Linux bootet auch einwandfrei, Windows will nun aber den BitLocker-Recovery-Key.
- Nach der Eingabe des Recovery-Keys bleibt Windows beim booten direkt bei dem blauen Hintergrund der BitLocker-Eingabe hängen. Aber ohne, dass es eine Eingabe erfordert oder irgendwas anzeigt.
- Auch nach Reboots bootet Windows nicht mehr
Linux bootet aber einwandfrei und kann auf die Windows-Partition zugreifen.
- Also einmal richtig herunterfahren und vom Strom trennen, wieder einschalten, jetzt will Windows wieder die PIN und danach den Recovery-Key.
- Ich kann nun Windows und Linux booten und per GRUB auswählen. Nur: Windows will bei jedem Boot den Recovery-Key
- Im UEFI wieder Windows als ersten Booteintrag auszuwählen ändert nichts, Windows will immer den Recovery Key.
OK, also Dual-Boot läuft, aber BitLocker ist zickig. Also weiter getestet:
- Windows als erster Booteintrag und BitLocker einmal deaktivieren und wieder aktivieren: Windows und BitLocker/eDrvie laufen wieder normal. Aber Linux kann ich so natürlich nicht booten...
- Ubuntu als erster Booteintrag und ich kann Ubuntu booten. Windows aber erst nach Eingabe des Recovery-Keys. Daran ändert sich auch nichts, wenn man BitLocker einmal deaktiviert und wieder aktiviert. Führt man beim Aktivieren die "Systemüberprüfung" aus, aktiviert sich BitLocker auch gar nicht erst.
Wenn Windows mit eDriver/BitLocker also nur bootet, wenn es den ersten Booteintrag beanspruchen darf, dann muss ich also den umgekehrten Weg gehen: Nicht Windows via GRUB booten, sondern Linux via Windows-Boot-Manager booten.
Via Google bin ich dabei hier drauf gestoßen:
http://www.andysblog.de/dualboot-mit-windows-8-bitlocker-und-debian-wheezy
http://machine-cycle.blogspot.nl/2012/02/dual-boot-windows-7-and-debian-gnulinux.html
http://social.technet.microsoft.com...-with-bitlocker-tpm-and-a-non-windows-os.aspx
Scheint also ein bekanntes Problem zu sein, aber möglich, es zu lösen. Man muss nur den Windows-Bootloader wieder im MBR installieren bzw. GRUB gar nicht erst in den MBR schreiben, sondern nur auf die Partition von Linux. Dann muss man eine Kopie dieses Bootsektors anlegen und sie mit bcdedit in den Windows-Bootmanager einbinden. Das werde ich gleich mal probieren und meinen Eintrag hier kurz editieren.
//EDIT: Scheint wohl doch nicht so einfach möglich zu sein. Die obigen Tipps funktionieren alle nur, wenn Windows und Ubuntu im Legacy-Modus installiert wurden. Im EFI-Modus klappt das nicht... Hier hat jemand das gleiche Problem und keine Lösung: http://serverquestions.com/question...start-efi-ubuntu-shimx64-efi-ubuntu-through-w Habe auch schon den rEFInd Bootloader probiert, aber der hat das gleiche Problem wie Grub. Sobald Windows via Grub oder via rEFInd gestartet wurden, mögen sie beim Booten nicht mehr den Key aus dem TPM holen... Scheint also doch nicht zu gehen oder ich muss immer via UEFI den jeweiligen Bootloader "switchen". Umständlich aber bisher die einige Möglichkeit, die mir noch einfällt...
//EDIT2: Dabei bleibt's nun wohl erst einmal. Anders will es einfach nicht laufen. Im UEFI ist nun ausgewählt, dass standardmäßig Windows bootet. Der fragt mich nach meiner BitLocker PIN und bootet dann ohne RecoveryKey und mit funktionierendem eDrive. Wenn ich dagegen das booten direkt unterbreche und im UEFI dann manuell Ubuntu auswähle, kommt Grub und ich boote dort mein Ubuntu. Nicht so schön wie direkt in GRUB auswählen zu können, aber immerhin funktioniert mein DualBoot trotz eDrive so.
Hat schon mal jemand das oben genannte ausprobiert? Also auf eine mit eDrive verschlüsselten Windows-Installation noch eine Partition auf der SSD dahinter für Linux angelegt und die gebootet? Klappt das?
Immerhin scheint bei eDrive ja zwischen der Boot-Partition für Bootloader und Bitlocker-Verschlüsselung und der eigentlichen System-Partition unterschieden zu werden. Auf erstere kann zugegriffen werden, davon wird ja bis zur Passwortabfrage gebootet, auf letztere kann dagegen erst nach Eingabe des Passworts + TPM oder Eingabe des Wiederherstellungsschlüssels zugegriffen werden. Wie verhält es sich mit einer weiteren Partition und einer eventuellen Linux-Installation darin?
- - - Beitrag zusammengeführt - - -
OK, Versuch macht kluch, dachte ich mir, und habe es (nach einer Datensicherung) einfach ausprobiert:
- Partitionen verkleinern musste ich nicht, da ich hinter Windows eh noch etwas Platz freigelassen hatte (Over Provisioning)
- Mir Rufus das Ubuntu-ISO ausgewählt und manuell den ISO-Modus auf den DD-Modus umgestellt, so dann meinen Stick bespielt.
- Im UEFI ausgewählt, dass einmalig der Stick an erster Stelle der Bootreihenfolge stehen soll.
- Ubuntu gebootet und festgestellt, dass ich direkt auf die Windows-Partition zugreifen kann.
- Recher einmal ausgeschaltet und wieder eingeschaltet, wieder vom Stick gebootet, jetzt ist die Windows-Partition nicht mehr lesbar, nur die EFI- und die Recovery/Boot-Partition von Windows. OK, so soll es ja auch sein.
- gparted geöffnet und eine Root- und eine Swap-Partition in dem freien Bereich angelegt. Dabei zig mal die Fehlermeldung von gparted weggeklickt, dass es Probleme beim Zugriff auf die Partitionen gab (es kann halt auch die Windows-Partition nicht lesen). Die neu angelegten Partitionen können aber angesprochen werden. Cool - bis hier hin siehts schon mal gut aus
Windows wird weiterhin geschützt, Linux arbeitet ganz normal, wie es scheint.- Ubuntu in die frisch angelegten Partitionen installiert. Das hat aber ewig gedauert, insbesondere die Punkte der Kernel-Installation, die Installation des Grub-Pakets und der update-grub-Befehl haben ewig gerödelt. Dabei leuchtete die HDD-Lampe am Gehäuse dauerhaft und in dem erweiterten Log, den man unten aufklappen kann, gab es im Sekundentakt Fehlermeldungen beim Zugriff auf den Datenträger. Nach einer knappen Stunde war aber alles durch, ohne dass ich irgendwo eingegriffen habe.
- Nach dem Reboot lud sofort wieder Windows.
- Bootreihenfolge im UEFI bestätigte, dass es nun zwei EFI-Einträge gibt und der Windows-Eintrag gerade vorne steht.
- Bootreihenfolge also auf "ubuntu" umgestellt und neu gestartet.
- Jetzt kommt die GRUB-Auswahl, Linux bootet auch einwandfrei, Windows will nun aber den BitLocker-Recovery-Key.
- Nach der Eingabe des Recovery-Keys bleibt Windows beim booten direkt bei dem blauen Hintergrund der BitLocker-Eingabe hängen. Aber ohne, dass es eine Eingabe erfordert oder irgendwas anzeigt.
- Auch nach Reboots bootet Windows nicht mehr
Linux bootet aber einwandfrei und kann auf die Windows-Partition zugreifen.- Also einmal richtig herunterfahren und vom Strom trennen, wieder einschalten, jetzt will Windows wieder die PIN und danach den Recovery-Key.
- Ich kann nun Windows und Linux booten und per GRUB auswählen. Nur: Windows will bei jedem Boot den Recovery-Key
- Im UEFI wieder Windows als ersten Booteintrag auszuwählen ändert nichts, Windows will immer den Recovery Key.
OK, also Dual-Boot läuft, aber BitLocker ist zickig. Also weiter getestet:
- Windows als erster Booteintrag und BitLocker einmal deaktivieren und wieder aktivieren: Windows und BitLocker/eDrvie laufen wieder normal. Aber Linux kann ich so natürlich nicht booten...
- Ubuntu als erster Booteintrag und ich kann Ubuntu booten. Windows aber erst nach Eingabe des Recovery-Keys. Daran ändert sich auch nichts, wenn man BitLocker einmal deaktiviert und wieder aktiviert. Führt man beim Aktivieren die "Systemüberprüfung" aus, aktiviert sich BitLocker auch gar nicht erst.
Wenn Windows mit eDriver/BitLocker also nur bootet, wenn es den ersten Booteintrag beanspruchen darf, dann muss ich also den umgekehrten Weg gehen: Nicht Windows via GRUB booten, sondern Linux via Windows-Boot-Manager booten.
Via Google bin ich dabei hier drauf gestoßen:
http://www.andysblog.de/dualboot-mit-windows-8-bitlocker-und-debian-wheezy
http://machine-cycle.blogspot.nl/2012/02/dual-boot-windows-7-and-debian-gnulinux.html
http://social.technet.microsoft.com...-with-bitlocker-tpm-and-a-non-windows-os.aspx
Scheint also ein bekanntes Problem zu sein, aber möglich, es zu lösen. Man muss nur den Windows-Bootloader wieder im MBR installieren bzw. GRUB gar nicht erst in den MBR schreiben, sondern nur auf die Partition von Linux. Dann muss man eine Kopie dieses Bootsektors anlegen und sie mit bcdedit in den Windows-Bootmanager einbinden. Das werde ich gleich mal probieren und meinen Eintrag hier kurz editieren.
//EDIT: Scheint wohl doch nicht so einfach möglich zu sein. Die obigen Tipps funktionieren alle nur, wenn Windows und Ubuntu im Legacy-Modus installiert wurden. Im EFI-Modus klappt das nicht... Hier hat jemand das gleiche Problem und keine Lösung: http://serverquestions.com/question...start-efi-ubuntu-shimx64-efi-ubuntu-through-w Habe auch schon den rEFInd Bootloader probiert, aber der hat das gleiche Problem wie Grub. Sobald Windows via Grub oder via rEFInd gestartet wurden, mögen sie beim Booten nicht mehr den Key aus dem TPM holen... Scheint also doch nicht zu gehen oder ich muss immer via UEFI den jeweiligen Bootloader "switchen". Umständlich aber bisher die einige Möglichkeit, die mir noch einfällt...
//EDIT2: Dabei bleibt's nun wohl erst einmal. Anders will es einfach nicht laufen. Im UEFI ist nun ausgewählt, dass standardmäßig Windows bootet. Der fragt mich nach meiner BitLocker PIN und bootet dann ohne RecoveryKey und mit funktionierendem eDrive. Wenn ich dagegen das booten direkt unterbreche und im UEFI dann manuell Ubuntu auswähle, kommt Grub und ich boote dort mein Ubuntu. Nicht so schön wie direkt in GRUB auswählen zu können, aber immerhin funktioniert mein DualBoot trotz eDrive so.
Zuletzt bearbeitet:
