Linux auf Stick mit 2 Partitionen

[clue]

Hi! Ich suche Hilfe bei der Erstellung eines live-usb sticks, der NICHT dem Standardszenario entspricht.
Folgendes möchte ich gerne haben, weiß aber nicht wie:

Der Stick soll 2 Partitionen haben. Die erste wird als "normale" Datenpartition verwendet, damit sie auch an Büro-Windows-Rechnern als Wechseldatenträger genutzt werden kann. Auf ihr soll dann auch die persistance liegen. Auf die Zweite kommt dann das live-image. Und das ganze sollte natürlich auch bootfähig sein .

Ich weiß, daß man einfach das live-iso mit dd /pfad/zum/image of=/mein/stick auf den stick bekommt. Nur wird dann eben der GANZE stick genommen, was ich eben nicht will.

[BenutzerGa4gooPh]

Schritt fuer Schritt:
http://cosmolinux.no-ip.org/raconetlinu ... tence.html
oder deutsch, eben bisschen aufpassen:
https://wiki.ubuntuusers.de/Archiv/Live ... tallation/
Die UEFI-Bootfaehigkeit der Debian-Live-Isos ist m. E. nicht in. jedem Fall gegeben, kenne aber auch nicht jede. Debian-Live-ISOs mit unfreien Treibern gibt es auch. Also würde ich zuerst die ISO mal probieren, bevor man den Zirkus lt. Manuals tut.
LG Jana

[smutbert]

Als Alternative:

Viele Live-Systeme lassen sich auch von einer iso-Datei starten. Man packt also kernel, initrd und das iso-Image auf eine Partition und startet das ganze zB mit grub.

Ich habe mir zum Beispiel mit grml so einen Stick zurechtgebastelt, der mittels grub-pc über dos/mbr, mittels grub-efi-amd64 auf normalen uefi-Systemen und mittels grub-efi-ia32 auf 64Bit Systemen mit 32Bit-uefi starten konnte. Ob das mit dem von dir auserkorenen Live-System auch funktioniert müsste man halt noch herausfinden.
Das hätte jedenfalls den Vorteil, dass du nicht unbedingt 2 Partitionen bräuchtest, im Grunde genügt eine einzige FAT-formatierte Partition (gegebenenfalls bräuchte man für dasselbe Setup eine BIOS-Boot-Partition für grub-pc, aber man kommt auch drum herum. Auf wunsch kann man das natürlich trotzdem auf beliebig viele Partitionen verteile.).

Im Endeffekt finde ich aber auch auf einem USB-Stick eine normale Installation wesentlich praktischer. Wenn es um die Manipulationssicherheit geht, die bei USB-Sticks naturgemäß nicht sehr ausgeprägt ist, dann könnte man auch auf Dateisysteme wie btrfs und read-only snapshots zurückgreifen, mit denen man den ist-Zustand vergleichen und zu denen man „zurückkehren“ kann.
Eine zusätzliche FAT-Partition für Daten/Windows, auf der dann auch grub-efi zu liegen kommen kann, ist dann ja eine triviale Angelegenheit.

[clue]

@Jana66
Hervorragende Anleitung. Danke. Ich werds mal ausprobieren.

@smutbert
Das mit dem direkten starten der iso nur mit kernel und initrd klingt ganz gut. Ich möchte folgendes:

Mein stick sollte an so ziemlich jeder Kiste auf der Welt laufen. Das heißt sowohl an 32bit und an 64bit Systemen. Und dann müsste er auch eine ziemlich breite Hardwareunterstützung liefern. Ich denke das live-iso sollte da schon recht brauchbar sein. Und 32bit können ja auch auf 64bit Systemen ausgeführt werden. Das wäre dann schon mal geklärt.

Außerdem sollte das verwendete Dateisystem möglichst nicht den stick schrotten wegen ständiger Schreibzugriffe. Deswegen denke ich, eine normale Standard-Installation wäre in dieser Hinsicht ungeeignet. Bleibt eigentlich nur live-image mit persistence. Ob das jetzt alles auf einer einzigen Partition zu machen ist, oder doch besser wie ich ursprünglich beschrieben habe auf zweien, ist jetzt die Frage. Ich würde es besser finden, wenn nur eine einzige Partition nötig wäre, da ich dann weniger Speicherplatz Verlust hätte.

