ubuntuusers.de

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).

• https://askubuntu.com/questions/647479/installing-to-external-usb-flash-hdd-uefi/647612

• https://askubuntu.com/questions/503796/how-to-make-a-portable-kubuntu-on-external-drive-gpt-on-uefi-computer

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.

• https://superuser.com/questions/684512/linux-on-external-drive-uefi

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).

Meine Sorge ist nämlich, dass durch diese Fahrlässigkeit von Ubiquity unzählige, potentiell an Ubuntu/Linux interessierte User verprellt werden. Und das auch noch völlig Unnötigerweise! Denn der Fehler ist zwar fatal, aber ebenso auch banal. Warum man diese Macke nicht behebt und stattdessen ahnungslose Nutzer in eine gemeine Falle laufen läßt, ist für mich nicht nachvollziehbar.

Der Installer ist keine KI, sondern ein Skript, in dem allerdings nicht alle Sonderfälle berücksichtigt werden.

Normal ist, dass man ein OS auf den internen Speicher installiert. Der Installer erkennt dabei auch noch ein Windows und evtl. andere vorhandene Betriebssysteme und frag dann sogar nach, was er machen soll, wenn er nicht genügend Speicherplatz findet.

Windows dagegen bügelt einfach alles Platt, um danach Partitionen anzulegen, welche dann die ganze Platte belegen.

Eine Installation auf einer externe HDD, die auch noch auf anderen Rechner laufen soll, ist nun wirklich nicht als Normalfall zu betrachten, sondern als absolute Ausnahme.

Das dies überhaupt funktioniert, ist verglichen mit Windows, schon fast ein Wunder.

Damit so etwas funktioniert, muss man das schon per Manuelle Partitionierung selber machen. Da kann man bereits vorher mit Gparted aus dem Live-System angelegte Partitionen einbinden oder diese während der Installation anlegen und dann auch die zweite esp einrichten und diese als esp zuweisen.

Mit Windows kann man so was gar nicht, ohne zusätzliches Programm und Tricks.

Ich bezweifle stark, dass der Durchschnittsumsteiger sein *ubuntu auf eine externe HDD installiert, weil solche Threads bezüglich Installationsproblemen hier im Forum nun wirklich die absolute Ausnahme sind. Mir persönlich sind erst zwei untergekommen - seit 2010.

Hej habkainzmer,

OT
habkainzmer schrieb:

... Du hast meinen Beitrag etwas zu sehr diagonal gelesen.

zunächst schon, alleine wegen der Verwendung von Virtualisierung - ich mache so etwas i.d.R. mit "freien" Platten/Sticks an realer hardware.

Sonst hättest Du bemerkt, dass die von Dir genannten Korrekturvorschläge schon in meinen Experimenten berücksichtigt sind.

1. waren das keine Korrekturvorschläge, sondern lediglich eine (äußerst knapp gefaßte - NVRAM Änderungen nicht berücksichtigend) Aufzählung dessen, was man für das von Dir beschriebene Vorhaben alles berücksichtigen muß

2. habe ich ja am Ende gelesen, daß es bei Dir funktioniert.

Ob sich das auch auf jedem echten Mainboard ganz ohne Ändern der Boot-Reihenfolge bewerkstelligen läßt

könnte schon sein, wenn denn

• die Reihenfolge von vorneherein in etwa so aussieht: 1. USB HDD, 2. int. HDD (resp. "Windows")

...Ist sie aber abgestöpselt, weiß der Rechner von nichts und es kommt wieder die vorherige Boot-Automatik zum Zuge

na, das liegt eben an den Einträgen im NVRAM. Ein nicht ausführbarer Eintrag wird dann einfach übergangen und der nächst funktionierende gewählt.

