[gelöst] Debian auf USB-Stick installieren

[larsneu]

Guten Tag zusammen,

als ich noch Xubuntu nutzte, habe ich mir einen USB-Stick mit einem lauffähigen Xubuntu erstellt, auch verschlüsselt. Die Installation verlief wie eine normale Installation auf einer SSD. Anschließend konnte ich diesen Stick an jedem beliebigen Rechner anschließen und davon booten. So konnte ich Xubuntu immer dabei haben.
Das gleich habe ich jetzt schon zweimal mit Debian probiert. Am Ende der Installation wird auch gefragt, wohin Grub installiert werden soll - selbstverständlich auf den Stick.
Im Anschluß an beide Installationen funktioniert das Booten vom Stick nicht. Schaue ich mir die Partitionierung des Sticks an und vergleiche sie mit meiner SSD, so unterscheiden sie sich. Es fehlen zum Beispiel die Einhängepunkte /boot/efi und /boot.

Ist es wirklich nur mit dieser Anleitung (https://wiki.debianforum.de/Ein_Notfall ... stallieren) möglich, Debian auf einen USB-Stick zu installieren? Oder kann ich irgendwie noch den Stick zum Laufen bringen?

Viele Grüße

[smutbert]

Eine normale Installation klappt genauso (oder sollte es zumindestens) und nachträglich zum Laufen bringen wird hoffentlich auch funktionieren.

Wenn gefragt wird wohin grub installiert werden soll, ist es grub-pc (eine Installation im BIOS-/Legacy-/CSM-Modus). Passt das zu deinem Comouter und den BIOS-Einstellungen?
Und was genau hast du als Ziel angegeben? (Hier will man normalerweise den kompletten Stick und nicht eine der Partitionen auf dem Stick angeben, damit grub im MBR landet.)

[grubenlicht]

...Anschließend konnte ich diesen Stick an jedem beliebigen Rechner anschließen und davon booten.

davon ausgehend, daß Rechner 2 unterschiedliche Bootmodi haben (können), mußt du dafür sorgen, daß der Bootloder eben auch beide Modi "versteht".

Erreichen kannst du das (z.B.) mit der Verwendung eines sog. -> stand-alone grub mit anschließender Installation von Debian, wobei der Modus in dem Fall unerheblich ist.
Je nach Debianversion richtest du dann die zum stand-alone grub gehörende grub.cfg so ein, daß entweder

– mittels SymLinks -> …linux /vmlinuz…
– mittels dortiger grub.cfg -> …configfile /boot/gru/grub.cfg
– oder mittels direkter kernel Auswahl -> … linux /boot/vmlinuz-5.xx…

gebootet wird.

[larsneu]

Danke für eure Antworten. Es hat jetzt funktioniert - hatte möglicherweise etwas mit dem booten des Installations-Sticks im EFI-Modus zu tun.
Nach der Installation auf dem Stick konnte ich an dem Wirts-Rechner vom USB-Stick booten. Dann habe ich noch die Grub-Wartezeit verändert, danach update-grub und der Stick funktioniert nun wie vorgesehen. Den Bootloader vom Wirts-Rechner hatte es bei einem vorherigen Versuch schon zerschossen. Nach dem erfolglosen Ausprobieren der Reparatur mittels verschiedener Anleitungen habe ich auf diesem Rechner kurzerhand Debian neu installiert.

[oui]

kann man danach den Rest vom Stick (beisp. 128 GB Stick) weiterbenutzen? Wie macht man eigentlich das? Geht es mit dd?

[cosinus]

kann man danach den Rest vom Stick (beisp. 128 GB Stick) weiterbenutzen? Wie macht man eigentlich das? Geht es mit dd?

Wie kommst du denn gerade auf dd?

[hikaru]

kann man danach den Rest vom Stick (beisp. 128 GB Stick) weiterbenutzen? Wie macht man eigentlich das? Geht es mit dd?

Angenommen, dein Stick mit der Linuxinstallation hat noch freien Platz, dann kannst du diesen ganz gewöhnlich (z.B. mit gparted) partitionieren und formatieren.
Das dort angelegte Dateisystem kannst du dann innerhalb des Stick-Linux mounten oder es als Austauschmedium nutze, wie bei gewöhnlichen Daten-USB-Sticks.

Da so ein Datenstick vielleicht ab und zu ein Windows sehen wird, sollte dieses Dateisystem wohl NTFS, oder heute auch exFAT sein. Außerdem sollte die Datenpartition in diesem Fall die erste primäre Partition auf dem Stick sein, und deine Linux-Partition dann dahinter kommen, denn Windows (zumindest in manchen - vielleicht schon beerdigten Versionen mag Datenpartitionen auf USB-Sticks nur so).

[oui]

danke hikaru für letzte erklärungen. Ich konnte in der Tat in einem Stick die restkapazität mit gparted als neue partition definieren (64 GB Stick also VIEL Platz noch!). Zur Anwendung kam es nicht, weil ich nicht mounten will sondern mit fstab diese Partition direkt einsetzen möchte. Und , natürlich, hatte ich in /etc/fstab keinen Eintrag dazu in meiner ISO, die am Anfang vom Stick alles starten soll.

und jetzt habe ich elende Schwierigkeiten, weil alle meine Vollinstallationen unbrauchbar werden, wenn ich eine neue (voll) Installation zur Erzeugung der neuen ISO für den Stick aufbereite, weil jedes Mal völlig umsonst eine neue UUID für swap erzeugt wird, die alle anderen Vollinstallationen stört!

Das ist doch mittelalterlich bis zu äussersten so ein perverses System...

[DeletedUserReAsG]

Das ist doch mittelalterlich bis zu äussersten so ein perverses System...

Mittelalterlich? Pervers? Und damit arbeitest du freiwillig? Hopp, ab zum fortschrittlichen, straighten Windows!

Wie auch immer: für deine „elenden Schwierigkeiten“ bist du selbst verantwortlich. Mach’s richtig.

[hikaru]

danke hikaru für letzte erklärungen. Ich konnte in der Tat in einem Stick die restkapazität mit gparted als neue partition definieren (64 GB Stick also VIEL Platz noch!). Zur Anwendung kam es nicht, weil ich nicht mounten will sondern mit fstab diese Partition direkt einsetzen möchte. Und , natürlich, hatte ich in /etc/fstab keinen Eintrag dazu in meiner ISO, die am Anfang vom Stick alles starten soll.

Wenn dein Debian auf einem iso-Dateisystem sitzt, dann hast du keine reguläre Installation durchgeführt, sondern irgendein Image darauf geschrieben. Das ist dann nicht modifizierrbar und folglich kannst du auch die fstab nicht anpassen.
Eine Debianinstallation sollte auf einem rw-Dateisystem (z.B. ext4) liegen. Dann kannst du auch die fstab anpassen.

und jetzt habe ich elende Schwierigkeiten, weil alle meine Vollinstallationen unbrauchbar werden, wenn ich eine neue (voll) Installation zur Erzeugung der neuen ISO für den Stick aufbereite, weil jedes Mal völlig umsonst eine neue UUID für swap erzeugt wird, die alle anderen Vollinstallationen stört!

1. Du solltest idealerweise dem System auf dem Stick gar keinen Swap geben, denn auf verschiedenen Rechnern gibt es natürlich auch verschiedene Swap-Partitionen (wenn überhaupt) mit verschiedenen UUIDs, und selbst wenn du die jeweils dynamisch erkennen könntest (was prinzipiell machbar wäre), weißt du nicht, ob du die benutzen "darfst", oder ob du dabei z.B. ein auf dem Rechner befindliches System stören würdest, das sich gerade in Suspend2Disk befindet.
Falls du also für dein Stick-System tatsächlich Swap brauchst, dann solltest du das auf dem Stick ablegen, dabei aber bedenken, dass das höhere Schreiblast bedeutet, was höhere Qualitätsanforderungen an den Stick stellt, sowohl was seine eigene Haltbarkeit als auch dein Nervenkostüm im Sinne von Wartezeiten angeht.

2. Wenn du im Installer eine bereits bestehende Swap-Partition überschreibst, dann bekommt die natürlich eine neue UUID und davon weiß dann das System unter dem sie ursprünglich angelegt wurde auch nichts. Daher solltest du bei Zweitinstallationen immer eine separate Swap-Partition anlegen, oder eben gar keine.
Wenn du gar keine angibst, kannst du die bestehende später händisch in die fstab mit der bestehenden UUID eintragen. Aber auch hier musst du im Betrieb bedenken, dass mehrere Syteme die sich die gleiche Swap-Partition teilen, sich möglicherweise gegenseitig auf die Füße treten.

[DeletedUserReAsG]

Aber auch hier musst du im Betrieb bedenken, dass mehrere Syteme die sich die gleiche Swap-Partition teilen, sich möglicherweise gegenseitig auf die Füße treten.

Dem würde man aus dem Weg gehen, wenn man die Swappartition bei jedem Start neu initialisiert, wie’s beispielsweise bei verschlüsselten Systemen ja sowieso gemacht werden sollte.

[hikaru]

Auch wenn du den Swap neu initialisierst, trittst du einem anderen System möglicherweise auf die Füße, das diesen Swap gerade für Suspend2Disk verwendet.

[DeletedUserReAsG]

Auch wenn du den Swap neu initialisierst, trittst du einem anderen System möglicherweise auf die Füße, das diesen Swap gerade für Suspend2Disk verwendet.

Wer in einem Szenario, in dem sich verschiedene Systeme eine Swap-Partition teilen, S2D macht, hat’s auch nicht besser verdient