dd von USB auf Festplatte läuft außerhalb der Größe

Hinweis: In dem Thema dd von USB auf Festplatte läuft außerhalb der Größe gibt es 4 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • dd von USB auf Festplatte läuft außerhalb der Größe

    Hi Leutz, ich habe da ein für mich kurioses Verständnisproblem.

    Ich möchte ein USB Livemedium ändern, sodass die Ramdisk nicht 512 MB sondern mehr hat.
    Nachdem das Livemedium offensichtlich als CD erkannt wird, kann es nicht geändert werden.
    Überlegung: Mach ich eine Kopie.
    Die schaut dann bei mir so aus:

    Quellcode

    1. dd if=/dev/sdb |pv| dd of=/home/gerald/Downloads/iso/2.iso
    2. ^C67GiB 0:05:20 [21,5MiB/s] [ <=> ]
    3. 18191264+0 records in
    4. 18191264+0 records out
    5. 18191265+0 records in
    6. 18191264+0 records out
    7. 9313927168 bytes (9,3 GB, 8,7 GiB) copied, 320,33 s, 29,1 MB/s9313927168 bytes (9,3 GB, 8,7 GiB) copied, 320,333 s, 29,1 MB/s
    jetzt muss man sagen, dass die Originalgröße nur 2,1 GB beträgt und offensichtlich hätte hier dd bis zum bitteren Ende weitergeschrieben.
    Es ist mir bekannt, dass man dd normalerweise verwendet um von einem zum anderen Speichermedium zu schreiben, also eine idente Kopie zu machen. Nachdem aber if/of inputfile/outputfile heißen soll, klang es für mich plausibel dass ich /.../.../2.iso machen könnte.


    1. kann ich eine iso von einem USB Stick auf die Festplatte mit dd ziehen?
    2. wenn ja, was habe ich in meiner Ausführung falsch gemacht?
    3. wenn nein, wie wäre es besser zu lösen?

    Vielen Dank!

    Für den Inhalt des Beitrages 113918 haftet ausdrücklich der jeweilige Autor: JeyF123

  • Man kann mit dd selbstverständlich auch ein .iso von einem Stick auf die Platte schieben.
    Auf einem Stick liegt aber keine .iso Datei.
    Also musst du bei dd die Größe selbst ermitteln und beim Aufruf mit angeben.
    Oder du machst schlicht ein dd if=/dev/sd<tatsächlicher-Buchstabe-hier> of=/home/luser/mein.iso
    Damit wäre dann das .iso File genau so groß, wie der Stick selbst.
    Völlig unabhängig von der tatsächlichen Größe des originalen Laufwerkabbilds.
    Am Ende fänden sich die Reste aus der vorherigen Verwendung oder zufälliger Datenmüll.

    dd ist ein Low-Level Kopiertool. Es hat keine Vorstellung von Dateigrößen, Dateisystemen, Directories oder Files. Es kennt nur Blöcke und die Geometrie des Devices selbst.

    Der Umweg über pv ist auch unnötig. dd reagiert auf -SIGUSR1 oder -SIGUSR2 (weiß ich nicht mehr; ausprobieren).
    Wird dieses Signal erhalten, spuckt dd Statistikdaten über den Kopierjob aus.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 113920 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • bin noch nicht ganz dabei. Aber ich glaube, dass ich den Kern meiner Unkenntnis erkannt habe.
    Es geht nicht um die Datei, sondern um den Stick selbst.
    Das ist ein 32 GB Stick. Dementsprechend hätte er das gesamte Medium übertragen.
    Stimmt das jetzt so?

    ich könnte statt dieser |pv| Struktur auch

    Quellcode

    1. dd SIGUSR1 if= ...

    schreiben?`

    Für den Inhalt des Beitrages 113921 haftet ausdrücklich der jeweilige Autor: JeyF123

  • Genau.
    Er hätte stur komplette 32GB kopiert.

    Ein SIGxxx kann man bei fast keinem Befehl als Option angeben.
    Signale sind mittel der IPC (InterProcessCommunication).
    Im Prinzip schickt der Kernel einfach einen Zahlenwert zu einem laufenden Prozess.
    Traditionell ist für das Senden solcher Signale der Befehl kill zuständig.
    kill hat seinen Namen tatsächlich nach dem häufigsten Gebrauch erhalten.
    Das killen eines Prozesses ist nichts anderes, als das Signal -SIGTERM an den Prozess zu senden.
    (kill sendet ein paar Signale mehr, falls der Prozess nicht reagiert)

    Shell-Script

    1. # sich alle verfügbaren Signale anzeigen lassen mit -l == list
    2. # die Zahlen und die jeweiligen Signalnamen kann man synonym verwenden
    3. #
    4. kill -l
    5. 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
    6. 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
    7. 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
    8. 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
    9. 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
    10. 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
    11. 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
    12. 38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
    13. 43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
    14. 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
    15. 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
    16. 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
    17. 63) SIGRTMAX-1 64) SIGRTMAX
    18. # den dd Befehl ausführen
    19. # das nachgestellte & sendet den Prozess in den Hintergrund
    20. #
    21. dd if=/irgendwo/irgendwas of=/anderswo/kopie &
    22. # die spezielle Shellvariable $? enthält die PID des Prozesses,
    23. # der zuletzt in den Hintergrund geshickt wurde. Die merken wir uns
    24. pid_of_dd=$?
    25. # und nun können wir beliebig den Status ausgeben
    26. kill -SIGUSR1 $pid_of_dd
    Alles anzeigen
    Da es Signale zwischen Prozessen sind, sind mindestens zwei Prozesse nötig.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Berichtigung ()

    Für den Inhalt des Beitrages 113923 haftet ausdrücklich der jeweilige Autor: Berichtigung

www.cyberport.de