Welcher IT-ler kennt es nicht: Das Endgerät wird mit Windows ausgeliefert, für manche Zwecke wäre die persönliche Präferenz aber ein selbst installiertes, konfiguriertes und mit der eigens bekannten Softwareauswahl gespicktes Linux.
Es gibt die Option, den oder die Datenträger zu löschen, partitionieren und/oder zu formatieren, aber meist steht diesem Unterfangen irgendwas im Weg. Mag es die benötigte Konferenz- oder Zeitabrechnungssoftware sein, oder gar der zu Recht von der eifrigen mit Hardwarekonfiguration beauftragten Person aktivierte Bitlocker, irgendwas steht der potentiellen Einzel- oder Dualbootoption mit Linux immer im Wege.
Meine letzte Erfahrung mit einem Dualbootsystem war die folgende: Partitioniert, Grub als Bootloader, die Windows Partition mit Bitlocker verschlüsselt, dann Linux installiert. Das schöne dabei: Jedes Mal, wenn der Linux-Kernel ein Update bekam, gab es auch eine Änderung in der Efi-Partition der Platte, was dem Bitlocker gar nicht schmeckte und man erst wieder dazu angehalten war, den nicht gerade kurzen Bitlockerwiederherstellungsschlüssel einzutippen. (und ja, das Wort ist kürzer als der aus Ziffern bestehende Schlüssel, den es beschreibt).
Und es sind dann die schönen Momente im Leben, an die man sich erinnert: Mittagstisch beim Kunden oder bei der Kundin, und es kommt eine neue Information oder gar eine veränderte Anforderung ans Licht, die jede freundliche, kompetente und kollegiale Person natürlich sofort ins Dokumenten- oder gar Dokumentierungssystem des eigenen Hauses transferieren möchte. Das Dualbootsystem wird neu gestartet, allerdings erscheint auf einmal Bitlocker, was unweigerlich zu der Feststellung führt, dass unser eins ja gestern etwas länger gemacht hatte, das System unter Linux nur in den Tiefschlaf versetzt hatte und heute noch nicht neu gebootet hatte. Entweder der Schlüssel wird jetzt, dokumentiert auf einem Schnipsel Papier, aus dem Portemonnaie gezogen (bester Eindruck überhaupt), oder man bootet erneut in Linux, logt sich ein, startet den Passwortmanager indem hoffentlich der Schlüssel schlummert, notiert sich diesen auf einem Blatt Papier (welches nach dem Vorgang natürlich umgehend vernichtet werden muss, entweder durch Kauen und Schlucken des Fetzens oder in einem traditionellen Verbrennungsritual) und tippt diesen ein. Aber zugeben, dass (selbst temporär) kein Zugang zur eigenen Maschine besteht, sollte tunlichst vermieden werden.
Und vielleicht besteht das Glück, das bei der Auswahl des mobilen Endgerätes eines mit zwei verbauten Datenträgern geordert wurde, und die Möglichkeit besteht, Datenträger 1 für Windows und Datenträger 2 für Linux zu nutzen, aber dies ist nur selten der Fall. Außerdem, bei den Geschwindigkeiten von den USB-Ports, heute auch fast nicht mehr Notwendig.
Also wird ein persistentes System auf einem USB-Stick installiert. Aber Obacht, es gibt Stolpersteine:
Erste Stolperfalle: Der Stick
Die Auswahl des Sticks an sich sollte wohlüberlegt sein. Wer meint, es würde ein Stick an der Kasse eines Lebensmittel- oder Drogeriediscounters ausreichen, darf gerne weiterlesen, verursacht bei mir aber bei dieser Aussage heftigstes Stirnrunzeln.
Kaufkriterium Nummer 1: Der Stick muss USB3.X mitmachen. Ein USB2.X Stick würde auch funktionieren, aber dieser ist nur für Informatiker, die Wartezeit gerne mit dem Weg zum Kaffeeautomaten überbrücken und sich, bei entsprechender Entfernung des solchen, parallel auf einen Marathon vorbereiten möchten.
Kaufkriterium Nummer 2: Lese- und Schreibgeschwindigkeit. An dieser Stelle ein hoch auf den Heise Preisvergleich (https://www.heise.de/preisvergleich/?cat=sm_usb), wo sogar nach den Geschwindigkeiten sortiert werden kann. Natürlich ist, die passende Schnittstelle des Endgerätes vorausgesetzt, mehr in diesem Fall besser. Aber inwiefern die Geschwindigkeit DEN entscheidenden Kaufgrund darstellt, kommt auf die Nutzungsart und -dauer an. Allerdings sollte sich das Gerät, zumindest was die Geschwindigkeit angeht, unter den Top 100 befinden, es ersetzt ja immerhin einen internen Datenträger.
Kaufkriterium Nummer 3: Die Größe des Sticks. Ein in ein mobiles Endgerät gesteckter USB-Stick stellt immer eine Verbreiterung des Gerätes dar. Dies kann, insbesondere in engen Serverschränken, zu Einschränkungen führen. Der USB-Stick sollte im laufenden Betrieb nicht unbedingt berührt, auf gar keinen Fall aber entfernt werden. Dies sollte auch bei einer Anschaffung eines Sticks mit USB-C Schnittstelle bedacht werden, da diese doch sehr kurz geraten ist. Zudem wird ein kleiner USB-Stick auch gerne mal übersehen, was wiederum auch gerne mal einen Verlust nach sich zieht.
Kaufkriterium Nummer 4: Die andere Größe des Sticks. Das potentielle Datenvolumen. Hier kommt es auch wieder auf den Anwendungsfall an. Wird mit großen Datenmengen gearbeitet, bietet sich natürlich auch ein dementsprechend dimensionierter Stick an.
Fazit: Der Stick sollte dem Hauptaufgabenfeld der Linux-Installation angepasst werden. Werden Netzwerke damit geprüft und befindet sich der Informatiker oder die Informatikerin häufiger in engen Umgebungen, wäre ein kurzer Stick, welcher das Volumen des mobilen Endgerätes nicht unnötig erweitert die bessere Wahl. Hat der Kollege oder die Kollegin hauptsächlich damit zu tun, VMs von VMWare nach Proxmox zu migrieren und tut dies an einem dedizierten Arbeitsplatz, wäre die physische Größe egal und es sollte eher auf Kapazität und Geschwindigkeit geachtet werden.
Persönliche Empfehlung: Nach der Anschaffung meines neuen Laptops habe ich lange mit mir gerungen, welchen USB-Stick ich mir zulege. Ich persönlich bin bei diesem gelandet:
https://www.heise.de/preisvergleich/samsung-fit-plus-2020-256gb-muf-256ab-apc-a2303121.html?hloc=de
USB-A, sehr kurz, und trotzdem eine valide Lese- und Schreibgeschwindigkeit. Für die eine oder andere VM findet sich, dank der 256 GB, auch noch Platz.
Zweiter Stolperstein: Die Partitionierung
Die erste Partition, wie sollte es anders sein, wird die EFI Partition. Diese sollte, je nach Wunsch und Anzahl an OS Systemen auf dem Stick, zwischen 512 MB und 1 GB groß sein, bei vielen persistenten Systemen ggf. auch größer.
Nun kommt die Gretchenfrage: Soll es eine Partition geben, welche den Datenaustausch zwischen dem internen Windowsdatenträger und dem Linux-System auf dem Stick duldet, oder kann dies aufgrund anderer Methoden ignoriert werden? Zum Beispiel durch eine Cloud, aber dies hieße das beide Systeme zugriff auf diese haben müssten (und zumindest ein Internetzugriff von beiden Systemen möglich ist).
Ich rate immer noch zu so einer temporären Ablage, weise aber an dieser Stelle daraufhin das diese entweder nach jedem Einsatz gesäubert werden sollte, oder aber die Dateien oder die Partition mit einer Verschlüsselung versehen werden müssen, welche beide Betriebssysteme unterstützen.
Soll eine solche Partition vorhanden sein, muss sie als zweite Partition auf den Stick. Windows liest zwar mehrere NTFS Partitionen, allerdings nur wenn eine NTFS Partition vorangeht (Ausnahme EFI Partition, aber selbst die ist immer noch im, eigentlich von Windows lesbaren, FAT32 Format formatiert). Also muss diese als zweite Partition auf den USB-Stick. Hier ist die Größe der Partition den Bedürfnissen anzupassen.
Als nächste Partition wird dann die die /boot Partition konfiguriert, welche sich noch außerhalb der Verschlüsselung befinden darf. Auch hier sollte eine Größe zwischen 512 MB und 1 GB gewählt werden.
Nun kommt die verschlüsselte Partition, welche das OS und die Daten beherbergt. Zunächst einmal die Herangehensweise:
Ursprünglich gestaltete sie sich, wie auf einer der folgenden Seiten beschrieben:
http://daemons-point.com/blog/2021/08/27/ubuntu-gnome-20.04.3/
https://medium.com/@chrishantha/encrypting-disks-on-ubuntu-19-04-b50bfc65182a
https://gist.github.com/superjamie/d56d8bc3c9261ad603194726e3fef50f
Allerdings stellte mich dies vor diverse Probleme bei den Linux Installationsoptionen (getestet wurden Ubuntu-Server 22.04 und Mate-Desktop 22.04). Ich habe zunächst die Partition verschlüsselt, geöffnet, die LVM Gruppen und Volumes angelegt, bin dann in den Installer gegangen, um sie dann selten (zwei Mal in sechs Versuchen beim Ubuntu-Server) oder gar nicht (Mate-Desktop) zu Gesicht zu bekommen, und das obwohl jedes Mal über eine Shell die verschlüsselte Partition geöffnet wurde.
Beim Ubuntu Server gabs es in den zwei Versuchen dann Probleme bei der Installation, darauf gehe ich aber gleich noch ein.
Was im Endeffekt funktioniert hat: Die zu verschlüsselnde Partition anlegen, diese jedoch unformatiert lassen oder ggf. reinigen.
Den Ubuntu-Server Installationsprozess durchlaufen lassen (die Software kann sie selbst auch updaten, wobei ich in diesem Fall nochmals nahelege, bis zur Auswahl der Sprache zurück zu gehen, da sich diese nachdem Update auch zurücksetzt).
Die Partitionierung und Installation manuell ausführen (was auch sonst), dann die zweite bzw. dritte Partition als /boot auswählen (somit erkennt die Installation auch wohin der Bootloader soll).
Dann auf dem freien Bereich eine LVM Gruppe anlegen (Bei mir war das Anlegen ein Blindflug, weil mir die Partitionen nicht angezeigt wurden, ich mich nur durch unsichtbare Punkte scrollen bzw. klicken konnte; am besten man merkt sich wie groß die Partition ist, und sobald die richtige Größe angezeigt wird (1-zu-1) wurde die richtige Partition erwischt).
Darunter den Haken setzen bei Verschlüsselung aktivieren, Passwort eingeben und wiederholen, und dann wird die neue LVM Gruppe oben angezeigt, und der Bereich lässt sich in logische Laufwerke aufteilen.
Zur Aufteilung der logischen Laufwerke: In den meisten Anleitungen wird dem Wurzelverzeichnis eine Größe zwischen 30 und 50 Gigabyte zugewiesen, etwas Platz für Swap gelassen, und der Rest des Platzes geht in den persönlichen Ordner, namentlich das /home Verzeichnis. Ich habe damit so meine Probleme. Meine beiden Aufgabenfelder sind VMs und Netzwerküberwachung. Die VMs werden normalerweise im Wurzelunterverzeichnis /libvirt/images angelegt, dies kann auch auf das /home-Verzeichnis umgebogen, damit habe ich aber nur die halbe Miete. Für die meisten meiner Netzwerktools benötige ich bereits beim Start Root-Rechte, was bedeutet auch hier landen die Daten nicht unbedingt in Nutzerverzeichnis. Ich separiere deswegen das /home sehr selten auf eine eigene Partition, sondern belasse es da wo es ist, als Unterverzeichnis des Wurzelverzeichnisses. Das mag jeder anders handhaben. Ich persönlich bin einfach zu häufig an den Punkt gekommen, dass ich zwar noch genügend Platz für eine weitere VM hätte, dieser aber so ungünstig auf beiden Partitionen verteilt war, dass es letztendlich doch nicht mehr gepasst hat, und ich verschieben und/oder löschen musste. Verschlüsselt wird eh alles.
Was bei der Aufteilung der logischen Laufwerke noch gesagt werden sollte: Im Gegensatz zu den o.g. Beispielen in den Links, arbeitet der Server nicht mehr mit einer Swap Partition, sondern mit einer Swap-File im Wurzelverzeichnis. Da ich nur mit nur mit Wurzel-Laufwerk und Swap-Laufwerk gearbeitet habe, hat mir die Installationssoftware die Swap Partition zwar als Swap formatiert, immer aber als /Home deklariert (konnte auch nicht verändert werden, war ausgegraut), was m.E. der Grund dafür sein könnte, dass der Installationsprozess zweimal abgestürzt ist.
Sollte man dies mit Ubuntu-Server 22.04 also nochmal probieren, würde ich die Swap-Partition zunächst außen vorlassen.
Hier ein Blick auf Swap-File vs. Swap Partition
https://www.baeldung.com/linux/swap-file-partition
Wird unbedingt eine Swap Partition gewünscht, einen Bereich am Ende des LVMs leer lassen. Nach Ende der Installation diesen Bereich auswählen, ein neues logisches Laufwerk anlegen, dieses mit Swap formatieren und in die fstab eintragen. Die Swap File dann aus der fstab austragen und aus dem Wurzelverzeichnis löschen.
Und Voila, fertig ist der verschlüsselte Linux USB-Stick. Dass schöne an ihm? Er ist zwar für das mobile Endgerät konzipiert worden, kann aber an anderen Endgeräten, die auch den Bootvorgang von USB unterstützen, gestartet werden.
Neueste Kommentare