2

I'm using macOS Catalina.

I have a 16GB microSD card that had Raspbian on it, which is 2 partitions:

  • 45MB boot partition
  • large Linux partition

I needed to clear it, so I plugged the SD card into my Mac and did this:

$ sudo bash -c 'gdd if=/dev/zero of=/dev/rdisk2 bs=4M; sync'

gdd is the GNU version of dd, installed using homebrew.

/dev/disk2 is definitely the right microSD card I'm zeroing out, confirmed with the Disk Utility.

I use rdisk instead of disk because it's much faster, and points to the same disk.

When the command starts running, the macOS Disk Utility shows the drive name change from "boot" to something like "Generic Flash Device" or something like that, so I know it's definitely doing something.

gdd runs for a while, and after a few minutes, shows this:

gdd: error writing '/dev/rdisk2': Input/output error
3799+0 records in
3798+0 records out
15931539456 bytes (16 GB, 15 GiB) copied, 419.932 s, 37.9 MB/s

The error makes sense, since it tries to write zeroes to the microSD card until it runs out of space. At this point, the SD card should contain all zeroes. I've done this literally dozens of times on Linux. It never fails. I've even done this successfully on High Sierra dozens of times.

What doesn't make sense to me is that as soon as the gdd process is done running, Disk Utility shows the SD card as "boot" again, it automounts at /Volumes/boot, and the files are still there. How is it that gdd shows that it successfully wrote the entire SD card full of zeros, and yet the data is still there?

Update: The Mac I was doing this on just happened to have VMware fusion on it, so I did this:

  • Created a VM, attached Arch Linux ISO to it, and booted it
  • Attached the USB card reader device to the VM
  • Used dd in Arch to zero out the drive

I shut down the VM, and the USB device reattached to the macOS. Exactly the same thing - the "boot" partition is still there, still auto-mounts, and has all the files there. What is going on?

Update 2: I can't even seem to delete the partitions. I use the Arch VM, and either fdisk, or cfdisk to delete the 2 partitions on the SD card, it says it deleted them successfully, but as soon as I check again, the partitions are still there. The SD card is brand new. I'm not seeing any I/O errors reading from, or writing to it that would even suggest that its damaged.

Update 3: I can't even delete the files. I mount either partition under Arch, use rm -rf * to delete ALL files on that partition, and ls shows that they are gone. I unmount the partition, and immediately mount it again, and all the files are still there.

5
  • 1
    Why not use diskutil to erase and prepare this? – bmike Jul 5 '20 at 20:51
  • Mostly because I'm a Linux guy - not a mac guy. Does it matter? MacOS is supposed to give any process that has permissions to read from or write to /dev/rdiskX absolute access to the device. dd has been used for low level disk operations for decades. Am I wrong? – John Jul 5 '20 at 20:53
  • Did you unmount/eject the drive before running dd? – nohillside Jul 5 '20 at 21:05
  • Yes. You can't eject it without the device disappearing, but I unmounted it, as I have dozens of times in the past. Also, while using VMware, as soon as you tell it to attach the USB drive to the VM, it automatically detaches it from the host MacOS, making the device disappear from Disk Utility completely, and show up in the VM. – John Jul 5 '20 at 21:33
  • Thanks John. It was not a criticism and just seeing if you wanted the end result more than the explanation why dd can trip up. +1 sorry for not voting sooner – bmike Jul 6 '20 at 0:27
1

The error makes sense, since it tries to write zeroes to the microSD card until it runs out of space.

You've misread the error.

gdd: error writing '/dev/rdisk2': Input/output error

That means there was an error writing to the device. The command you issued should do what you want - fill the drive with zeros, but this error says otherwise.

What doesn't make sense to me is that as soon as the gdd process is done running, Disk Utility shows the SD card as "boot" again, it automounts at /Volumes/boot, and the files are still there. How is it that gdd shows that it successfully wrote the entire SD card full of zeros, and yet the data is still there?

gdd did no such thing! It gave you an I/O error message when it was writing to the device. Your original files are there because nothing was written to the SD card.

Possible causes:

  • The card could be write protected
  • The card could be defective (especially if counterfeit - i.e. it reports 16GB but only has 2GB of actual storage)
  • The USB card reader could be defective
6
  • 1. It didn't take 419 seconds at 37.9 MB/s to do nothing. It definitely did something. 2. When you don't give dd a limit on how much data to read or write, it reads until the source runs out of data, or the destination runs out of space. /dev/zero is never going to run out of data. /dev/rdisk2 does NOT have unlimited space. It is absolutely going to run out of room, as soon as every block has been written to. This makes total sense, and happens every single time, on every single system I've ever run this on, which is easily over a hundred times. This error is expected – John Jul 6 '20 at 1:24
  • I have never gotten an I/O error on any device that was working properly. dd doesn't write data until it errors out and if it did you would get the error "No Space Left On Device" rather than I/O error. And speaking from an entirely pragmatic point of view, that's a horrible way to indicate to a user "process done." – Allan Jul 6 '20 at 1:47
  • dd is low level. It has no idea, and doesn't care, where it's reading from, or what it's writing to. Only the interfaces (file/stdin/etc). It's not going to tell you "your SD card ran out of space". It tells you exactly the error it ran into - it couldn't write anymore. Also, I use dd all the time, but I'm sure there are hundreds of uses of dd I haven't tried. Just because you've never run into this doesn't mean it's not expected. It just means you've never tried to zero out a device. Try it. I can pretty much guarantee you'll see an error very similar to this one, depending on your dd version – John Jul 6 '20 at 14:12
  • Looking at the Securely wipe disk Arch Wiki page, it appears that while a dd error is expected when wiping the disk in this way, the exact error they get is dd: writing to ‘/dev/sdX’: No space left on device. Mine is an IO error. I'm not sure why it has the ability to write to the majority of the device, but not that tiny section. Nothing is mounted. Unless someone has a different theory, it's starting to sound like you were right, and the card is bad – John Jul 6 '20 at 14:27
  • Assuming what you say is correct, both dd included with macOS and gdd as you’ve used both issue the same error “No space left on device” so, your assumptions are still incorrect. – Allan Jul 6 '20 at 19:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .