Find your Micro SD card identifier
diskutil info -allYou're looking for something like this:
**********
Device Identifier: disk2
Device Node: /dev/disk2
Whole: Yes
Part of Whole: disk2
Device / Media Name: SD Card Reader
Volume Name: Not applicable (no file system)
Mounted: Not applicable (no file system)
File System: None
Content (IOContent): FDisk_partition_scheme
OS Can Be Installed: No
Media Type: Generic
Protocol: USB
SMART Status: Not Supported
Disk Size: 7.9 GB (7948206080 Bytes) (exactly 15523840 512-Byte-Units)
Device Block Size: 512 Bytes
Media OS Use Only: No
Media Read-Only: No
Volume Read-Only: Not applicable (no file system)
Device Location: Internal
Removable Media: Removable
Media Removal: Software-Activated
Solid State: Info not available
Virtual: No
Note:
- device identifier is the highest level parent, i.e.
disk2and notdisk2s1etc. - device media name is "SD Card Reader"
- it clearly states the media is removable
Unmounted, but not ejected
diskutil unmountDisk /dev/disk2Should see:
Unmount of all volumes on disk2 was successful
Create the image (full image) and compress it
sudo dd if=/dev/rdisk2 of=/tmp/rpi.img bs=4m status=progressShould see:
7914651648 bytes (7915 MB, 7548 MiB) transferred 209.056s, 38 MB/s
1895+0 records in
1895+0 records out
7948206080 bytes transferred in 209.971211 secs (37853790 bytes/sec)
Since dd is copying the raw block device, it reads every sector, including:
- Empty space
- Unused filesystem blocks
- Partition table
- Bootloader
As a result, we got a bit-for-bit clone and the image file is the size of the SD card itself (in my case it's 8 GB).
This is far from perfect because larger image takes longer to create, takes longer to burn onto a new SD card and takes more space for storage.
The options are:
- Compress the image - my 7,95 GB image became a 770 MB gzip file; this helps storage but burning still takes long as it goes through the original 8 GB volume. Here's how you can compress:
gzip /tmp/rpi.img- faster, but may be problematic with Balena Etcherzip -j -9 /tmp/rpi.img.zip /tmp/rpi.img- slower to compress but Etcher reads the image immediately;-jstrips the folder structure and packages just the given file
- Put the OS you want to clone on an SD card of the smallest, tightest possible size, before cloning it - see below
Find how much space your OS actually uses
Insert your Micro SD back to Raspberry Pi, boot it and run:
pi@raspberrypi:~ $ sudo df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p2 6.8G 2.6G 3.9G 40% /(In case alignment got messed up - it says only 2,6 GB had been used)
And to confirm:
pi@raspberrypi:~ $ sudo du -h --max-depth=1 / | grep "/$"
du: cannot access '/proc/854/task/854/fd/3': No such file or directory
du: cannot access '/proc/854/task/854/fdinfo/3': No such file or directory
du: cannot access '/proc/854/fd/4': No such file or directory
du: cannot access '/proc/854/fdinfo/4': No such file or directory
2.7G /This means we can easily burn the same OS onto a 4 GB Micro SD card and then we have much smaller volume to copy and burn.
Metadata error when burning your image
You may be getting a metadata error:
Error: (0 , h.requestMetadata) is not a function
You may be led to thinking the problem is with the image you're burning, but believe it or not, it could be that Etcher can't load their ads or tracking spyware and that's why you're seeing the error. Common when you're using DNS-based ad blocking.
I can't confirm this officially, but I got the idea based on reading these two posts on the Etcher forum: