2

I have a system that generates embedded Linux systems. The system outputs three files:

  • a tarball containing rootfs excluding the kernel modules
  • a tarball containing the kernel modules
  • uImage

The system is deployed on a 1 GB SD card, of which 10 MB is given to a FAT boot partition and the rest to an ext4 root partition.

The most optimal output format for the system would be an image file that could be written on the SD card using dd. Right now, that image file is created by partitioning and formatting the SD card manually, extracting/copying the files on it and then reading the contents of the card using dd. It works, but the process could be a lot easier.

I know it's possible to create a loop file system representing the card, create the file systems on that and then extract/copy the files on them. I have tried that, and it works to some extent, but not well enough. The problem seems to be related to partitioning and the "geometry" (as in the geometry of a hard-disk, which, as far as I know, shouldn't matter in the case of a memory card) of the SD card, as if the partitioning should be specific to the model of the card, but I am not enough an expert on that area to say more than that.

What would be the proper way to get from the two tarballs and uImage to an image that could be copied on the SD card with dd?

0

If you are sure that the SD card always is of the same size (or greater) as the one you actually have, and the 1G is enough for what you want to copy there, you could proceed as follows:

  1. Manually partition an appropriate SD card, but leave the partitions empty (but create the required filesystems on them)
  2. Copy the whole SD card (say, /dev/sdb) to your system with dd if=/dev/sdb of=empty.image bs=4M
  3. Every time you have to create a new SD card, copy the empty image to a new image: cp empty.image new.image
  4. Now create a loop evice on that file: losetup -f -P new.image (-P is important, as this will force the kernel to read the partition info).

This will create a new loop device (say /dev/loop0) and the partitions /dev/loop0p1.../dev/loop0pn. These now can be mounted and used like any "normal" partition. After finishing your work, call losetup -d /dev/loop0 and copy the created image to your SD using dd if=new.image of=/dev/sdb bs=4M. All those steps may be scipted.

Edit:

Instead of 2) and 3) above:

You might also only copy the partition block (if it's MBR) and keep that (dd if=/dev/sdb of=empty_MBR bs=512 count=1); then for the new SD, ceate empty file (truncate -s 1G empty.file), which is just a sparse file (size=0), copy the partition table (dd if=empty_MBR of=empty.file), create loop device (losetup -f -P empty.file), format the partitions, and proceed like shown above.

Edit2:

If you even don't want to keep the small MBR file, you are also able to use sfdisk scripted (see man sfdisk or https://superuser.com/questions/332252/creating-and-formating-a-partition-using-a-bash-script). This means: Create empty file (s.a.), create loop device (no partitions, without -P), partition that device with sfdisk, detach loop device, reattach loop device (with partitions -P) and proceed.

  • I am trying avoid that approach because it would force me to put the 1 GB image into the version control system and make it very slow to clone. – TheAG Jan 2 '18 at 11:01
  • I am not sure why you would create the (empty) image inside your version control system? These are just (temporary) files you always might recreate at any time. – ridgy Jan 2 '18 at 11:15
  • What you suggested is not entirely scriptable, because it requires manual creation of the empty image. Making it entirely scriptable would require either that the image is stored along with the script or that the script can create the image automatically. The whole point of all this is to make everything scriptable and inside one repository in a version control system. – TheAG Jan 2 '18 at 11:22
  • See my edits for fully scripting.. – ridgy Jan 2 '18 at 11:51
  • One little addition to how truncate is used: In my case, giving it the size 1G didn't work. It resulted in slightly too big a file. I made it work by reading the contents of the card into a file (using dd) and giving truncate the size of that file. – TheAG Jan 19 '18 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.