Guide to the .sdcard format

Document created by gusarambula Employee on Jun 10, 2015
Version 1Show Document
  • View in full screen mode

Understanding and using the .sdcard format


One very useful feature enabled by default in both the Yocto Communiy BSP and Release BSP is the option of generating the baked images in .sdcard format.

If the .sdcard format is not selected by default it can be enabled on the conf/local.conf file by adding it with the IMAGE_FSTYPES as follow:


It’s important to note that if this variable is specified only the file systems typed defined will be created. The default value used most often for this variable is:

IMAGE_FSTYPES="tar.bz2 ext3 sdcard"

The .sdcard format creates an image with all necessary partitions and loads the bootloader, kernel and rootfs to this image. You can just low level copy the data on this file to the SD card device using dd as on the following command example:

$ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && sync


Partitions used on the .sdcard file


The .sdcard partitions looks as follow:


Unpartitioned space reserved for the bootloader

Kernerl and other data

The rootfs.


Granting more free space on the RootFS partition


The size of the .sdcard file will depend solely on the size of the rootfs. This means that the resulting file won’t partition all our SD Card capacity unless we add extra space to the rootfs partition. (Of course there is always the option of editing the partitions once loaded on the SD Card)


In order to add more space you may use the IMAGE_ROOTFS_EXTRA_SPACE variable. You may add it to your local.conf file with the added free disk space in Kbytes. For example, if you would like to guarantee 1GB of extra space you may add the following line to your local.conf file.




It is important to note that this is space additional to the IMAGE_OVERHEAD_FACTOR variable which defines a multiplier that is applied to the initial image size. This is only applied when the multiplier times the

By default, the build process uses a multiplier of 1.3 for this variable. This default value results in 30% free disk space added to the image when this method is used to determine the final generated image size. This would mean that there should be 30% of free disk space before post install scripts. If you wish for more space you may edit this variable as bellow:




Which would result in 50% free disk space added to the image, before post install scripts and without considering overhead that may come from the package management system.

How the IMAGE_ROOTFS_SIZE is calculated


This variable is also measured in Kbytes and it’s determined by the OpenEmbedded build system using an algorithm that considers the initial disk space used for the generated image, the requested size for the image (trough the overhead factor) and the additional free space to be added to the image (trough the extra space variable).


The build system first runs a du (disk usage) command to determine the size of the rootfs directory tree. If the IMAGE_ROOTFS_SIZE current value is larger than the disk usage times the overhead factor only the extra space is added. If the IMAGE_ROOTFS_SIZE is smaller than the disk usage times the overhead factor then the disk usage is multiplied times the overhead factor prior to adding the extra space.


IMAGE_ROOTFS_SIZE must be set on a default value which is usually very low as it’s just initialized and updated with the actual size requirements each time an image is baked.


You may also use this variable directly in order to select the space you would like to allocate to the RootFS.For example setting the RootFS to 2GB would require the following addition to the local.conf file:




In this example we would leave the overhead factor to 1 so no extra space is added since we’re specifying the rootfs size that we want.

13 people found this helpful