1

Trying to copy Raspberry Pi OS to image using dd.

$diskutil list /dev/disk2
/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.9 GB    disk2
   1:             Windows_FAT_32 boot                    268.4 MB   disk2s1
   2:                      Linux                         2.7 GB     disk2s2

Running sudo dd bs=1m if=/dev/rdisk2 of=/Users/sunknudsen/tmp/pi-clean.img works but includes unallocated space which is inefficient.

sunknudsen
  • 447
  • 1
  • 5
  • 14
  • You'll have to shrink the image first, or create one that fits. – goldilocks May 15 '21 at 15:52
  • Thanks for helping out... I removed init=/usr/lib/raspi-config/init_resize.sh from /boot/cmdline.txt so I believe I don’t need to shrink image first. – sunknudsen May 15 '21 at 15:57
  • 1
    So to clarify, the "unallocated space" you are referring to is the rest of the SD card? Ie., you do want the entire 2.7 GB partition but not the rest of the ~16 GB card. You could either copy the two partitions individually and concatenate them, or else create an image and copy in the content. I haven't tried the first method, but it should work if done properly. – goldilocks May 15 '21 at 16:37
  • dd has no idea of file systems. If that matters to you, use a dump/restore tool knowing of either the file systems or files. Plenty exist. – Thorbjørn Ravn Andersen Sep 26 '23 at 10:03

3 Answers3

2

dd by default copies the physical data - even if the data is zeros SD clone from menu in Raspberry OS uses "cp" command - I checked this while doing the clone ;-) But SD clone does much more than copying only the data (prepares partition table, modifies the /etc/fstat etc.) - it is binary file, not a script - so kind of difficult to see how it does step by step I did not manage to get anything better and efficient than SD clone yet - neither on Linux nor on MacOS - I would like to know it as well.

1

dd copies blocks (regardless of their contents).

macOS will not read the ext4 filesystem and is thus incapable of determining contents or shrinking the image.

You need a Linux system (which can be the Pi). There are many answers explaining how to do this.

You CAN determine the size of MBR plus boot plus root and instruct dd to copy just that, but this seems rather pointless as an unexpanded image is unusable.

I have written scripts using fdisk on the Mac to manipulate Pi image partitions but this is error prone and tedious and ultimately not particularly useful.

If you want to do this on a one off it is probably easier to manually calculate the size (using the output of fdisk list).

Milliways
  • 59,890
  • 31
  • 101
  • 209
  • Thanks for helping out. What do you mean by “unexpanded image is unusable”? – sunknudsen May 15 '21 at 23:11
  • Would love to get your feedback on https://gist.github.com/sunknudsen/2b684774df8973f866e851b56ddaff11. Btw, I resized disk2s2 using GParted first so image is actually expanded enough for use case. Trying to create image of microSD card on macOS. – sunknudsen May 16 '21 at 00:19
  • @sunknudsen The image has little free space - just enough to boot. If you tried using it it would rapidly run out of space and lock up. See https://raspberrypi.stackexchange.com/a/44700/8697 for a script sample – Milliways May 16 '21 at 00:24
0

With PiShrink

You might want to look at github.com/Drewsif/PiShrink — it won't run on bare metal mac, so you'll need some kind of emulation/virtualization environment (e.g. VirtualBox/UTM/multipass etc; verified to work fine under multipass), or an actual linux box.

Once you have created the full image with dd, clone the repo or download the file (it's a single bash script) and run in a linux env:

# shrink in-place (modifies original image)
sudo ./pishrink.sh image.img
# shrink to a new file (leaves original image intact)
sudo ./pishrink.sh image.img image-slim.img

It will take a couple of minutes to shrink the image size.

Most of the shrinking magic is done by resize2fs.

Manually, with ootb tools

It should also be possible to do something like, e.g. (assuming the device you want to backup is not the currently booted disk)

  1. In a non-emulated linux environment attach the physical sdcard and shrink the partition using resize2fs, parted or some GUI tool like gparted, partitionmanager, etc.
  2. Get the End sector of the compacted partition with e.g. sudo fdisk -l divide by the block size (bs, 512 in this example) and then do the copy with dd if=/dev/sda of=disk.img bs=512 count=<End/512>+<SOME-SAFE-EXTRA-SPACE> (untested so not guaranteed to be correct).

NOTE: Unlike the PiShrink option with this scenario you can save time and space by not having to create a full image with dd, especially when sdcard capacity is high, ie a 128/256GB sdcard with only a few GB of actual data.

With SD Card Copier

SD Card Copier comes preinstalled on desktop versions of raspbian and located under the Accessories menu. It will let you make a live copy of the currently booted sdcard to another USB device, so is probably the most efficient way to clone to a physical sdcard. There are also ways to create an emulated USB device backed by a file image as described in https://superuser.com/questions/1062991/linux-usb-mass-storage-emulation although might be tricky to set up on a rpi.

The downside of this method is that you'll need to have a minimal running xorg with dependencies in order to run the utility.

Also see:

ccpizza
  • 431
  • 3
  • 8