Könntest Du mir mal eine Anleitung geben, wie Du das mit dem Iso und nur einer Partition gemacht hast? Geht das auch auf (ex)fat, damit ich den stick auch ganz normal als Wechseldatenträger verwenden kann? Ich möchte da auch gerne noch ne virtuelle Maschine draufhaben, damit ich die dann auch als Gast unter Windows oder Mac laufen lassen kann. Und dann noch portable-Versionen von z.B. LibreOffice und Co. Das wäre dann ziemlich cool.

Dann könnte ich im besten Fall direkt vom stick booten. Falls das dann irgendwie nicht geht, kann ich noch eine VM starten. Und falls das auch nicht geht, kann ich dann immer noch meine portablen Programme starten.

[BenutzerGa4gooPh]

Wäre das nicht was für dich?!
https://wiki.ubuntuusers.de/Remastersys/
Deine eigene Live-Iso/Distribution clue-linux-1.0 mit vorinstalliertem Virtualisierer und all deinen Wünschen und auf jedem Rechner lauffähig. Kannst sogar noch Installer dazupacken. Denke aber dran: Bei Paketaenderungen sind eigene Quelltexte nach GNU-Lizenz zu veröffentlichen. (Ist bisschen lustig ausgedrückt aber ernst gemeint.)
Vielleicht geht die Installation noch:
viewtopic.php?f=34&t=142818
https://packages.debian.org/jessie/live-build
Systemback und pinguybuilder gibt es auch noch. Keines davon habe ich allerdings getestet.

Die Idee von smutbert mit den btrfs-snapshots und normaler Installation von Linux ist Spitze!

[retabell]

Ich weiß, daß man einfach das live-iso mit dd /pfad/zum/image of=/mein/stick auf den stick bekommt. Nur wird dann eben der GANZE stick genommen, was ich eben nicht will.

da bleibt Dir dann die Möglichkeit im nicht genutzten Platz eine 2. Partition anzulegen.
in Kanotix ist das so gelöst. Da gibt eine Funktion den usb-Stick persistent zu machen.
Die angelegte Partition kannst hinterher dann auch noch verkleinern, und eine 3.Partition mit z.B. Fat32 anlegen.
das sieht dann so aus

Code: Alles auswählen

/dev/sdb1  *       2048    6143    4096    2M ef EFI (FAT-12/16/32)
/dev/sdb2          6144 3004415 2998272  1,4G 83 Linux
/dev/sdb3       3004416 5038079 2033664  993M 83 Linux
/dev/sdb4       5038080 7802879 2764800  1,3G  b W95 FAT32

sdb2 ist hier das iso (entsprechend der iso Grösse)
sdb3 die persistence Partition
sdb4 halt ne zusätzliche Fat32
ist zwar kein pure debian, aber vlt hast ja Lust das mal zu testen.

Ich würde es besser finden, wenn nur eine einzige Partition nötig wäre, da ich dann weniger Speicherplatz Verlust hätte.

das sollte sich damit erledigt haben.

Im Endeffekt finde ich aber auch auf einem USB-Stick eine normale Installation wesentlich praktischer.

Ja das hat Vorteile, grad in Sachen Geschwindigkeit.

Mit dem live-iso kannst halt mal schnell mit der Bootoption toram starten
Stick abziehen und hast ein laufendes System, das ist ein Vorteil dieser Variante.

[clue]

Ich würde es besser finden, wenn nur eine einzige Partition nötig wäre, da ich dann weniger Speicherplatz Verlust hätte.

das sollte sich damit erledigt haben.

Ich weiß jetzt, wie ich es haben will: 1 einzige Partition mit fat32 und live-image, dazu noch persistence. Was mir jetzt noch fehlt ist eine Anleitung, wie ich das hinkriegen kann.

Mit dem live-iso kannst halt mal schnell mit der Bootoption toram starten
Stick abziehen und hast ein laufendes System, das ist ein Vorteil dieser Variante.

Ja, ich denke das wäre ein sehr großer Vorteil.

[smutbert]

zusammenfassend läuft es darauf hinaus, dass nachdem du den Stick wunschgemäß partitioniert und das FAT-Dateisystem erstellt hast, du das Image hinaufkopierst und grub auf den Stick installierst.

