I'm using the dd command to create a bootable usb from iso file:

sudo dd if=~/Desktop/ubuntu.iso of=/dev/sdx bs=1M

After pressing enter it momentarily exits and gives me:

915+0 records in 915+0 records out 959447040 bytes (959 MB) copied,
0.539375 s, 1.8 GB/s

So it's like running in background because I can see that the flash drive is working. Eventually it will stop copying and I can remove the drive successfully but the question is why doesn't dd command wait for copying to finish. Why does it run in background. And how can I make it wait?

  • 4
    Have you tried sync? – choroba Jul 9 '13 at 15:32
  • 1
    @choroba Does it make sense to run 'sync' if the system's already writing data to the flash drive? – Kirill Ivlev Jul 9 '13 at 16:03
  • I am not sure, byt sync might wait. – choroba Jul 9 '13 at 16:05
  • 2
    dd also has some sync options, for example conv=fsync. That said, I never had to use it with /dev/sd* drives myself. If you literally used /dev/sdx my guess would've been you had a useless 959MB file in /dev (ramdisk) now... – frostschutz Jul 9 '13 at 16:07
  • 1
    @frostschutz I used /sdc for my flash drive – Kirill Ivlev Jul 9 '13 at 16:23

Despite popular belief, dd is a perfectly ordinary command, it isn't more low-level than cat or cp. Your command reads from the disk cache and writes to the disk buffers like any other command.

In order to make sure that the data is fully written to the physical media, you need to call sync. The command sync flushes all output buffers to the disk(s). When the sync command returns, the data has been fully written.

sudo dd if=~/Desktop/ubuntu.iso of=/dev/sdx bs=1M; sync

Most of the time, you don't need to call sync, because unmounting a filesystem does the same job. When the umount command returns, or when you get a confirmation message after clicking “Eject”, the buffers have been written to the disk. Here, you're directly writing to the disk without going through a mounted filesystem, so you need to explicitly flush the buffer.

Note that instead of dd, you could use tee. This has two advantages: there's less risk of inverting the source and destination due to a typo, and it's probably slightly faster.

<~/Desktop/ubuntu.iso sudo tee /dev/sdx >/dev/null; sync
  • 1
    How about the "Eject" or "Safely Remove" buttons/icons. Wouldn't they also call sync before giving the "OK to remove" notification? – user68186 Jul 9 '13 at 16:11
  • 1
    You likely want to use sudo tee /dev/sdx >/dev/null, otherwise the copying process would still be very slow due to data being written to console output. – Lekensteyn Jul 9 '13 at 16:26
  • 1
    @user68186 They don't call the sync command, but they do the same job under the hood. – Gilles 'SO- stop being evil' Jul 9 '13 at 16:30
  • 7
    This answer is wrong. Without conv=fdatasync, the dd command does not wait to finish until the data is written to the disk, as the OP requested. Furthermore, the sync command schedules a sync operation, but it immediately returns; it does not wait to return until after the data are written to the disk. – vy32 Jun 26 '16 at 17:52
  • 1
    @vy32 you're right dd won't wait for the cache to be flushed without conv=fdatasync etc. but on non-ancient Linux you're incorrect about sync not waiting. You can see coreutils' sync(8) making the sync(2) syscall. The sync(2) man-page says "Before version 1.3.20 Linux did not wait for I/O to complete before returning." so sync(8) won't return until the disk acknowledges the writes (or an error is triggered). – Anon Oct 9 '19 at 5:56

Try this:

sudo dd if=~/Desktop/ubuntu.iso of=/dev/sdx conv=fdatasync bs=1m

The conv=fdatasync tells dd to use the special options to make sure that the data get written to the physical device.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.