Tutorial: How to create DD images with appropriate size - Printable Version

+- PINE64 (
+-- Forum: PINE A64(+) (
+--- Forum: Android on Pine A64(+) (
+--- Thread: Tutorial: How to create DD images with appropriate size (/showthread.php?tid=2237)

Tutorial: How to create DD images with appropriate size - tkaiser - 09-18-2016

This mini tutorial is meant for those people providing Android or RemixOS 'DD images'. The DD images currently provided have been created wrong (too large for many SD cards out there). Fortunately it's easy to do it better. Since we're talking here about SBC why not stop wasting time on both creator's and user's side, using an SBC in USB gadget mode, create images with appropriate size and speed up things?

The whole process would work with any Pine64/Pine64+ too but since AFAIK no OS image is around that uses a correctly configured kernel enabling the necessary g_mass_storage module and since a small patch might be necessary to get this working with BSP kernel (can't test right now since ran out of Pine64) we discuss this with H3 devices instead (H3 is A64's little sibling). Ingredients:
  • Any H3 device from this list:
  • A short USB-to-Micro-USB cable (or type A to type A when choosing the Beelink X2 or Pine64 later)
  • An Armbian image for the device in question using legacy kernel since we need USB OTG support
  • A 120 GB disk to store the images with 7.8, 15.8, 31.8 and 63.8 GB size (or a 250 disk when both Android and RemixOS images should be stored on the same disk)
I would choose the cheapest device possible: Orange Pi One powered through the barrel plug and establishing the USB OTG connection through the Micro USB port.

1) Prepare the disk

Connect the USB device to OPi One, the H3 board to your Windows machine, then do on the Linux box:
modprobe g_mass_storage file=/dev/sda
echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role

This will hand the whole device as an USB disk to your Windows PC. Since I don't own such thing (only virtualized Windows servers) in the following I will show how it looks like when the SBC is connected to a Mac. You can now use disk utility (no idea how that's called in Windows) to partition the disk that is physically connected to the SBC in reality. I created the necessary partitions in OS X that are all small enough to fit on any SD card later. Now in OS X it looks like this:
macbookpro-tk:~ tk$ diskutil list
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:      GUID_partition_scheme                        *128.0 GB   disk2
  1:                        EFI EFI                     209.7 MB   disk2s1
  2:                  Apple_HFS Ohne Titel 1            7.8 GB     disk2s2
  3:                  Apple_HFS Ohne Titel 2            15.8 GB    disk2s3
  4:                  Apple_HFS Ohne Titel 3            31.8 GB    disk2s4
  5:                  Apple_HFS Ohne Titel 4            63.8 GB    disk2s5
  6:                  Apple_HFS Ohne Titel 5            8.9 GB     disk2s6

And on the SBC itself in Linux it looks like this:
root@orangepiplus2e:~# cat /proc/partitions
major minor  #blocks  name

179        0   15267840 mmcblk0
179        1   15114128 mmcblk0p1
179       32       4096 mmcblk0boot1
179       16       4096 mmcblk0boot0
  8        0  125034840 sda
  8        1     204800 sda1
  8        2    7617188 sda2
  8        3   15253392 sda3
  8        4   30957032 sda4
  8        5   61658076 sda5
  8        6    8688952 sda6

So we created 4 partitions that we will then feed to PhoenixCard in the next steps. Time to eject/unmount the partitions from Windows (or OS X in my case) and then remove the device back in Linux (we switch first to USB host mode which is the equivalent of disconnecting a real USB disk physically and will then unload the driver since we will use it in the next step not with /dev/sda but the individual partitions instead):
echo 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
rmmod g_mass_storage

2) Provide the partitions as devices starting with 7.8 GB in size

In Linux /dev/sda2 is 7.8 GB in size so now we hand only this partition out to Windows (or in my case OS X):
modprobe g_mass_storage file=/dev/sda2
echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role

And instantly on the connected PC a new USB device appears that's just 7.8 GB in size:
macbookpro-tk:~ tk$ diskutil list
  #:                       TYPE NAME                    SIZE       IDENTIFIER
  0:                            Ohne Titel 1           *7.8 GB     disk2

3) Let PhoenixCard do the work

Now start PhoenixCard and point it to this virtualized 'USB thumb drive'. PhoenixCard will create a bunch of new Android/Linux partitions on /dev/disk2 (/dev/sda2 on Linux) and use the maximum disk space available (7.8 GB in our case). That's the whole trick: Creating a partition small enough to fit on any SD card later, let PhoenixCard use this partition as device and create its own partitions on this. Smile

4) Create the DD image on Linux

Eject/unmount the virtual USB thumb drive in Windows, mount the next one to create the 16GB version and while PhoenixCard does its job in Windows create a new device image on the SBC that will be way smaller than the images Pine64 folks provide now. The most important thing here is that we create a device image by using a partition. Now /dev/sda2 on Linux contains a bunch of partitions and therefore we use
dd if=/dev/sda2 bs=10M | 7zr a -bd -t7z -m0=lzma -mx=3 -mfb=64 -md=32m -ms=on -si Android-8GB.img.7z

For the 16GB variant it would look like this (and so on):
dd if=/dev/sda3 bs=10M | 7zr a -bd -t7z -m0=lzma -mx=3 -mfb=64 -md=32m -ms=on -si Android-16GB.img.7z

(I think Armbian doesn't ship with 7-zip so an 'sudo apt-get install p7zip' would be required before). This way you get pretty small DD images while PhoenixCard is already preparing the next image on the Windows host.

5) Tell your users to use appropriate tools and what's important.

When you put the compressed images online then provide GOOD documentation how to burn images correctly. Don't recommend tools that suck, it's 2016 and burning tools that verify the burning process do exist, for Android and RemixOS images it's VERY IMPORTANT that users choose SD cards that show high random IO performance. Everything is outlined here:

RE: Tutorial: How to create DD images with appropriate size - dkryder - 09-27-2016

you have done a great job of leading to a large pond of pure tasty water. now just, will they drink? i hope so since it is rather easy to cause physical damage to a sd card when using a file resize tool. i forgot to think about buying some cheap sd card just as cards for use while learning can be rendered useless if things are not done right. so, heck, it's my own fault for using evo to learn on. but i killed 2 of those before i bought some cheap ones. my own fault. still, to not even have to deal with it would be great. so, thank you, and here is hoping the suggestion you make is followed.

RE: Tutorial: How to create DD images with appropriate size - MarkHaysHarris777 - 09-27-2016

We might create a sub-forum for development general; these tips apply not only to Android. This post might be pinned there should it prove to be verified and reproducible.


RE: Tutorial: How to create DD images with appropriate size - KarenHeinz - 12-15-2016

I have a DD image from a 4GB SD card that has two partitions, these two partitions are only using up about 800 MB and as such I wish to reduce the size of the img fie.
Does anyone know of a way to remove the "free space" from the img file?

RE: Tutorial: How to create DD images with appropriate size - Toriless - 12-19-2016

I just use Windows and Win32DiskImager. It works for Android 7.0 unlike PhoenixCard. The Pine release are dead. They never get updated.

RE: Tutorial: How to create DD images with appropriate size - Bluphire - 12-20-2016

GParted worked nicely for me on OSX