Bootbares Linux auf einer externe USB SSD installieren

[Garmor]

Ich hab gestern spaßenshalber mal Ubuntu auf eine externe SSD installiert. Das interne System lag auf /sda, die externe war /sdb. Im Installer hab ich als Ort für den Bootloader eine neue ESP in /sdb1 angegeben und die ESP auf /sda1 explizit als "nicht benutzen" markiert. Am Ende wurde der Bootloader dementsprechend wie gewünscht in /sda1 installiert.

Man muss eben nur wissen, wie ma... oh. Ich hasse Ubiquity.

 

[Creeping.Death]

Das Traurige daran ist, dass dieser Umstand schon sehr lange bekannt ist, aber nicht gefixt wird.
Ich finde die Idee einer vollwertigen und portablen Linux-Installation klasse. Aber dieser Umstand macht es unnötig kompliziert.

 

[wolle17]

Ich setzte eine VM auf und schiebe das dann auf die externe Platte.

Was meinst Du mit "VM"?

 

[Lotsenbruder]

VM = Virtuelle Maschine

 

[wolle17]

Klar! - bin nicht drauf gekommen!

 

[@mo]

Ich hab gestern spaßenshalber mal Ubuntu auf eine externe SSD installiert. Das interne System lag auf /sda, die externe war /sdb. Im Installer hab ich als Ort für den Bootloader eine neue ESP in /sdb1 angegeben und die ESP auf /sda1 explizit als "nicht benutzen" markiert. Am Ende wurde der Bootloader dementsprechend wie gewünscht in /sda1 installiert.

Man muss eben nur wissen, wie ma... oh. Ich hasse Ubiquity.

Einfach eine Minimalinstallation mit Lubuntu (Calamares, nicht Ubiquity) durchführen und den gewünschten Desktop nachinstallieren und gut is.
Aber klar, warum einfach, wenn's umständlich geht...!?
Ärgerlich eben, dass ja durchaus Ubiquity ständig verbessert wird, nur da machen sie nix!

 

[OMGWTFBBQ]

Hab letztens EndeavourOS auf eine externe SSD installiert und da wurde der Bootloader auch auf die externe installiert. Windows und seine EFI Partition wurden nicht angefast. OS lässt sich via BIOS wechseln.

Ich denke alle Installationen die mit Calamares laufen, werden sich so verhalten.

 

[7vor10]

Hab letztens EndeavourOS auf eine externe SSD installiert und da wurde der Bootloader auch auf die externe installiert. Windows und seine EFI Partition wurden nicht angefast. OS lässt sich via BIOS wechseln.

Ich denke alle Installationen die mit Calamares laufen, werden sich so verhalten.

Gut zu wissen. Das ist das erste Mal, dass ich das in Zusammenhang mit einem eindeutigen Praxisbezug lese.
Warum machen es die anderen Installer aber dann nicht auch so?

Das Traurige daran ist, dass dieser Umstand schon sehr lange bekannt ist, aber nicht gefixt wird.

Wenn man die dahinhuschenden Meldungen während einer Installation angespannt verfolgt, so sieht man, dass laut grafischen Frontend, der Boot-Starter sehr wohl auf die richtige (gewählte) Partition geschrieben werden soll (also z.B. Disk B statt Disk A). Nur das Low-Level Tool, an das die Parameter durchgereicht werden, ignoriert es einfach. Das kann nur bedeuten, dass zwischen GUI-Tool und Low-Level-Tool kein Austausch stattfindet (auf der Entwicklerseite). Warum, das verstehe ich allerdings auch nicht.

Freilich, wenn man diese Macke kennt, ist es keine große Sache, den Fehler zu umgehen.
Und zwar auch ohne zwischenzeitliches Aus- und Wiedereinbauen von Festplatten.

Wenn ich mich recht erinnere, dann hilft es, wenn man vor der Installation einen Partitionsmanager benutzt und vorübergehend das ESP Flag der internen SSD zu entfernt.

Entweder so.
Oder so wie nachstehend.

Ich setzte eine VM auf und schiebe das dann auf die externe Platte

Nochmal in Kurzform die VM-Methode zusammengefasst:

• eine Dummy-VM errichten (am besten unter dem VMware Player), die folgende Grundeigenschaften aufweist:
  • EFI-Modus
  • USB3-Unterstützung
  • KEINE virtuelle Disk
