Vor ein paar Tagen habe ich ein Experiment durchgeführt, dessen Ergebnisse ganz gut in diesen Thread passen.
Und zwar wollte ich testen, ob man Ubuntu 18 LTS auf eine externe Disk installieren kann bei nachfolgender Ausgangslage:
interne Disk ist im GPT-Stil mit boot-fähiger EFI-Partition (Flags: boot, esp)
auf der internen Disk befindet sich bereits (mindestens) ein installiertes OS (zu starten als UEFI-System)
externe Disk wird für UEFI vorbereitet (eigene EFI-Partition (Flags: boot, esp) )
Ubuntu ist portabel auf die externe Disk zu installieren (d.h., es verankert sich ausschließlich in der externen EFI-Partition)
Auf den Punkt gebracht: es geht um das Verhalten, wenn mehrere boot-fähige Festplatten in einem reinen UEFI-System angeschlossen sind.
Dazu muß man sagen, dass reine UEFI-Systeme (also ohne Legacy-Option) schon jetzt der Stand der Dinge bei neuer Hardware sind. Lediglich die Option Secure Boot ein- oder auszuschalten, bleibt bestehen, weil dies Teil der UEFI-Spezifikation ist. (Andernfalls wäre das ein Fall für die Kartellbehörden. Was würden die wohl sagen, wenn beispielsweise LIDL oder PENNY jedesmal die Eröffnung einer neuen Filiale bei ALDI kostenpflichtig beantragen müßten!?)
Hinzu kommt, dass externe (portable) Festplatten immer größer (1 TB und mehr) , immer schneller (USB 3), immer handlicher (klein und ohne eigenen Stromanschluß) und immer billiger (ca. 50 € für 1 TB) geworden sind. Unter diesen Umständen, wird es immer wichtiger, dass Ubuntu und alle anderen Linuxe sich auf externe Disks ebenso problemlos aufspielen lassen, wie auf die interne Festplatte!
Wie immer probiere ich sowas erstmal in einer VM aus. (Nativ besteht für mich persönlich derzeit noch kein Bedarf.)
Als Kennzeichen für den erfolgreichen Abschluß des Experiments wurden folgende Merkmale vorab definiert:
zweites OS bootet automatisch, wenn beide Disks angeschlossen sind
erstes OS bootet automatisch, wenn nur die erste Disk angeschlossen ist
zweites OS bootet autonom, wenn es an einen anderen Rechner angeschlossen wird
Folgendes Szenario habe ich zu diesem Zweck aufgebaut:
Virtualisierungsprogramm gewählt (im Test: VMware Player 12, hier unter Windows 7)
VM mit (zunächst) einer virtuellen Disk kreiert (im Test: Windows 10 (17 03), Home, 64 Bit. Abweichende Standardeinstellungen: reines Host Only Netzwerk; 4 GB RAM; 2 CPUs)
im VMX-File der VM vor erstem Start den Eintrag firmware = "efi" hinzugefügt (um Installation im EFI-Modus zu erzwingen)
Windows-Installation durchgeführt (Windows generiert automatisch die EFI-Stilistik der virtuellen Disk)
zweite virtuelle Disk erstellt und angebunden (noch ohne Spezifizierung)
ISO mit Linux-Distribution (im Test: Ubuntu 18 LTS) als virtuelles CD/DVD-Laufwerk eingebunden
Start der VM über das virtuelle EFI (F2 drücken), um Start per ISO (als Live-System) zu erzwingen
Start von GParted im Live-Ubuntu, um zweite Disk UEFI-konform zu erstellen (GPT-Stil, EFI-Partition (500 MB) mit den Flags boot + esp)
Installer-Programm aufgerufen, um Ubuntu im Modus Etwas Anderes zu installieren (Partition in EXT4-Format, Einhängepunkt /, Ort des Bootloader auf externe Disk (, Swap-Partition optional))
Beide OSe waren anschließend lauffähig installiert. Die Überprüfung des virtuellen EFIs ergab, dass ubuntu an oberster Stelle eingetragen war vor dem Windows Boot Manager an zweiter Stelle. (Windows 10 ließ sich überdies auch durch das von Ubuntu generierte Grub-Menü starten. Zu diesem Zeitpunkt wußte ich noch nicht, dass dies ein Indiz für das Scheitern des Experiments im Sinne meiner Zielvorgaben zu deuten war.)
Nach dem Entfernen der zweiten virtuellen Disk kam jedoch die böse Überraschung! (Zum Glück ohne Folgen, da in einer Test-VM).
Der nächste Boot startete nicht wie erwartet Windows, sondern versackte in einer ansonsten leeren Grub-Konsole. Damit war bewiesen, dass der Ubuntu-Installer entgegen meiner Anweisung, die Ubuntu-Installation über die EFI-Partition der internen Disk anstatt der externen Disk verankert hatte! Man könnte an dieser Stelle einwenden, dass das Rechner-System ja noch intakt ist. Man bräuchte doch nur die Boot-Reihenfolge im EFI (jedesmal) manuell abzuändern, um wieder booten zu können (in dem Fall also Windows). Das ist aber keine wirkliche Lösung und schon gar keine saubere. Es beantwortet auch nicht die Frage, warum der Ubuntu-Installer zwar alle EFI-Partitionen zur Auswahl anbietet, aber die Installation dann trotzdem eigenmächtig auf die erste EFI-Partitition umbiegt, ohne den Benutzer darüber zu informieren bzw. zu warnen?!
Die anschließende Recherche im Internet ergab, dass das Problem seit langem bekannt ist (, aber anscheinend noch immer nicht gelöst).
Die gute Nachricht ist, dass das Problem zwar nicht beseitigt, es aber immerhin halbwegs akzeptable Behelfslösungen gibt:
Abstecken der ersten Disk (interne) vor der Installation von Ubuntu (ideal für den, der sich das (zu)traut)
Ausmaskieren der internen EFI-Partition (in GParted temporär die Flags boot + esp löschen (ändern auf msftdata) )
Beide Behelfslösungen habe ich in der VM anschließend ausprobiert und beide funktionieren (Zielvorgabe somit erreicht).
Die Ausmaskierung macht man wieder rückgängig, sobald die Installation von Ubuntu (nach Neustart) abgeschlossen ist. Das geht am einfachsten, indem man nochmals das Ubuntu-Live-System startet, da GParted im installierten Ubuntu vorab noch nicht enthalten ist. Achtung! Es reicht nicht, die interne EFI-Partion im Installer vor Installationsstart auf 'nicht benutzen' zu setzen. Auch das wird nämlich vom Installer ignoriert.
Die externe, virtuelle Disk ließ sich übrigens auch an eine andere VM (im EFI-Modus) erfolgreich anschließen (im Test: VM mit Windows 7)
Zum Schluß noch ein paar Anmerkungen:
Installation teste ich vorab immer in einer VM bevor ich sie ggf. nativ ausprobiere (ich mag keine Überraschungen)
Spezielle Installationsszenarien unter Einbeziehung von BIOS bzw. UEFI teste ich immer mit dem VMware Player (statt VirtualBox), da VMware auch ein virtuelles BIOS/EFI generiert (NVRAM-Datei). Die Startverzögerung des virtuellen BIOS/EFI läßt sich anpassen (einfach mal googlen).
Das virtuelle BIOS/EFI im VMware Player ist zwar präzise aber nur rudimentär. Leichte Abweichnungen gegenüber einem nativen EFI sind nicht auszuschließen. Beispielsweise blendet mein MSI-Board aktuell nicht zugängliche Boot-Einträge automatisch aus. Das virtuelle EFI tut das nicht; es übergeht aber aktuell nicht zugängliche Boot-Einträge automatisch. Das funktioniert natürlich nicht, wenn zwar das zugehörige Installationsmedium entfernt wurde, nicht aber die verantwortliche EFI-Partition (das ist auf einem echten System natürlich genauso).
Secure Boot ist unter dem VMware Player standardmäßig immer abgeschaltet. Auf einem nativen System kann das aber anders sein und sollte im Zweifelsfalle immer abgeschaltet werden (Ubuntu geht zwar mit Secure Boot; viele andere Linuxe aber nicht).
auf einem nativen System sind auch immer sogenannte Fast-Boot-Optionen angeboten, die ebenfalls abzuschalten sind, wenn auch Linux-OSe betrieben werden sollen.
Die in diesem Beitrag angesprochene Problematik besteht nur, wenn mehrere EFI-Partitionen vorhanden sind. Sie besteht also nicht, wenn die interne Disk im Legacy-Format vorliegt (also mit MBR statt EFI-Partition).
Moderiert von redknight:
abgetrennt von https://forum.ubuntuusers.de/topic/installation-mit-uefi/