Wie genau du das machst hängt auch davon ab ob du mittels grub-pc (BIOS/Legacy/CSM) oder grub-efi(-amd64) starten willst. Interessant sind dafür vor allem die Optionen »--boot-directory=…«, »--efi-directory=....«, »--no-nvram« und »--removable« von »grub-install«.
Wenn das geschafft ist sollte es eigentlich genügen eine passende grub.cfg anzulegen und dort einen Eintrag für das Live-Image hinzuzufügen, Beispiele für grml gibt es zum Beispiel hier
https://wiki.grml.org/doku.php?id=rescu ... ck_feature
mit anderen Live-Systemen funktioniert es aber nicht notwendigerweise gleich.

An welches live-System hast du denn gedacht?

[clue]

Also ich würd schon gerne das offizielle Debian live nehmen. Der Stick soll nur 1 fat32 Partition haben.

Eine Schritt für Schritt Anleitung wäre sehr hilfreich für mich.

[BenutzerGa4gooPh]

http://www.debian.org/releases/stable/i ... 03.html.de

[clue]

@Jana66

Vielen Dank für den link. Leider sind die Angaben dort recht unvollständig (z.B. wo finde ich das hd-media-image?). Außerdem beschreiben die Methoden dort nur, wie man einen stick entweder komplett (also unter vollständigem Verlust der Restkapazität des sticks) oder mit 2 Partitionen erhält.

Was mir aber noch immer fehlt ist eine Anleitung, wie ich meinen 32gb stick mit einer einzigen Partition erstellen kann, und dennoch meine 32gb weiter nutzen kann.
Wenn ich Smutbert richtig verstanden habe, ist es ihm gelungen genau das zu erreichen.

Folgendes habe ich schon ausprobiert:

cp debian.iso /dev/sdX <- erstellt eine einzige Partition mit 0 byte Restkapazität.

Ich entnehme von http://wiki.grml.org/doku.php?id=usb#grml2usb, dass eine Fat 16 Partition zum Booten benötigt wird. Ich nehme an, das hängt mit dem BIOS zusammen. Das würde mir aber nichts bringen, weil ich mit Fat 16 nicht meine 32gb nutzen kann.

Eine andere Möglichkeit wäre, das Image auf einer 2. Partition zu packen, so dass die erste von Windows/MacOS ganz normal als Wechseldatenträger genutzt werden kann (von mir aus NTFS-formatiert).
Dann würde ich die persistence halt auf die NTFS-Partition packen. Die Frage bleibt aber trotzdem, ob ich für den stick dennoch eine Fat 16 Partition benötige oder nicht.

Hier ist übrigens noch eine Anleitung. Ich meine aber, dass die Szenarien dort anders als meines sind: http://www.debian-administration.org/ar ... USB_device

[smutbert]

Doch ab "4.3.3. Dateien manuell auf den USB-Stick kopieren – der flexible Weg" wird schon das beschrieben was du willst. Es wird eine Partition mit FAT formatiert, das Image darauf kopiert und ein Bootloader installiert.
Nur das Speichern von Änderungen des Systems auf dem Stick ist nicht abgedeckt, aber das sollte kein Problem sein - verwendet habe ich dieses Feature allerdings noch nie.

Ein paar Kleinigkeiten habe ich anders gemacht und wahrscheinlich brächte ich auch eine Anleitung zustande, aber im Moment mangelt es mir - so blöd es klingt - an einem freien USB-Stick mit dem ich das ausprobieren könnte. Wenn du noch etwas Geduld hast, schaffe ich es vielleicht noch…

edit: FAT12, FAT16 oder FAT32 ist egal, die verwenden alle denselben Dateisystemtreiber und auch der Bootloader syslinux (grub sowieso) sollte alle Varianten unterstützen.

[hikaru]

Ich weiß jetzt, wie ich es haben will: 1 einzige Partition mit fat32 und live-image, dazu noch persistence.

Wenn man nicht auf eine bestimmte Distribution angewiesen war, dann hieß die Standardantwort auf sowas eigentlich Slax (oder eines der einstmals vielen Derivate) und basierte auf Slackware. Das hat mit Hilfe der Linux-Live-Scripts [1] vom selben Entwickler auf einem FAT-Dateisystem einen Container mit Unix-Rechte-kompatiblen Dateisystem in Form eines Tar-Archivs bereitgestellt, das beim Boot entpackt wurde. Persistenz und Updates wurden über zuschaltbare weitere Archive erreicht, oder schlicht über Einbinden von Ordnern auf dem Fat-Host-Dateisystem, sofern die Rechte nicht wichtig waren. Auf dem Stick wurde nur so viel Platz belegt, wie für das System tatsächlich nötig war.