• VM mit entsprechender Live-ISO starten und nachfolgend die physikalische, externe USB-Disk an die VM koppeln
• als Installationsziel die externe USB-Disk bestimmen. Da innerhalb der VM keine andere EFI-Partition als die der USB-Disk sichtbar ist, landet der Starter somit automatisch auch auf dieser. Die USB-Disk sollte natürlich passend vorbereitet worden sein (GPT, Partitionen) und es kann auch nicht schaden, wenn zuvor eine Sicherheitskopie der EFI-Partition gemacht worden war (falls da schon was anderes drauf sein sollte).

Unmittelbar nach der Installation sollte man die externe USB-Disk dann direkt auf dem Host booten. Linux (getestet mit Ubuntu und Mint) passt sich beim Hochfahren automatisch an die geänderte Hardware an. Schlimmstenfalls müßte der Treiber für das Grafiksystem noch manuell nachjustiert werden.

Am Ende wurde der Bootloader dementsprechend wie gewünscht in /sda1 installiert.

Nach dem was Du vorher geschrieben hattest (temporäres Verstecken der internen ESP auf sda), muß es wohl 'sdb' heißen.

 

[Creeping.Death]

Nach dem was Du vorher geschrieben hattest (temporäres Verstecken der internen ESP auf sda), muß es wohl 'sdb' heißen.

Also ich hatte das, was @Garmor geschrieben hat als "ironisch" interpretiert. Weil es eigentlich genau das beschreibt, wie es mir bei meinen ersten Versuchen ging.

Man denkt, man ist schlau, weil man dem Installer ja explizit sagt, was man haben möchte und alles so aussieht, als würde er das auch machen. Letztendlich macht das Ding aber doch, was es möchte.

 

[LochinSocke]

Nochmal in Kurzform die VM-Methode zusammengefasst:

Nein Falsch, ich richte eine VM mit virtueller Disk ein und schiebe die am Ende auf den externen Datenträger. Starte das System ggf. dann von extern (chroot) und schreibe den Bootloader einmal neu.

Aber So wie du schreibst geht es natürlich auch gut. Der letzte Schritt ist in der Regel nicht notwendig.

 

[foofoobar]

Nochmal in Kurzform die VM-Methode zusammengefasst:

• eine Dummy-VM errichten (am besten unter dem VMware Player), die folgende Grundeigenschaften aufweist:
  • EFI-Modus
  • USB3-Unterstützung
  • KEINE virtuelle Disk
• VM mit entsprechender Live-ISO starten und nachfolgend die physikalische, externe USB-Disk an die VM koppeln

Das geht auch mit KVM/Qemu/virt-manager:

<disk type="block" device="disk">
<driver name="qemu" type="raw" cache="none"/>
<source dev="/dev/disk/by-id/xxxxxxxx>
<target dev="vda" bus="virtio"/>
<address type="pci" domain="0x0000" bus="0x07" slot="0x00" function="0x0"/>
</disk>

 

[7vor10]

Nein Falsch, ich richte eine VM mit virtueller Disk ein und schiebe die am Ende auf den externen Datenträger. Starte das System ggf. dann von extern (chroot) und schreibe den Bootloader einmal neu.

Das wäre dann aus meiner Sicht quasi die vierte Möglichkeit, den Fehler des Installers zu umgehen (war mir bisher noch nicht bekannt).
Ich bleibe allerdings erstmal bei Methode 3, also der VM-indirekten Installation auf die physikalische Disk.
Das habe ich kürzlich zum dritten Mal erfolgreich hingekriegt (der Mensch ist ja ein Gewohnheitstier).

Also ich hatte das, was @Garmor geschrieben hat als "ironisch" interpretiert. Weil es eigentlich genau das beschreibt, wie es mir bei meinen ersten Versuchen ging.

Nein, das lese ich nicht als Ironie. Denn er hat ja mittels Methode 2 (Boot-Flags der internen Disk temporär deaktivieren) den Fehler des Installers ausgetrickst. Der Installer (von Ubuntu & Co) schreibt den Starter sturr auf die erste vorgefundene EFI-Partition. Wenn der Datenträger sda aber keine hat (weil temporär ausmaskiert), jedoch der externe Datenträger (in dem Fall sdb) über eine solche verfügt, landet der EFI-Starter halt dort.
Und so wie @Garmor das gemacht hat, um den Starter auf die externe (,zweite) Disk zu zwingen, hatte ich es bei meinem ersten erfolgreichen Versuch auch gemacht.
Um es noch mal zu klar zu sagen: es geht letztendlich immer nur darum, dass der Installer nur eine einzige EFI-Partition zum Zeitpunkt der Installation finden kann (und zwar die, auf der der Starter landen soll).

