Building custom rootfs for sd card boot


Hi, I am trying to replace my custom rootfs with the one supplied by linaro. I am using the “” script to prepare the sd card. The following steps I am following to achieve this.

  1. Executed the script “”.
  2. Using dd command write the image “db410c_sd_install_debian.img” to sd card.
  3. Boot the dragonboard with sd card and install the image on board.
  4. I installed some custom application and some packages and libraries on the board.
  5. After installation. mount another sd card (sd card 2) or usb mass storage device. Use dd command to extract the contents of mmcblk0. I am calling this image as rootfs_custom.img. The size of this file is 7.8 G.
  6. When i tried to replace it with the (alip) rootfs.img provided by the linaro i got the following errors.

    sudo sh
  • trap cleanup_exit INT TERM EXIT
  • VENDOR=linaro
  • OS_FLAVOUR=jessie
  • PLATFORM_NAME=qcom-snapdragon-arm64
  • VERSION=20161006-144
  • pwd
  • export PATH=/home/sahil/development/vvats/bootable_sd/skales:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  • du -sk os
  • cut -f1
  • size_os=7676988
  • size_os=7677952
  • size_os=7882752
  • size_img=9750528
  • sudo rm -f out/os.img
  • sudo mkfs.fat -a -F32 -n OS -C out/os.img 7882752
    mkfs.fat 3.0.26 (2014-03-07)
  • mkdir -p mnt
  • sudo mount -o loop out/os.img mnt
  • sudo cp -r os/debian os/flash os/mksdcard mnt/
    +cp: error writing ‘mnt/debian/rootfs.img’: File too large
    +cp: failed to extend ‘mnt/debian/rootfs.img’: File too large
  • cleanup_exit
  • [ 1 = 0 ]
  • cd .
  • sudo git clean -fdxq

I need help to rectify this issue.

Thanks in advance


It looks to me like your rootfs is uncompressed (and therefore too large
to fit on a FAT32 filesystem).

Can you point at where you got this shell script from. The version I’m
looking at contains the code to automatically compress the rootfs and
your trace shows nothing like that is running.



actually, this script is coming from us (from our CI jobs). And the flashing tool expects a .img file, not .img.gz. So i am not sure what you are referring to @danielt.

Ultimately, rootfs.img is being used by the on-target flasher which parses this file: (that’s where the filename rootfs.img is coming from).

So essentially, it is correct that we don’t support files >= 4GB… I used FAT32 there, because i was expecting it to be useful for anyone to mount this on any PC (read: Windows) and drop their files directly. We could use another file system instead of FAT32.

However , i am wondering if you can’t reduce your image size instead. Do you really want to flash an image which is larger than 4GB? Are you sure you minimized the image size as much as you could? Are you sure the image is ‘sparsed’ properly?


I was reading this one:

Of course, now I pay closer attention I notice there are gunzip options…

However , i am wondering if you can’t reduce your image size instead. Do
you really want to flash an image which is larger than 4GB? Are you sure
you minimized the image size as much as you could? Are you sure the
image is ‘sparsed’ properly?

To be explicit filesystem images are better prepared using ext2simg. The
output is more compact than images that are made ready for flashing
using img2simg.


Thanks @ndec @danielt for your responses.
I realized that the image is too large because img2simg didn’t reduces the image size considerably. I have tried to build a custom rootsfs using the linaro supplied rootfs. I am able to build it successfully. Only one query i have that if need to run some scripts during sd card installation process like pre-install or post-install scripts, how to achieve this?

Should I post it as a separate thread?


Not sure if I was 100% clear before about the difference between img2img and ext2simg.

img2simg only performs compression by eliminating long runs of zeros. If the filesystem image was not initialised with zeros prior to authoring (or has been temporarily close to full at any point during authoring) then img2simg will not be able to compress it. ext2simg is much more sophisticated, it parses the file system structures and simply does not encode unallocated space. This will almost always result in smaller images (they burn faster too because the don’t have to write unnecessary zeros to eMMC).


we can keep on this thread. but I would like to have a better description of what you want to do. it’s not clear to me what you are calling ‘scripts during sd card installation’. can you please clarify this a bit?



I want to install some utilities, libraries and packages and custom application during sd card installation. there must be some post install scripts through which i can perform these tasks.

May be if i have the source code for the sd card installer could help me.


@danielt i will see if i could do with ext2simg and will share the results.


the graphical installer is a Qt5 application, the code is available here:

The Qt5 application ends up calling a flashing script as :slight_smile:

burn.start(_root + “/flash -o /dev/mmcblk0”);

and the source code for this ‘flash’ script is located in the OS installation folder in the SD card, e.g.

and the ‘flash’ script will use the following application to do the actual flash writing:

So basically, you add anything to the ‘flash’ script in the SD card OS folder. You can add commands to be done before, or after the flashing.

How to build a "AUTO INSTALL" installation SD card

great… @ndec Thanks so much for sharing the code and scripts description.



So can I consider that if I update the flash script…
OUTPUT=$(basename $2) SCRIPTPATH=$(dirname $(readlink -f "$0") ) sudo $SCRIPTPATH/mksdcard -p partitions.txt -i $PWD -o /dev/$OUTPUT -s $((cat /sys/block/$OUTPUT/size`/2))

sudo dpkg -i /var/cache/apt/archives/xxx.deb’

will install the deb files to my dragonboard.



not exactly like that, but close. When you boot into the GUI installer, you are booting off SD card. So if you run this dpkg command it will install the packages on the current rootfs which is on the SD card, not on the eMMC.

however you can do something like this instead:

mount /dev/mmcblk0p9 /mnt # assuming p9 is the rootfs on eMMC (i don't remember OTOH)
cp  /var/cache/apt/archives/xxx.deb /mnt
chroot /mnt dpkg -i /xxx.deb
rm /mnt/xxx.deb
umount /mnt

with this command, you would in turn install the packages using a chroot into the eMMC rootfs.