Der Entwickler hatte irgendwann keine Zeit mehr für das Projekt und wollte es auch nicht abgeben. So ist Slax eingeschlafen, wurde aber unter dem Namen Porteus geforkt. Allerdngs scheint es auch bei Porteus seit Ende 2014 keine nennenswerte Aktivität mehr zu geben.
Mit PureOS gab es sogar mal ein ähnliches Projekt auf Debian-Basis. Aber auch das ist eingeschlafen.

Lange Rede kurzer Sinn:
Falls du eine aktuell gepflegte Distribution auf Basis der Linux-Live-Scripts findest, dann nimm die (und sag mir bescheid!)! Das System wurde genau für deinen Anwendungszweck zugeschnitten und ein mittlerweile recht angeschimmeltes Porteus liegt auch noch auf meinem Datenstick.

Inzwischen nehme ich aber eine normale Debianinstallation auf einem Stick mit. Die Zeiten wo Sticks so klein waren, dass man jedes MB mit Namen kannte sind vorbei. Und wenn man nicht gerade einen Billigstick vom Grabbeltisch des Discounters nimmt, dann hält der wohl gelegentlichem Einsatz als Systemmedium durchaus stand.

Die Idee mit "Überall booten" hat sich aber vermutlich ohnehin überholt. Man weiß heutzutage nicht, ob ein Rechner mit BIOS oder UEFI bootet und wenn UEFI, dann funkt möglicherweise auch noch Secure Boot dazwischen.
Selbst auf das Vorhandensein einer x86-Architektur kann man sich seit der Verbreitung von Googles Chrome-Books nicht mehr verlassen.


[1] http://www.linux-live.org/

[retabell]

Folgendes habe ich schon ausprobiert:

cp debian.iso /dev/sdX <- erstellt eine einzige Partition mit 0 byte Restkapazität.

Ich hatte oben schon geschrieben das Du den nicht benötigten Platz wieder herstellen kannst
also die ganze Speicherkapazität vom Stick nutzen kannst, also die Partition verkleinern.

Lange Rede kurzer Sinn:
Falls du eine aktuell gepflegte Distribution auf Basis der Linux-Live-Scripts findest, dann nimm die (und sag mir bescheid!)!

siehe oben, backup vom build-tree findest auch auf github

Die Idee mit "Überall booten" hat sich aber vermutlich ohnehin überholt. Man weiß heutzutage nicht, ob ein Rechner mit BIOS oder UEFI bootet und wenn UEFI, dann funkt möglicherweise auch noch Secure Boot dazwischen.

100% wirds da wohl eh nicht geben, obige Variante sollte mit und ohne UEFI funktionieren.
Ein Nachteil ist das grub auf einigen Systemen langsamer startet als syslinux.

obiges Layout lässt sich genauso mit einem debian-live image anlegen
dann halt mit syslinux.

Bleibt noch anzumerken das die Erkennung der FAT32 Partition nicht mit allen
Sticks funktioniert, der muss von Windows halt als Festplatte erkannt werden.

[hikaru]

Lange Rede kurzer Sinn:
Falls du eine aktuell gepflegte Distribution auf Basis der Linux-Live-Scripts findest, dann nimm die (und sag mir bescheid!)!

siehe oben, backup vom build-tree findest auch auf github

Ich habe mir Kanotix lange nicht mehr angesehen, aber in meiner Erinnerung ist das Prinzip von Kanotix ein anderes als das von Slax.
Für ein persistentes Kanotix auf einem windowskompatiblen Datenstick brauchst du nach wie vor mehrere Partitionen auf dem USB-Stick.
Bei Slax reicht eine einzige Partition. Darauf liegt dann das System in zwei Ordnern (boot & slax) in Form von komprimierten Tar-Archiven. Im Gegensatz zu Kanotix liegt schon das Grundsystem selbst in einem aufs/squashfs-Container.
Die Slax-Ordner kannst du bei Bedarf löschen, falls du z.B. mal den zusätzlichen Platz brauchst und kopierst sie hinterher einfach wieder drauf um wieder vom Stick booten zu können.

