staging.inyokaproject.org

Hey, mal ne Frage. Funktioniert bei euch folgender Befehl:

$ gunzip -c ~/image-sdx.img.gz | sudo dd of=/dev/sdx

Ich muss bei mir den ganzen Befehl als Root ausführen, also so:

# gunzip -c ~/image-sdx.img.gz | dd of=/dev/sdx

Liegts an mir oder ist das Wiki falsch? Hab leider grad kein aktuelles und frisch installiertes Ubuntu zur Hand, evtl. liegts einfach an meiner Konfiguration.

Müsste funktionieren, wobei ich statt -c normalerweise Pipes verwende, also

gunzip < image.gz | dd of=/dev/haudrauf

vielleicht lag das Image bei dir einfach im falschen Verzeichnis / mit den falschen Rechten?

Hi.

Wie sehen denn die Rechte von image-sdx.img.gz aus? (ls -la)

frostschutz schrieb:

vielleicht lag das Image bei dir einfach im falschen Verzeichnis / mit den falschen Rechten?

Nein, Verzeichnis und Rechte sind in Ordnung.

Dann liegts wohl an meiner .bashrc, hab da nen Alias für sudo drin ☺

EDIT: Lag tatsächlich an meinem Alias (das ich da nicht früher drauf gekommen bin). Hab ihn gerade rausgenommen und siehe da, es geht. Das sind so Momente, da könnte ich mich wieder über mich selbst ärgern.

Morgen ☺

Wie in diesem Thread besprochen stoppt beim Überschreiben der Festplatte das Programm pv nicht nachdem die Größe der Festplatte bereits erreicht wurde. Ich habe deshalb den Parameter -S im Wiki hinzugefügt. Sollte man den Parameter noch irgendwie beschreiben? Oder hatte es einen Grund, dass dieser nicht bereits im Wiki an dieser Stelle erwähnt wurde?

Und noch eine Frage: Gleich darunter steht eine Experteninfo wie man den Löschprozess beschleunigen kann indem man die Buffersize richtig wählt. Meiner Erfahrung nach reicht es einfach ein bs=8M an das Programm dd anzuhängen. Abgesehen davon (Auszug aus der manpage von pv):

Note that if the input size cannot be calculated, and the output is a block device, then the size of the block device will be used and pv will automatically stop at that size as if -S had been given.

Also wäre es zumindest beim letzten Befehl relativ unerheblich wie groß genau die Blocksize gewählt wird, sofern sie nicht zu klein gewählt wird (sonst geht die Datenrate in den Keller).

Developer92 schrieb:

Ich habe deshalb den Parameter -S im Wiki hinzugefügt. Sollte man den Parameter noch irgendwie beschreiben?

Gerne - idealerweise im Artikel pv.

Developer92 schrieb:

Meiner Erfahrung nach reicht es einfach ein bs=8M an das Programm dd anzuhängen.

Es gibt wenig Grund größere Werte als bs=1M zu verwenden. Braucht mehr RAM und wird nicht schneller.

Optimale Geschwindigkeit beginnt so bei bs=64k, nur der Default mit 512 Byte ist einfach zu langsam. bs=1M hat ansonsten den Vorteil daß man sich bei der Ausgabe "x Blöcke kopiert" ohne Kopfrechnen die Größe vorstellen kann, wenn x = 1M.

aasche schrieb:

Gerne - idealerweise im Artikel pv.

Done.

frostschutz schrieb:

Es gibt wenig Grund größere Werte als bs=1M zu verwenden. Braucht mehr RAM und wird nicht schneller.

Man könnte jetzt mit dem Totschlagargument schlechthin kommen: Wen juckt das bei mehr als 4GB RAM noch?

Allerdings erkennt jeder der weiter als 3 zählen kann die Ironie darin.

Developer92 schrieb:

Gerne - idealerweise im Artikel pv.

Done.

Sehr schoen - danke ☺

Hallo Leute,

ich versuche gerade, mit dd ein image zu erzeugen und dabei eine Stausanzeige zu erhalten. Dazu benutze ich die Befehlszeile aus dem Wiki

sudo dd bs=6144 if=/dev/sda17 of=/Daten/HD-Images/win7-10gb.img  & ddpid=$! ; while [ $(ps -a | grep $ddpid) ]; do kill -SIGUSR1 $ddpid; sleep 10; done 
[2] 3461
bash: [: Zu viele Argumente.

und erhalte die Fehlermeldung. Ich benutze Kubuntu 14.04. Was stimmt da nicht, und wie müsste das angepasst werden?

lionlizard schrieb:

sudo dd bs=6144 if=/dev/sda17 of=/Daten/HD-Images/win7-10gb.img  & ddpid=$! ; while [ $(ps -a | grep $ddpid) ]; do kill -SIGUSR1 $ddpid; sleep 10; done 
[2] 3461
bash: [: Zu viele Argumente.

Bei mir würde es so funktionieren:

sudo dd bs=6144 if=/dev/sda17 of=/Daten/HD-Images/win7-10gb.img  & ddpid=$! ; while [ "$(ps -a | grep $ddpid)" ]; do sudo kill -SIGUSR1 $ddpid; sleep 10; done

Wenn eine andere Shell verwendet wird und zusätzlich alles in einer Rootshell, könnte es aber auch so wie im Wiki-Beispiel funktionieren.

Die Befehlskette ist für sudo nicht so gut geeignet... und $(ps | grep) ist bäh. kill müsste dann wahrscheinlich auch per sudo erfolgen. Vielleicht ist das dann eher was für pv.

Ich rufe dd meist normal auf (im Vordergrund), schon allein weil ich zur Not per CTRL-C abbrechen können will. Ein watch -n 10 killall -SIGUSR1 dd o.ä. kann dann in einem zweiten Terminal laufen.

bs=6144 ist ziemlich schräg, nimm 1M. dd entwickelt erst so ab bs=64k die volle Geschwindigkeit, bs=1M dient dann der Leserlichkeit (x Blöcke kopiert = x MiB).

Ich habe jetzt gerade noch mal ein wenig getestet, und wie es scheint, liefert das "ps -a" zu viele Argumente:

 ps -a
  PID TTY          TIME CMD
 3104 pts/6    00:00:00 sudo
 3105 pts/6    00:00:01 bash
 4116 pts/6    00:00:00 ps

Ein

dd bs=4096 if=/dev/sda17 of=/Daten/HD-Images/win7-10gb.img  & ddpid=$! ; while [ $(ps -ao pid | grep $ddpid) ]; do kill -SIGUSR1 $ddpid; sleep 4; done 

funktioniert.

hakunamatata schrieb:

Bei mir würde es so funktionieren:

sudo dd bs=6144 if=/dev/sda17 of=/Daten/HD-Images/win7-10gb.img  & ddpid=$! ; while [ "$(ps -a | grep $ddpid)" ]; do sudo kill -SIGUSR1 $ddpid; sleep 10; done

Ja, so funktioniert es bei mir auch.

Kann das noch mal jemand überprüfen? Und wie soll man das ins Wiki schreiben?

Von der Formulierung her oder meinst du wegen der Syntax? Hier kann ich die Passage entsprechend anpassen.

vielleicht einfacher: while kill $ddpid ; do sleep 10 ; done

das ps grep braucht man nicht, kill liefert selber fehler wenn es das signal nicht schicken konnte. wenn dd fertig ist gibts dann irgendwann ein kill (12345) no such process und fertig.