|
Anzeige
|
USB-Stick mit dd: ISO-Image erstellenIch habe einen bootbaren 8GB-USB-Stick, der nur ca 500MEGA-Byte Daten drauf hat. Von dem würde ich gerne mit dd ein ISO-Image erstellen, aber ohne das es mir 7,5GB leeren Rauminhalt mit ins Image schreibt. Gibts dafür nen Kniff? Nach einer Wiederherstellung soll dieser Stick auch wieder bootbar sein. Clonezilla scheidet aus, das soll so sein, dass das an einem Rechner wiederherstellbar ist, der bereits ein Linux laufen hat. -niggs neu mit CZ booten.
Nein. Wenn da kein ISO-Dateisystem drauf ist, bekommst du auch mit einem Kniff mit dd keines davon erstellt. Wenn du ein ISO-Image davon haben willst, könntest du’s mit mkisofs oder genisofs probieren. Wenn’s aber gar nicht um ein ISO-Image geht, sondern um ein Image des Sticks: du könntest vor dem Erstellen des Images das Dateisystem auf dem Stick entsprechend verkleinern, und ein Image davon ziehen. Oder du schreibst den leeren Platz auf dem Stick explizit mit Nullen voll (dd if=/dev/zero of=/pfad_zum_stick/datei […]), löschst diese Datei im Anschluss und komprimierst das via dd gezogene Image dann – zusammenhängende Nullen lassen sich ausgezeichnet komprimieren, sodass die rausfallende Datei nur wenig größer, vielleicht sogar kleiner als die Daten auf dem Stick ist. könnte man mit dd evtl auch gleich direkt aus einem Archiv heraus den Stick wiederherstellen? Ja, du kannst das Archiv on the fly dekomprimieren und an dd pipen. Du kannst auch beim Auslesen schon die Ausgabe von dd an xz, oder was auch immer du nutzen willst, pipen, sodass die große Datei gar nicht erst auf deiner Platte landet. Genau, und zum "Nullen" der freien Bereiche kannst Du auch "fstrim /" verwenden. Archiv erstellen und komprimieren:
Archiv zurückspielen: (vorher alle Partitionen des Sticks un-mounten)
so ungefähr. Ja das mit dem Komprimieren klappt auch. Das erleichtert hier so einiges. Danke für die Tips
Das sollte eher so sein:
Sonst dekomprimiert es das Archiv, aber nicht nach stdout, in ne neue Datei, und damit landet dann nichts auf dem Stick. Statt gunzip kann man auch "gzip -d" nehmen. Auch wenn das für das reine Backup vom Stick nicht relevant ist: Wenn der bootbare USB-Stick aus einem Hybrid-ISO erstellt wurde, und das OS darauf keine automatischen Partitions-Resizes für Persistenz-Partion etc. macht, kriegt man das auch wieder als ISO image herunter und bootfähig auf eine CD oder DVD gebrannt. einfach dem "dd" zum Runterkopieren noch mit blocksize(bs) und count angeben, dass nur die ersten xxx MB kopiert werden sollen.
Dann muss ich ja schon wieder rechnen ;-]
Ja, richtig. Oder auch mit -c (hatte ich vergessen):
Dafür bekommst du den useless use of dd award von mir. Ansonsten sind sparse Files auch sehr schnuckelig.
Beitrag #7632977 wurde von einem Moderator gelöscht.
x*1 ist nicht besonders schwer zu rechnen. Hallo DesIntegrator,
wenn Dein USB-Stick dadurch entstanden ist, dass eine ISO-Datei direkt auf den Stick (z.B. mit dd) geschrieben wurde, dann würde ich folgendes probieren (hab's noch nicht gemacht!): Voraussetzung: Du hast erst einmal den Stick komplett z.B. mit dd in eine Datei dupliziert. Lösung 1: (die naive) Du durchsuchst mit einem geeigneten Hexeditor, z.B. HxD die Datei von hinten nach vorne visuell. Wenn nur noch Nullen auftreten, gehören die vermutlich nicht zur ursprünglichen ISO-Datei. Dann speicherst Du nur den Dateiausschnitt vom Anfang der Datei bis zum Anfang des Null-Bereichs, bzw. vielleicht 2100 Bytes dahinter (siehe Info aus Lösung 2). Lösung 2: (für den ambitionierten ISO-Cutter) Du schmökerst in der Format-Definition, z.B. hier https://wiki.osdev.org/ISO_9660#System_Area und suchst mit HxD nach dem "Volume Descriptor Set Terminator". Du speicherst dann den Dateiausschnitt vom Dateianfang bis 2048 Byte hinter dem Beginn des Terminators. Fazit: Der DesIntegrator sucht also nun den Terminator. :) Melde Dich 'mal um zu sagen, dass es geklappt hat oder mir irgendwo ein Denkfehler unterlaufen ist! ja, das klingt auch interessant. Könnte nicht schaden, wenn da nicht immer /irgendwo/ wieder die Info drin steckt, wie gross der ursprüngliche Stick war. Irgendwo kommen diese 8GB sonst ja immer wieder zustande. bei 8GB gehts ja noch halbwegs, aber wenn etwas von einer grossen Platte kommt, wirds blöd. Wenn das im jetzigen Falle dann vielleicht auf einen 1GB-Stick passen würde, müsste man keine Sorgen haben, ob im Bedarfsfalle das auch mal jaaah passt. wie gesagt, ich möchte den Umstand wenns geht vermeiden, dass ich zum sichern und Zurückspielen immer erst einen Rechner mit einem ext. Bootmedium neu booten muss. Das darf gerne aus einem laufenden System passieren. Also ist es doch ein ISO-Hybrid-Image eines Live-Mediums o.Ä.? Wär’s in dem Fall nicht besser, einfach das Ausgangsimage ins Backup zu packen? Ja das ist ein Acronis-Stick. Aber ich sehe grad, dass der eben installierte Hex-Editor mit 8GB garnicht klar kommt. Es lässt sich nichts bedienen (kein Markieren, Löschen... sonstwas) bei kleinen Dateien kein Prob. da brauche ich mal einen Tipp, was unter Mint läuft und 8GB-Dateien verarbeiten kann. Ein Hybrid-Iso enthält normalerweise auch eine Partitionstabelle. Diese sollte eigentlich (muss aber in der Theorie nicht...) den ganzen belegten Platz abdecken. fdisk -l /dev/usbstick im Zweifel mit der Dateisystemgröße aus dem ISO9660-Header abgleichen und den größeren Wert nehmen.
https://github.com/pixel/hexedit kommt mit großen Files klar. Vim sowieso, in Verbindung mit xxd (gehört zu vim).
Ist bereits installiert: NAME od - dump files in octal and other formats [ ..... ] EXAMPLES od -A x -t x1z -v Display hexdump format output
Nun ja – zwischen dumpen und editieren gibt es einen kleinen semantischen Unterschied ;)
Er soll/will ja nichts ändern.
Wollte er aber offenbar:
Nachdem ja schon Methoden genannt wurden das Problem mit dem LHC am CERN zu lösen, schlage ich einfach mal eines der einfachsten Werkzeuge vor welches ein Linux System zu bieten hat. Die Eingeweihten nennen es insgeheim ›cp‹
Gibt's auch, steht an prominenter Stelle in der zum besagten ›cp‹ Befehl gehörenden man-page beschrieben. In dem Fall wär’s gut, wenn du auch gleich den Weg zurück zu einem bootenden Stick für den Desintegrator aufzeigst. Im Grunde ist syslinux einfach zu handhaben, aber an der Art der Frage meine ich zu erkennen, dass es hier nicht die optimale Variante wäre.
Oh ja, das habe ich in der Tat vergessen. Also … dafür nimmt man dann natürlich eines der einfachsten Werkzeuge welches ein Linux System zu bieten hat. Die Eingeweihten nennen es insgeheim ›cp‹ ›cp‹ ist eine echte Bestie. Das Ding funktioniert sogar in beiden Richtungen.
Wenn du versuchen würdest, zu erfassen, worum es hier geht, wirst du erkennen, dass dein wenig subtiler Ironieversuch dich nicht gut dastehen lässt: es gibt zwei Möglichkeiten, hier mit cp zu hantieren. Einmal auf dem Devicefile – dann gibt es ein Image der Daten incl. des ganzen ungenutzten Platzes – genau den wollte der TE aber loswerden. Passt also nicht. Die zweite Möglichkeit wäre, das Dateisystem des Sticks zu mounten, und die Dateien mittels cp zu sichern. Kann man machen, allerdings fällt kein bootfähiger Stick raus, wenn man das auf gleichem Weg zurückkopiert. War also auch nix. Nun?
Auf Sparse Files die man mit cp erzeugen kann hatte ich ja auch schon hingewiesen.
Wenn du zumindest ansatzweise versuchen würdest zu erfassen was der ›cp‹ Befehl alles kann, kämst du nicht auf die Idee derart blödsinnige Statement öffentlich nieder zu schreiben. Selbstverständlich kann man mit ›cp‹ GANZ GENAU das erreichen was dem Threadersteller wichtig ist.
Dafür gab's von mir auch den Pluspunkt. Aber ich vermute (wie man unschwer bestätigt sieht) das selbst dieser einfache Parameter zu komplex ist um verstanden zu werden.
Dann zeig mal bitte: gegeben sei bootbarer Stick, dessen 8GB großes Dateisystem mit 500MB belegt ist; die Aufgabe lautet, die Daten so zu sichern, dass einerseits nur der belegte Platz gesichert wird, wobei der Stick beim Zurücksichern direkt wieder bootbar ist. Sollte deiner Darstellung nach ja ganz einfach mit cp machbar sein. Ein weiteres „RTFM doch selbst!kk“ von deiner Seite kann man getrost als „ich hab ja auch keine Ahnung!“ interpretieren, denke ich. Copypasta ist gefragt.
Sag mal, bist du zu schusselig um eine man-page zu lesen? Müssen wir dir erklären wie ›cp‹ funktioniert? Müssen wir dir erklären wie ein device angesprochen werden kann?
Gut. Du hast also keinen Schimmer. Sonst würdest du’s nämlich einfach hinschreiben :)
Du hättest als Kücken auf die Welt kommen sollen. Die bekommen auch alles erst einmal vorgekaut und vorverdaut. Ich frag mich halt, wie man darauf kommt, sich so zu verhalten, wenn man selbst offenbar keine Ahnung hat – in jedem anderen Fall wär’s ja doch ein Leichtes, spätestens nach der dritten Nachfrage einfach die Option hinzuschreiben – von mir aus dann auch mit ’nem hämischen Kommentar über mein Lesevermögen, oder so. Ich geb dir mal noch eine Chance: welche Option von ›cp‹ soll den gewünschten Effekt erzeugen? Ich hab ’n ungefähre Ahnung, was in deiner Vorstellung funktioniert – probier’s besser aus, bevor du hier antwortest. Es tut nicht, was du dir vorzustellen scheinst. Kann natürlich sein, dass mir tatsächlich was entgangen ist – liegt an dir, mich bloßzustellen :D OT: „Küken“ Die Loesung ist doch viel einfacher: Den 8 GB Stick mit dd auf einen 512 k Stick schreiben. Hab ich aehnlichst neulich gerade getan: Ein Rescuesystem, dass auf einem 64 GB Stick eine 32 GB Partittion fuer sich anlegt. Das ist schon bescheuert. Und dann in der 32 GB Partition gerade mal < 500 MB braucht... Also flugs den 64 GB Stick "roh" auf einen 16 GB Stick geschrieben. Natuerlich war das Dateisystem danach ein wenig karp0tt. Aber, der Stick bootet wie er soll. :)
Hast du noch alle Tassen im Schrank? So eine verblödete Anmache funktioniert bestenfalls im Kindergarten. Immerhin solltest du dich daran doch noch gut erinnern können.
Meine Güte … mach’ doch kein Drama draus – poste, dass ich blöder Noob zu doof wäre, ›--sparse‹ zu erkennen, und zitiere noch die Zeilen dazu vom Ende der Manpage. Ich poste dann das Ergebnis einer solchen Operation, und du räumst ein, dass da ja noch ein Schritt fehlen würde, und dass du ja gemeint hättest, dass das schon gemacht worden wäre – was aber nicht zu dem von dir geposteten Quote aus dem Eingangsbeitrag passt. Außerdem verweise ich noch auf die Probleme, die dabei auftreten können, die du im Anschluss kleinzureden versuchst. Dann weiß jeder, woran er bei dir ist (falls das bis hier noch für irgendjemanden nicht klar geworden wäre, denn nur sehr narzisstische Leute handeln, wie du es hier gezeigt hast), und der TE hat eine weitere Option für sein Vorhaben, die allerdings etwas Umsicht erfordert.
Im Rheinland sagt man zu solchen Reparaturmethoden "beimachen". Es gilt: Prestolith und Fliegendraht halten auch bei schneller Fahrt. :) Ich kann mich dunkel erinnern, dass ich in so einem Fall mal den Stick in ein Image geschrieben hatte, die Partition im Image verkleinern konnte, den Rest des Images gelöscht habe und dann das resultierende Image wieder auf einen kleineren Stick schreiben konnte. Ich weiß leider den genauen Weg dorthin nicht mehr.
Ganz schoen umstaendlich. Gerade neulich habe ich einen "Ubuntu"-Installationsstick, 64 GB, auf einen mit 32 GB kopiert. Das ging mit fdisk, mkfs-vfat und cp -r eigentlich ganz einfach. Und der bootete auch. :) Ich weiss aber nicht mehr, ob das CSM da helfend eingegriffen hat, oder er aus dem UEFI bootete. Was ja schlussendlich auch egal ist.
Naja, solange der prim./sek./tert. Bootlader auf dem Stick mit dem karp0tten Filesystem noch klarkommt, ist es ja Weisswust. Ich kenne auch weder "Prestolith" noch "Fliegendraht". Frohe Ostern! Um die Verwirrung noch weiter zu steigern hier ein für diesen Zweck ausreichendes Miniscript um den Offset zu finden ab wann in einem File nur noch Nullen sind:
Wenn man weiß wie ein ext4 Dateisystem aufgebaut ist macht es wenig Sinn nach dem letzten Byte zu suchen.
dd hat sogar die passenden Parameter dazu: conv=notrunc,noerror
So würde ich es auch machen. resize2fs -M
Was bringt "continue after read errors" konkret in diesem Fall? Hallo Motopick,
Prestolith ist eine Spachtelmasse, "Fliegendraht" ist eine Umschreibung für "Glasfasergewebematte". :) Hallo Alexander,
die startfähigen USB-Sticks entstehen typischerweise unter Nutzung von aus Dateiabbildern für optischen Datenträger, die bootfähig sind. Diese optischen Datenträger, wie z.B. CD-R oder DVD-R bergen ein IS09660-Dateisystem. Vermutlich mit ein paar Tricks werden diese ISO-Dateien so erstellt, dass sie auch bootfähig sind, wenn man sie direkt (also nicht auf Dateiebene) auf eine Festplatte schreibt. Auch dort bleibt dann das ISO9660-Dateisystem erhalten!
Hallo Peter.
Vermutlich durch geschickte Sortierung der Dateien im Track. :) Ich habe mir mal eine bootfaehiger Solaris CD gebaut. Und das ging eigentlich ganz einfach. Mann nimmt sich eine Harddisk passender Groess, erzeugt darauf die Slices, in den Slices die (UFS-)Filesysteme, und bevoelkert die Filesysteme in den Slices mit den passenden Bootladern fuer die verschiedenen Architekturen. Dann "kopiert" man einfach seine Dateien in das "grosse" Filesystem das spaeter das Root-FS wird. Und die ganze Platte, muss man dann nur noch 1:1 auf das "ISO-Filesystem" einer CD brennen. Dazu braucht es nicht einmal ein mkisofs. Damit kann man dann von der Sun Classic, ueber den Sun Server 10 bis zur Sun Ultra davon booten und hat zumindest ein R/O Root-FS. Aber, wo bleibt dabei eigentlich das ISO-Filesystem? :) Auf der CD sind nur viele UFS-Filesysteme. Bei El-Torito weiss man ja woran man (nicht) ist... Hallo Motopick, das klingt sehr beeindruckend, aber beim Thema Solaris bin ich definitiv kompetenzbefreit!
Ja schade. Die CD war recht nuetzlich um im Bedarfsfall ohne Geschraube eine Sun zu klonen. Die exportierte naemlich ihr Root-FS auch per NFS, und hatte auch die uebrigen Serverdienste die man zum Remote-Boot brauchte. Benutzt wird wohl das grundsaetzliche ISO-Format, also Fehlererkennung und Fehlerkorrektur, aber wohl nicht die Spezifika der Anordnung der Daten, Dateinamen, Verzeichnisse, ... wie sie der ISO-Standard vorsieht. Das sieht man ja auch bei Rettungssystemen, die FAT32/exFAT basiert sind, und so direkt auf eine CD/Stick geschrieben werden. Frohes Osterwochenende! Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