[clue]

Folgendes habe ich schon ausprobiert:

cp debian.iso /dev/sdX <- erstellt eine einzige Partition mit 0 byte Restkapazität.

Ich hatte oben schon geschrieben das Du den nicht benötigten Platz wieder herstellen kannst also die ganze Speicherkapazität vom Stick nutzen kannst, also die Partition verkleinern.

Also der KDE-Partitionmanager kann bei der Methode keinerlei Partitionen erkennen. Fdisk /dev/sdd zeigt allerdings folgendes Schema:

Code: Alles auswählen

Disk /dev/sdd: 29,8 GiB, 32015679488 bytes, 62530624 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1f405b75

Device     Boot Start    End Sectors  Size Id Type
/dev/sdd1  *        0 647167  647168  316M  0 Empty
/dev/sdd2        3940   4579     640  320K ef EFI (FAT-12/16/32)

obiges Layout lässt sich genauso mit einem debian-live image anlegen dann halt mit syslinux.

Wie kann ich jetzt den restlichen Speicherplatz zurückgewinnen?
Also wie gesagt, ein Debian-live-image klingt für mich am überzeugendsten. Eine richtige Installation würde dann aber auch zumindest ein ext2 Dateisystem benötigen, was dazu führen würde, dass der stick nicht unter Windows/MacOS als Wechseldatenträger verwendet werden kann.

Wenn man nicht auf eine bestimmte Distribution angewiesen war, dann hieß die Standardantwort auf sowas eigentlich Slax (oder eines der einstmals vielen Derivate) und basierte auf Slackware. Das hat mit Hilfe der Linux-Live-Scripts [1] vom selben Entwickler auf einem FAT-Dateisystem einen Container mit Unix-Rechte-kompatiblen Dateisystem in Form eines Tar-Archivs bereitgestellt, das beim Boot entpackt wurde.

Hm klingt ziemlich langsam, wenn beim Starten erst das System entpackt werden muss. Kostet das nicht auch mehr Arbeitsspeicher als das Starten eines live-images? Und wie siehts mit ständigen Schreibzugriffen auf den stick aus? Würde das im Vergleich zum live-image nicht um ein Vielfaches zunehmen?

[hikaru]

Hm klingt ziemlich langsam, wenn beim Starten erst das System entpackt werden muss.

Ja, es erhöht die Bootzeit. Auf meinem Netbook ist das aber noch erträglich.

Kostet das nicht auch mehr Arbeitsspeicher als das Starten eines live-images?

Ja. So ein System läuft praktisch immer mit der toram-Option. Allerdings lässt sich hier steuern, welche Teilarchive (Slax nennt sie "Module") überhaupt in den RAM geladen werden. Wenn du z.B. während einer Sitzung das fette Libreoffice nicht brauchst, dann kannst du schon beim Booten angeben, dass das Modul gar nicht entpackt werden soll. Änderst du später deine Meinung, dann kannst du das Modul im laufenden Betrieb nachladen und auch wieder entladen.

Und wie siehts mit ständigen Schreibzugriffen auf den stick aus? Würde das im Vergleich zum live-image nicht um ein Vielfaches zunehmen?

Da die Module selbst readonly sind, entstehen hier gar keine Änderungen. Persistente Änderungen können auf Wunsch zunächst in eine RAMdisk geschrieben und erst beim Beenden der Sitzung (oder auf manuellen Aufruf) auf dem Stick gesichert werden.

[smutbert]

Wie siehts aus - hast du alles so hinbekommen wie du wolltest?

Ich habe jetzt endlich einen (vorübergehend) unbenutzten USB-Stick, mit dem ich es ausprobiert habe und ertwartungsgemäß war es kein Problem ein iso-Image darauf zu kopieren, grub auf dem Stick zu installieren und davon zu booten. Für den Teil könnte ich dir mein Vorgehen beschreiben, wenn du es noch brauchst.