blacktencate@t520-xx:~$ sudo efibootmgr -v
[sudo] Passwort für blacktencate: 
BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 0019,000C,0007,0008,000A,0009,000B,000D,0006,000E,000F,0010,0011,0012,0013
[...]
Boot0007* USB FDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0008* ATAPI CD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
[...]
Boot000A* ATA HDD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
[...]
Boot000C* USB HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
[...]
Boot0019* ubuntu	HD(1,GPT,8298816c-d6e6-484a-b1d8-4f12c0fc1c22,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
blacktencate@t520-xx:~$ 

blacktencate@t520-xx:~$ sudo blkid
/dev/sda1: SEC_TYPE="msdos" UUID="682A-DD73" TYPE="vfat" PARTUUID="a705ea26-01"
[...]
/dev/sdd1: UUID="30C6-2927" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="8298816c-d6e6-484a-b1d8-4f12c0fc1c22"
/dev/sdd2: UUID="fb4ac3ba-50e4-486e-8a4e-16cfc911a1b9" TYPE="ext4" PARTUUID="533dac6a-1741-46b6-873c-bb2eadfe1fad"
blacktencate@t520-xx:~$

• eben mit Stick → sdd, ohne → sda

Weil Ubiquity nämlich den Starter für Ubuntu in die EFI-Partition der ersten Disk geschrieben hat.

ubiquity kann es halt nicht anders, sagte ich doch; da mußt du eben Hand anlegen.

Wo wird ein Hilfesuchender mit UEFI-Problemen im Rahmen des Ubuntu-Forums wohl suchen? Möglicherweise unter

Installation mit UEFI

möglich, besser aber unter EFI Externer-Datenträger und weiter Installation auf externen Speichermedien; ansonsten eben hier im Forum hoffen, daß sich jemand mit ausreichenden Kenntnissen seines Problems annimmt.
/OT

Gruß black tencate

bowman und black_tencate
Das habe ich mir in etwa schon so gedacht, dass nämlich konstruktive Kritik an real existierenden Problemen dadurch gelöst wird, indem man sie ignoriert und am Thema vorbei wegdiskutiert. Es ist auch nicht die Frage, ob ein solches Installationsszenario in den vergangenen 10 Jahren typisch war, sondern ob sowas in den kommenden 10 Jahren Standard werden könnte. Zumal Windows 10 in Verdacht steht, seine interne Platte mit versteckten Tricks verteidigen zu wollen.

Aber, mir geht es nicht darum, Recht zu behalten. Es ging mir nur darum, potentiellen Problemlösungssuchenden an passender Stelle, eine zusätzliche Hilfe bereit zu stellen.

Das ist erfolgt. Aus meiner Sicht ist somit alles gesagt. Und daher bin ich hier in diesem Thread fertig.

Gruß an alle.

Hej habkainzmer,

habkainzmer schrieb:

... Das habe ich mir in etwa schon so gedacht, dass nämlich konstruktive Kritik an real existierenden Problemen

verstehe ich das richtig: Du bemängelst die nicht vorhandene Fähigkeit von ubuquity, bei Vorhandensein von 2x esp im System eine davon nach user Vorgabe auswählen zu können? Falls ja, dann bist Du hier bei UUde aber an der falschen Stelle! (hier lesen für gewöhnlich keine entsprechenden Entwickler mit)

...indem man sie ignoriert und am Thema vorbei wegdiskutiert.

wie kannst Du von ignorieren und wegdiskutieren reden, wo ich dich doch auf mehrere - genau in die Problematik passende - Wikiseiten aufmerksam gemacht habe? Schon alleine die Tatsache, daß sich gleich mehr als ein user mit der von dir hier hineingeworfenen Thematik beschäftigen, kannst Du doch nicht mit ignorieren abtun. Btw.: Eigentlich ist das ja eine Themenentführung (von dir), denn beim TO geht es doch gar nicht um 2x esp oder Installation auf ext. Datenträger. (Er hat imho schlicht an allen möglichen "Knöpfen" gedreht und geschaltet, bis er selber nicht mehr durchgeblickt hat.)

Es ist auch nicht die Frage, ob ein solches Installationsszenario in den vergangenen 10 Jahren typisch war, sondern ob sowas in den kommenden 10 Jahren Standard werden könnte.

hmm, die Verwendung von 2x esp - darum geht es doch, oder(?) - ist doch schon mit jeder DVD/USB LiveSystem Standard, schau einfach mal auf so einen Stick (der bringt immer seine eigene esp mit).

blacktencate@t520-xx:~$ sudo parted -l
[sudo] Passwort für blacktencate: 
Modell: ATA Crucial_CT120M50 (scsi)
Festplatte  /dev/sda: 
[...]

Modell:  USB DISK 2.0 (scsi)
Festplatte  /dev/sdd:  2007MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags
 1      1049kB  2007MB  2006MB  primary  fat32

(# Anm.: Vor dem Beschreiben)

blacktencate@t520-xx:~$ sudo dd if=ubuntu-18.04-desktop-amd64.iso of=/dev/sdd bs=1M && sync
1832+1 Datensätze ein
1832+1 Datensätze aus
1921843200 bytes (1,9 GB, 1,8 GiB) copied, 73,3544 s, 26,2 MB/s
blacktencate@t520-xx:~$ sudo  sudo fdisk -l
Medium /dev/sda:
[...]
Medium /dev/sdd: 1,9 GiB, 2006974464 Bytes, 3919872 Sektoren
Einheiten: sectors von 1 * 512 = 512 Bytes
Sektorengröße (logisch/physisch): 512 Bytes / 512 Bytes
I/O Größe (minimal/optimal): 512 Bytes / 512 Bytes
Typ der Medienbezeichnung: dos
Medienkennung: 0x2b192737

Gerät      Boot   Start    Ende Sektoren Größe Id Typ
/dev/sdd1  *          0 3753599  3753600  1,8G  0 Leer
/dev/sdd2       3672780 3677451     4672  2,3M ef EFI (FAT-12/16/32)

(# Anm.: Nach dem Beschreiben)

blacktencate@t520-xx:~$ 

Zumal Windows 10 in Verdacht steht, seine interne Platte mit versteckten Tricks verteidigen zu wollen.

ich prophezeihe mal: Wirklich 'gelingen' wird denen das nicht.

...Es ging mir nur darum, potentiellen Problemlösungssuchenden an passender Stelle, eine zusätzliche Hilfe bereit zu stellen.

wenn Du Deinen Bericht hier in einem thread 'vergräbst', muß derjenige, der Hilfe sucht, aber schon viel Glück haben, um darauf zu stoßen.

Vorschlag: Schreib eine Wikiseite dazu, oder evt. auch (nur) ein HowTo, dann ist die Wahrscheinlichkeit, daß es 'gefunden' wird, deutlich größer.

Gruß black tencate

Hallo @black_tencate
Du hast meinen Beitrag etwas zu sehr diagonal gelesen. Sonst hättest Du bemerkt, dass die von Dir genannten Korrekturvorschläge schon in meinen Experimenten berücksichtigt sind.

Start von GParted im Live-Ubuntu, um zweite Disk UEFI-konform zu erstellen (GPT-Stil, EFI-Partition (500 MB) mit den Flags boot + esp)

Was denkst Du denn, was ich damit sagen will? 😉

Falls Du mir nicht glaubst, ich werde nachher vor dem Abschicken des Posts versuchen, 3 der rund 60 Screenshots von den Experimenten hochzuladen. Bild 23, beispielsweise, zeigt den Zustand der vorpräparierten, zweiten Disk, auf die dann anschließend der Installer (ubiquity) Ubuntu 18 draufmachen soll. An der EFI-Partition auf sdb, die der Installer zum Verankern der Installation benutzen soll, ist doch nichts auszusetzen!? Erst recht nicht, wenn mithilfe (einer) der Behelfslösungen sich eine funktionierende, autonom boot-fähige Disk mit Ubuntu erstellen läßt! Und wie gesagt, ich habe die virtuelle Zweitdisk anschließend noch an einer ad hoc erzeugten, weiteren EFI-VM (mit Windows 7) getestet und auch da startet Ubuntu auf Anhieb out of the box. Lediglich vor dem allerersten Start an diesem virtuellen Fremdrechner mußte ich ins virtuelle EFI gehen und manuell den Eintrag mit der zweiten EFI-Disk wählen. Aber nach der ersten Ubuntu-Session konnte ich mich davon überzeugen, daß auch der namentliche Eintrag ubuntu nun vorhanden war und zwar an oberster Stelle. Sodass alle folgenden Starts wie folgt abliefen:

• mit angeschlossener zweiten EFI-Disk startet Ubuntu

• ohne angeschlossene zweite EFI-Disk startet Windows

Und zwar ohne jeweils auch nur ein einziges Mal die Boot-Reihenfolge im EFI ändern zu müssen!

Ob sich das auch auf jedem echten Mainboard ganz ohne Ändern der Boot-Reihenfolge bewerkstelligen läßt, kann ich nicht mit Sicherheit sagen. Im virtuellen EFI von VMWare und ebenso im physikalischen EFI meines MSI-Rechners ist jedenfalls bei einer solch simplen Ausgangslage keine Änderung der Boot-Reihenfolge nötig.

Nach der gleichen Methode hatte ich übrigens vor rund einem halben Jahr meine echte, portable EFI-Disk aufgebaut. Die 3 darauf installierten Linux-Distros geniessen Vorrang, wenn die USB3-HDD am Rechner angeschlossen ist. Ist sie aber abgestöpselt, weiß der Rechner von nichts und es kommt wieder die vorherige Boot-Automatik zum Zuge. Nur dass die interne Boot-Disk damals von mir in MBR-Stilistik organisiert worden war. Ubiquity konnte also gar nicht in eine falsche EFI-Partition schreiben, weil es ohnehin nur eine gab.

Ich habe mir übrigens die virtuelle EFI-Partition sowohl nach der mißglückten Variante als auch nach erfolgreichen Modifikation angesehen. Der Inhalt des Subordners ubuntu sah in beiden Fällen gleich aus (Bild 42). Nur war bei der mißglückten Variante auch noch ein Subordner für Windows mit drin (,weil auf der ersten Disk) und diese zugehörige EFI-Partition war in /boot eingehängt (statt der EFI-Partition auf der zweiten Disk, wie es bei einer portablen (autonomen) Installation hätte sein müssen).

Gehen wir gedanklich den Boot-Mechanismus beim zunächst mißglückten Experiment noch einmal durch bis zum Sichtbarwerden des Fehlers:

• erster Start der VM: virtuelle Windows-DVD bootet automatisch. Warum? Weil das in dem Moment noch das einzige überhaupt boot-fähige Medium darstellt.

• zweiter Start der VM: das installierte Windows bootet automatisch. Warum? Weil die virtuelle EFI-HDD eine höhere Priorität hat als die DVD.

• dritter Start der VM: um von der virtuellen Ubuntu-Live-DVD booten zu können, muß ich sie im EFI händisch auswählen. Warum? Siehe vorheriges Statement.

• vierter Start der VM: das installierte Ubuntu startet automatisch. Warum? Weil Ubuntu sich mit einem gleichnamigen Eintrag an die Spitze der EFI-Pyramide gesetzt hat (noch vor dem Windows Boot Manager; siehe Bild 36)

• fünfter Start der VM: nach Entfernen der zweiten Disk startet NICHT wie erwartet Windows, sondern ein schmuckloser Grub-Screen mit einer Eingabezeile. Warum? Ja, Himmel Herrgott warum!!

Weil im virtuellen EFI von VMware der derzeit obsolete Ubuntu-Eintrag nicht entfernt wurde. Aber das ist gar nicht entscheidend! Das virtuelle EFI prüft nämlich trotzdem, ob der fragliche Eintrag mit einem auf einem momentan angeschlossenen Datenträger verknüpft ist. Und schockierender- sowie fälschlicherweise ist er das immer noch!

Weil Ubiquity nämlich den Starter für Ubuntu in die EFI-Partition der ersten Disk geschrieben hat. Daher ist aus Sicht von EFI alles OK. Es übergibt somit die Kontrolle an den Ubuntu-Starter (Grub), welcher nunmehr völlig verdattert dasteht, weil er die zugehörige Partition mit Ubuntu nicht finden kann (, die ja auf der momentan entfernten Disk liegt). Der arme Grub kann in dieser misslichen Situation aber nicht einfach die Kontrolle an EFI zurückreichen:

Hör mal, liebes EFI, ich habe hier ein unerwartetes Problem. Kannst du mal schaun, ob es vielleicht noch einen anderen Boot-Starter gibt, der den Job machen kann. Ich blicke hier gerade nicht mehr durch!

Nee, das geht leider nicht! Ergo, leerer Screen im Eingabe-Modus. Sieh zu User, was Du draus machst!

War der Starter für Ubuntu hingegen auf die zweite Disk geschrieben worden, bemerkt EFI beim Überlesen der Boot-Reihenfolge sofort, daß mit ubuntu derzeit nichts verknüpft ist. Also weiter im Text. Wer kommt als nächstes? Ein gewisser Windows Boot Manager. Na, dann vielleicht der.

Damit ist man dann wieder beim fünften Start der VM. Nunmehr aber mit dem richtigen Ergebnis.

Bleibt noch die Frage, warum ich das alles hier und auch noch so ausführlich darlege.
Meine Sorge ist nämlich, dass durch diese Fahrlässigkeit von Ubiquity unzählige, potentiell an Ubuntu/Linux interessierte User verprellt werden. Und das auch noch völlig Unnötigerweise! Denn der Fehler ist zwar fatal, aber ebenso auch banal. Warum man diese Macke nicht behebt und stattdessen ahnungslose Nutzer in eine gemeine Falle laufen läßt, ist für mich nicht nachvollziehbar. Deswegen ist mein Post eher an den Thread als an den Threadstarter gerichtet.

Wo wird ein Hilfesuchender mit UEFI-Problemen im Rahmen des Ubuntu-Forums wohl suchen? Möglicherweise unter

Installation mit UEFI