Clonezilla Live USB

Question

Mein Ziel ist es, Clonezilla-Images auf/von einem 16 GB-Laufwerk zu speichern/wiederherzustellen.
Da Images groß sind, brauchte ich etwas anderes als FAT(32).
Ich entschied mich für NTFS, damit ich ohne zusätzliche Schwierigkeiten auf Images von Windows-Rechnern zugreifen konnte. Hier bin ich also und versuche, ein Clonezilla-Image auf ein NTFS-USB-Laufwerk zu schreiben, und es scheitere sowohl unter Windows als auch unter Ubuntu. Beispielsweise RUFUSwird angezeigt, dass das Clonezilla-Image mit dem NTFS-Partitionstyp nicht kompatibel ist und FAT32 vorschlägt. UnetbootinEin gemountetes USB-Laufwerk, das in NTFS ist, wird einfach nicht als verwendbar (zum Schreiben) aufgelistet.
Also habe ich den obigen Befehl verwendet mkusb, was eine nette GUI ist . Das Ergebnis war ein leerer (nicht partitionierter) Speicherplatz und eine 3 MB große Partition. Obwohl der Speicherplatz „dd
ungeteilt" (siehe ausgewählte Zeile im Bild) das USB-Laufwerk ist immer noch bootfähig (keine Ahnung, warum das Dd-Verfahren für eine .iso solche Auswirkungen hat).
Also habe ich auf den Resten des USB-Laufwerks eine 15 GB große NTFS-Partition erstellt und erfolgreich einige Windows-Partitionsabbilder auf diesem neu erstellten Teil des USB-Laufwerks gespeichert.
Wenn ich jetzt versuche, den NTFS-Teil des USB-Laufwerks als /home/partimag(Standardquellverzeichnis zum Speichern/Wiederherstellen von Abbildern) zu mounten, wird in der GUI nach Force Mount gefragt (was keine Auswirkungen hat) und sdbin der Konsole wird ehrlich gesagt angezeigt, dass „Ressource belegt“ ist.
Das funktioniert jedoch trotzdem, wenn Clonezilla von einem separaten USB/einer separaten CD gebootet wird

Meine Fragen: Erstens. Ist es überhaupt möglich, Clonezilla zu booten UND Images vom selben USB-Laufwerk wiederherzustellen? Zweitens: Hängen meine Probleme damit zusammen, dass ich eine nicht so gute DD-Methode verwende (ich habe das Gefühl, dass SDB voll ausgelastet ist, weil dieser bootfähige 200-MB-Teil mit Clonezilla am Anfang des Laufwerks nicht als Partition erkannt wird, was einfach dazu führt, dass mountALLE Partitionen des USB-Laufwerks gesperrt werden)? Oder habe ich etwas anderes übersehen?

PS das ist vielleicht eine dumme Frage, aber gibt es eine Möglichkeit, das 200mb Clonezilla-Image zu ddnur sdb1? Ich meine, vielleicht würde das dazu führen, dass Clonezilla normalerweise den NTFS-Teil des USB-Laufwerks mountet?

Answer 1

Lösung:

Proceed with FAT32 - 4gb limit wont cause you an issue.  You dont have to worry.

Grund:

1. Clonezilla teilt große Dateien automatisch in Vielfache von 4 GB auf (auch bei NTFS-Dateien)
2. UEFI-basierte Systeme erlauben (normalerweise) keinen Bootcode in NTFS. Aus diesem Grund empfehlen Rufus und andere FAT32. Dies liegt an den Spezifikationen von UEFI.

Andere Fragen:

Erstens: Ist es überhaupt möglich, Clonezilla zu booten UND Bilder vom selben USB-Laufwerk wiederherzustellen?

Ja. FAT32 ist zum Booten erforderlich (aufgrund von UEFI)

Hängen meine Probleme damit zusammen, dass ich eine nicht so gute DD-Methode verwende (ich habe das Gefühl, dass SDB völlig ausgelastet ist, weil dieser bootfähige 200-MB-Teil mit Clonezilla am Anfang des Laufwerks nicht als Partition erkannt wird, was dazu führt, dass Mount ALLE Partitionen des USB-Laufwerks sperrt)? Oder habe ich etwas anderes übersehen?

Es liegt nicht an der ISO/DD-Methode, sondern an der nicht FAT32-formatierten Bootpartition.

Answer 2

Clonezilla Live USB läuft standardmäßig vollständig aus dem RAM Ihres Computers, was es sehr schnell macht, und da Clonezilla Live USB portabel ist, kann dieselbe Installation von Clonezilla Live USB auf mehreren Computern verwendet werden.

Clonezilla Live USB funktioniert sehr gut mitUNetbootin(Windows/Mac/Linux) und UNetbootin ist auch in den Standard-Ubuntu-Repositorys. Clonezilla ist in der Liste der kompatiblen Distributionen von UNetbootin im == Select Distribution ==Dropdown-Menü von UNetbootin. Sie sollten den USB-Stick zuerst in GParted als FAT32 neu formatieren, wenn Sie den USB-Stick jemals zum Booten einer Linux-Distribution verwendet haben.

UNetbootin wurde in Ubuntu 18.04 und höher aus den Standard-Repositorys entfernt. Als ich die integrierte Anwendung Startup Disk Creator als UNetbootin-Ersatz-App mit einem Nicht-*Buntu-Live-ISO-Image testete, funktionierte sie in Ubuntu 18.04.