Für das dauerhafte Speichern der Änderungen habe ich allerdings keine Möglichkeit gefunden. Bei anderen Live-Systemen heißt es da meistens es genügt eine Datei mit der gewünschten Größe und dem richtigen Namen anzulegen, aber bei Debian ist immer nur die Rede von einer eigenen ext2/3/4-Partition wie zB hier
- http://crunchbang.org/forums/viewtopic.php?id=25489
- http://www.heise.de/ct/hotline/Kali-USB ... 81978.html
- http://de.docs.kali.org/installation-de ... persistenz
oder alternativ vom „Entpacken“ des Images in einem Dateisystem
- http://cosmolinux.no-ip.org/raconetlinu ... tence.html
Soweit ich das sehe funktioniert keines von beiden mit einer FAT-Partition, was ja aber genau das war was du wolltest.

Bei einigen anderen Live-CDs, wie zB denen von Ubuntu müsste es dagegen funktionieren, weil die die Änderungen offensihctlich, so wie ich es eigentlich auch bei Debian vermutet hatte, in einer Datei auf einem beliebigen beschreibbaren Dateisystem speichern können:
- https://help.ubuntu.com/community/LiveCD/Persistence

[clue]

Also vielen Dank, dass Du Dir die Mühe gemacht hast. Es ist schade, dass das persistence nicht klappen will. Warum geht das nicht, wenn man alles manuell einrichtet? Jedenfalls ist es ohne persistence für mich nicht lohnend. Ich will ja schließlich noch ein paar Programme außerhalb des Repos draufhaben. Und da kommt man nicht um persistence herum.

Auch wenn ich also Deinen Weg nicht unbedingt nachvollziehen will (aufgrund der fehlenden persistance), wäre es bestimmt auch für andere Interessant zu sehen, wie Du Deinen Stick vorbereitet hast. Vielleicht kann man daraus sogar mal ein Wiki machen.

[smutbert]

Darf man fragen wieso es eigentlich unbedingt Live-Systeme sein müssen und keine normalen Installationen sein dürfen?

____

Der USB-Stick war bereits von Haus mit einer mit FAT32 formatieren Partition mbr-partitioniert.
Dieses Dateisystem habe ich unter »/mnt/tmp« gemountet.
Dorthin habe die ich die iso-Datei (»debian-live-8.4.0-amd64-cinnamon-desktop.iso« von hier) kopiert und dann das LABEL des Dateisystems herausgesucht, wahlweise würde es auch mit der UUID funktionieren

Code: Alles auswählen

# blkid
[…]
/dev/sdc1: LABEL="KINGSTON" UUID="6098-DC2C" TYPE="vfat" PARTUUID="6044516f-01"

und auf dem Stick die Verzeichnisse »efi/grub« und eine Textdatei »efi/grub/grub.cfg« (also »/mnt/tmp/efi/grub/grub.cfg«) mit folgendem Inhalt angelegt:

Code: Alles auswählen

menuentry "Live ISO Boot" {
	insmod loopback
	insmod iso9660
	search --no-floppy --label --set=root KINGSTON
	loopback loop /debian-live-8.4.0-amd64-cinnamon-desktop.iso
	linux (loop)/live/vmlinuz boot=live findiso=/debian-live-8.4.0-amd64-cinnamon-desktop.iso noeject
	initrd (loop)/live/initrd.img
}

Fehlt also nur noch die eigentliche grub-Installation:
Ich habe einfach das auf meinem normalen Arbeitssystem bereits installiert grub-efi-amd64 verwendet und grub mit folgendem Befehl auf dem Stick installiert

Code: Alles auswählen

# grub-install --boot-directory=/mnt/tmp/efi --efi-directory=/mnt/tmp --force-extra-removable --no-nvram --no-uefi-secure-boot

Es mag einige UEFI-Systeme geben (ich kenne aber keine) die grub-efi nur von gpt-partitionierten Datenträgern starten, dann müsste man des Stick vorher, zB mit gdisk neu partitionieren.

Will man dagegen lieber mit grub-pc booten, dann braucht man bei gpt-partitionierten Datenträgern vermutlich eine zusätzlich BIOS Boot Partition, die bei mbr-partitionieren nicht notwendig ist. Außerdem muss man für grub-pc die Optionen von grub-install etwas anpassen - statt dem »efi-directory« müsste man das Installationsziel angeben, also die Gerätedatei des USB-Sticks und "--force-extra-removable --no-nvram --no-uefi-secure-boot" müsste man weglassen.

[clue]

Hey, vielen Dank für Deine Anleitung. Also Du hast einfach das image kopiert, also nicht mit dd gearbeitet?

