-1

This command produced the error mentioned above after 9 h (preparing a 2 TB hdd for encryption):

time openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom \
bs=128 count=1 2>/dev/null | base64)" -nosalt </dev/zero \
| pv -bartpes 1884183960000  | dd bs=512 count=1840023391 of=/dev/sdc3

I got at 50% (9 h) a total written GB count as well as a bs/count information.

Is it possible to resume this process?

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
John Jane
  • 1
  • 4

1 Answers1

2

I think you need the seek=BLOCKS which should make dd start writing at the block next to BLOCKS of your disk address space.

Supposedly you should also decrease count by that number of blocks as well.

kostix
  • 1,150
  • 1
  • 7
  • 13
  • You again. And another perfect answer for me. TYSM all the best from a German questioner. – John Jane Feb 27 '15 at 20:06
  • I found another explanation regarding my question to obs/ibs: http://unix.stackexchange.com/questions/108858/seek-argument-in-command-dd What I didn't found was a real difference between bs and obs/ibs together with seek. The man isn't clear frmpov. – John Jane Feb 27 '15 at 20:23
  • I found something about seek/skip: skip=SKIPBLOCKS | Skip blocks (bs/ibs) of the INPUT-device(!) seek=SEEKBLOCKS | Skip blocks (bs/obs) of the OUTPUT-device(!) – John Jane Feb 27 '15 at 20:37
  • @JohnJane, keep in mind that your source device is not really a device but rather a stream: *skipping* N bytes from it would litreally mean *reading* them (or failing with "blah blah the device is not seekable" -- depending on how smart `dd` is; both cases are unacceptable. In either case, skipping a part of random input has no sense. *Seeking* in the destination device, conversely, has sense: it will position the file pointer to the correct address using appropriate syscall. – kostix Feb 27 '15 at 22:56
  • Yes, I am aware of that. But I run into the same error after 9 h (50%) again today. Would you do me a favor and try to replicate the dd values to check if I may use/calculated the wrong ones? – John Jane Feb 28 '15 at 09:23
  • I can post all necessary information of the error, including everything you need (/proc/partition ..). – John Jane Feb 28 '15 at 09:24
  • Maybe I miss calculated pv and in real it is 100%? – John Jane Feb 28 '15 at 09:46
  • dd error output: `error writing output file` `1840023391+0 Datensätze ein` <--100% correct `1840023391+0 Datensätze aus` <--100% correct `942091976192 Bytes (942 GB) kopiert, 33610,4 s, 28,0 MB/s` <--50% BUT the number `942091976192` is exact the multiplication of `512*1840023391`! I feel so stupid. It is in front of me and I can't see it. – John Jane Feb 28 '15 at 16:05
  • @JohnJane, I may be a bit lost here, but if you're using `seek=N` to make `dd` *continue* writing to the target device, you'll have to decrease its `count` parameter by the value of `N` -- otherwise `dd` will try to write past the end of the device (which is not a regular file and hence can't grow). Is this your problem? – kostix Mar 02 '15 at 10:42
  • @JohnJane, you might also have a "not really a problem" problem here: you might for some reason have miscalculated the amount of data to write because different tools might use different units for their display. For instance, `blockdev --getsz /dev/sdaX` would report the size in units of 512 bytes while the output from `cat /proc/partitions` uses units of 1024. And you see, if the "target" size you've calculated is off by at least a single block, writing that one block will fail. But note that *all the blocks before it have been written* just okay, so no worries here. – kostix Mar 02 '15 at 10:54