0

I'm attempting to burn the latest raspbian image to a microSD card on a mac (macos sierra: 10.12.6) following the official instructions for doing so.

INSTALLING OPERATING SYSTEM IMAGES ON MAC OS

I've done this many times before without difficulty but recently something has changed which is is generating this error:

dd: /dev/rdisk3: Invalid argument

Interestingly, this error occurs both

  1. when I use the version of dd that comes with macos and
  2. when I use the version of dd from gnu coreutils (installed via homebrew)

    😈 >which --all dd
    /usr/local/opt/coreutils/libexec/gnubin/dd
    /bin/dd

with macos dd:

 😈   >date; sudo /bin/dd bs=1m if=2017-07-05-raspbian-jessie.img of=/dev/rdisk3; date
Sun Aug  6 12:24:33 PDT 2017
dd: /dev/rdisk3: Invalid argument
4445+1 records in
4445+0 records out
4660920320 bytes transferred in 189.129174 secs (24644111 bytes/sec)
Sun Aug  6 12:27:42 PDT 2017

with gnu dd:

 😈   >date; sudo dd bs=1M if=2017-07-05-raspbian-jessie.img of=/dev/rdisk3; date
Sun Aug  6 11:50:48 PDT 2017
Password:
dd: error writing '/dev/rdisk3': Invalid argument
4445+1 records in
4445+0 records out
4660920320 bytes (4.7 GB, 4.3 GiB) copied, 189.93 s, 24.5 MB/s
Sun Aug  6 11:54:04 PDT 2017

Switching from "/dev/rdisk3" to "/dev/disk3" seems to make the error go away but it take 20 minutes to complete instead of 3 minutes.

/dev/rdisk3 => /dev/disk3

 😈   >date; sudo /bin/dd bs=1m if=2017-07-05-raspbian-jessie.img of=/dev/disk3; date
Sun Aug  6 12:35:20 PDT 2017
4445+1 records in
4445+1 records out
4661483821 bytes transferred in 1213.807451 secs (3840382 bytes/sec)
Sun Aug  6 12:55:34 PDT 2017

3 minutes is preferable to 20. In the past rdisk has worked without error. Given that this error occurs with both versions of dd and the source code for each is quite different, I'm guessing that the error is occurring during the mounting stage at the end of the burning. i.e. dd is making a sys call to mount the volume and this sys call is returning the error (I think).

2 questions:

  1. Does anyone know for certain why this error is being generated?
  2. The volume seems to actually mount, so is it safe to ignore the error?
2

There is a bug in the latest image. It is NOT a complete number of blocks (as indicated by the +1).

It should be possible to burn it by using dd parameters to write incomplete blocks dd conv=sync (I have not tried this), but the current workaround is to use Etcher.

Future images will consist of complete blocks.

  • this is the correct answer, thank you ! Other google results suggest changing rdisk# to disk#, but that halves throughput for some reason. – Eric Nov 18 '17 at 12:24
  • 1
    @Eric rdisk is "raw" disk mode aka a character mode device, rather than a block mode device, which is buffered by the OS. If you look in /dev you will see both. disk# is slower, sometimes only 10% but at other times can take 10 times as long. Generally you can only use raw mode on an unmounted drive. See man hdiutil – Milliways Nov 19 '17 at 5:31

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.