Ich sehe deswegen von einer "normalen" Installation auf dem Stick ab, weil die ständigen Schreibzugriffe das Ding schnell schrotten würden. Und das Üble daran ist dann, wenn ich auf meine vermeintlich sicher gespeicherten Daten zugreifen will, und mir das Ding dann lauter Fehlermeldungen liefert.

[BenutzerGa4gooPh]

Man könnte ja ohne Swap installieren und auf "alte Hasen" hören. Beispielsweise auf den:
viewtopic.php?f=12&t=160544#p1088831
"Inzwischen nehme ich aber eine normale Debianinstallation auf einem Stick mit. Die Zeiten wo Sticks so klein waren, dass man jedes MB mit Namen kannte sind vorbei. Und wenn man nicht gerade einen Billigstick vom Grabbeltisch des Discounters nimmt, dann hält der wohl gelegentlichem Einsatz als Systemmedium durchaus stand."

Oder alles schön fertig und aufgrund der hervorragenden Hardwareerkennung auf den meisten PCs einsetzbar:

Kanotix kann im Livemodus ohne Festplatteninstallation zum Testen, aber auch zum Arbeiten benutzt werden. Durch die unionfs- bzw. aufs-Unterstützung können persönliche Einstellungen, zusätzlich „installierte“ Programme getestet werden. Auch die Speicherung von Daten und der Kanotix-Konfiguration auf der Festplatte oder einem mobilen Datenträger z. B. einem USB-Stick ist möglich. (Erstellung eines bootbaren USB-Sticks mit "persistent" Option). Das Kanotix-Image kann von Festplatte oder einem USB-Stick, wenn vom BIOS unterstützt, gebootet werden. Dadurch ergibt sich ein erheblicher Geschwindigkeitsvorteil und macht ein (fast) normales Arbeiten wie bei einer Festplatteninstallation möglich.

https://de.m.wikipedia.org/wiki/Kanotix
http://www.kanotix.com

[geier22]

Knoppix macht das übriges auch aus der Live- Dvd heraus (Klicki-Bunt i):
blkid:

Code: Alles auswählen

/dev/sde1: LABEL="KNOPPIX" UUID="5B6E-8E9F" TYPE="vfat" PARTUUID="8e0072e7-01"
/dev/sde2: LABEL="KNOPPIX-DATA" UUID="59e1ba47-7acc-48b3-b353-b43a024303e7" TYPE="reiserfs" PARTUUID="8e0072e7-02"

[smutbert]

[…]
Ich sehe deswegen von einer "normalen" Installation auf dem Stick ab, weil die ständigen Schreibzugriffe das Ding schnell schrotten würden.[…]

Wenn man eine normale Installation mit einem Live-System mit "persistence" (jeweils alles auf einem USB-Stick) vergleicht, steht zweifelsfalls die normale Installation besser da, glaube ich, was Zahl/Umfang der Schreibvorgänge angeht und schneller ist es iA sowieso.

Ich würde ja beispielsweise neben der bereits vorhandenen FAT-Partition eine zweite Partition für Linuxinstallationen anlegen und mit btrfs formatieren.
Mit noatime reduziert man die Zahl der Schreibvorgänge und wenn man dann noch die Kompression des Dateisystems aktiviert, dann hat man nicht nur weniger Schreibvolumen sondern die Daten können auch schneller gelesen und geschrieben werden. Als Draufgabe wird die Zahl der Linuxinstallationen auf dem Stick nur durch den zur Verfügung stehenden Speicherplatz limitiert - man kann in btrfs für jede Installation einfach ein eigenes subvolume anlegen. Das erfordert zwar etwas Handarbeit, aber das gilt für die Variante mit den Livesystemen ebenfalls.

Gratis dazu bekommt man Prüfsummen über die Daten auf der btrfs-Partition und Snapshots, die auf Wunsch auch read-only sein können.


Sticks mit bescheidenem Wear-Leveling könnten übrigens unter eine großen FAT-Partition, bei der ständig Schreibzugriffe auf die Dateizuordnungstabelle erfolgen, mehr leiden als mit der Variante mit normalen Installationen auf einer eigenen Partition.
(Und wenn der Stick ein gut funktionierendes Wear-Leveling hat, dann ists vermutlich eh egal, weil er beide Szenarios lange genug oder zumindest etwa gleich lang durchhält.)