Diese Vorkehrungen hattest Du aber bei Deinen Versuchen nicht getroffen (mehr als eine sichtbare EFI-Partition vorhanden) und daher hatte der Installer trotz Deiner korrekten Auswahl den Starter dennoch an die falsche Stelle geschrieben.

 

[Creeping.Death]

Nein, das lese ich nicht als Ironie.

Vielleich klärt @Garmor uns auf, wie

Man muss eben nur wissen, wie ma... oh. Ich hasse Ubiquity.

gemeint war.

 

[Garmor]

Ironisch, weil es eben tatsächlich an der falschen Stelle gelandet ist.

 

[7vor10]

und die ESP auf /sda1 explizit als "nicht benutzen" markiert.

Hatte ich jetzt so verstanden, dass vor der Installation die Markierungen (Flags) esp und boot temporär auf Partition sda1 gelöscht worden waren (per GParted).
Das wäre ja der Hammer, wenn der Ubuntu-Installer trotzdem den Starter auf sda1 geschrieben hat!? Habe ich in meinen zwei bis drei Versuchen mit dieser Methode nicht erlebt (der Starter landete dann stets auf der zweiten Disk).
Aber vielleicht ist der Ubuntu-Installer ja inzwischen "weiterentwickelt" worden und "durchschaut" nunmehr, dass der Benutzer ihn austricksen will und trickst dann dagegen.

Das geht auch mit KVM/Qemu/virt-manager

Danke für den Tipp. Habe ich für mich als Methode Nummer 5 archiviert.
Man weiß ja nie, wieviele Varianten man noch braucht, falls irgendeine davon nicht mehr gehen sollte (siehe oben).

 

[Garmor]

per GParted

Nein. In der Partitionierungsübersicht von Ubiquity. Dort mit Rechtsklick auf die andere ESP und dort als "nicht verwenden" markiert. Dann verliert diese Partition im Installer auch das Label efi und wird einfach nur noch als FAT-Partition gelistet. Trotzdem landet der Installer darin.

 

[foofoobar]

Hatte ich jetzt so verstanden, dass vor der Installation die Markierungen (Flags) esp und boot temporär auf Partition sda1 gelöscht worden waren (per GParted).
Das wäre ja der Hammer, wenn der Ubuntu-Installer trotzdem den Starter auf sda1 geschrieben hat!? Habe ich in meinen zwei bis drei Versuchen mit dieser Methode nicht erlebt (der Starter landete dann stets auf der zweiten Disk).
Aber vielleicht ist der Ubuntu-Installer ja inzwischen "weiterentwickelt" worden und "durchschaut" nunmehr, dass der Benutzer ihn austricksen will und trickst dann dagegen.


Danke für den Tipp. Habe ich für mich als Methode Nummer 5 archiviert.
Man weiß ja nie, wieviele Varianten man noch braucht, falls irgendeine davon nicht mehr gehen sollte (siehe oben).

Die Methode kann auch nutzen um ein altes System in einer VM zu booten.
Man muss allerdings aufpassen das nicht ein Volume doppelt gemountet wird.

 

[Garmor]

Übrigens läßt sich die verhunzte Ubiquity-Installation durch einfaches Verschieben/Kopieren der betreffenden Bootloaderdateien in den gewollten Zustand bringen.

Ich habe auch Lubuntu mit Calamares probiert. Das schreibt tatsächlich den Bootloader da hin, wo man es angibt. Wenn man btrfs als Dateisystem wählt, sind die Voreinstellungen und Mount-Flags tatsächlich vernünftig gewählt und die Swap-Datei bekommt ein eigenes Subvolume. Unter Ubiquity wird die einfach unter @ erstellt und ist dann nicht benutzbar. Eine Möglichkeit zur Erstellung und Bearbeitung von Subvolumes im Installer wie unter Anaconda gibt es in Calamares leider auch nicht.