How to create a custom rootfs to embed additional files on linaro-stretch-alip?

Products Support DragonBoard410c
#1

Good evening everyone,

I would like to add additional files (such as kernel modules, additional softwares or libraries) to the existing rootfs image. Actually, I would like to create a custom image to flash immediately instead of flashing the SoM and downloading/compiling everything for each new SoM. Thus, I could minimize the flashing time significantly.

From what I understand, everything happens during the rootfs image build phase, but I can’t find any rootfs source code to customize.

I am using the release 17.09 version (kernel 4.9.56-linaro-lt-qcom). I’ve read a similar topic here but I am not sure it is still correct (also it is for OpenEmbedded, not Debian).

Do you have an idea on how to do this ?

Kind regards,
Mathieu

#2

Currently we have a two stage process:

  1. obs.linaro.org builds any special packages that we require for this board
  2. These are assembled from a jenkins job using FAI. Starting point for this is the job description ( https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-debian-images-dragonboard410c.yaml ) which works by having the job run scripts found in the same repo.

For a bit more detail (but fewer links) take a look at this thread:

#3

Hello @danielt,

Thank you for your answer. The infos you have linked seem to be very interesting.

Actually I am using an SD410 from Variscite as I stated in another topic, the rootfs file I have access to seems to be the default one from releases.linaro.org. The job yaml file you have linked seems to be exclusive to DragonBoard 410c. I am wondering how the rootfs from linaro has been built, is it from another job file ?

#4

It used to be but since the switch to FAI we no longer require an intermediate rootfs. It is generated directly by FAI. In the YAML file this is line 108, which calls builders-fai.sh « lt-qcom-debian-images - job/configs.git - to do the work.

1 Like
#5

Thank you very much for your explanations @danielt.

I also asked Variscite support for help, and it ended up with the img2simg/simg2img trick which I can track back from the builders-fai.sh.

For now, I am doing the process manually which is :

  • Converting the linaro rootfs img into a raw image (simg2img)
  • Mounting the raw image and making my own changes (mount)
  • Unmounting the raw image (umount)
  • Converting the raw image back to a rootfs image (img2simg)
  • Flashing the board (fastboot)

However, I’ve heard about other tools called make_ext4fs here as well as mkfs.ext4 here. Are those tools still in use ?

Regards,
Mathieu

#6

hey!

using img2simg/simg2img is fine. It’s not a ‘trick’. If you want to do simple things like drop new files or do a bit of linux config, it is definitely the simple thing to do. But if you start doing packages manipulations such as package upgrade, package modifications, … then it will start to become really error prone. In that case rebuilding a full image with FAI will be more appropriate.

make_ext4fs is a tool that we used before, it takes a “folder” and create an image with an EXT4 file system with the folder content. However we found issues with this tool when using e2fsprogs tools (to resize the file system), that’s why we switched to make.ext4fs which is the tools from e2fsprogs to create EXT4 file system. The good thing with make_ext4fs is that it knew about the ext4 file system structure and used this information to generate ‘better’ sparse images, so in theory sparse images with make_ext4fs were more optimized than with img2simg which uses a very naive implementation. img2simg does not know about the file system structure and creates a ‘dumb’ sparse file.

Right now we use FAI to generate the rootfs, which will use make.ext4 to generate an EXT4 image (see RAW « disk_config - fai.git - [no description]), and then we use img2simg to sparse it.

1 Like
#7

If you are working with ext4 images it is best to use ext2simg to generate the sparse images (note that fastboot sparse images are completely unrelated to sparse files :wink: ). The difference is that ext2simg is aware of unallocated space in the filesystem and doesn’t bother encoding it, this makes flashing faster.

1 Like
#8

Thank you both of you for your details.

Right now I am modifying the rootfs image by myself, manually. It works for now but it is kind of “dirty” when it comes to install packages such as v4l-utils or a custom gstreamer-1.0 debian package (I extract the data.tar.xz from the debian package and copy/paste in correct folders).

I suppose that kind of work would be done from a script that would overload or come in the end of the FAI build chain. Is there any documentation about how we could custom the FAI build chain ?

Regards,
Mathieu

#9

As you say, you may eventually have scaling (or version skew) problems trying to customize a pre-authored rootfs.

However if the problem is merely installing debian package then you can avoid the need to manually unpack debian packages by using qemu user-mode emulation. This works by making your x86_64 kernel recognise AArch64 ELF files and run them using qemu-aarch64-static. Instructions are here if you are a Debian user (you just miss out step four since you already have a rootfs):
https://wiki.debian.org/Arm64Qemu

The same principle applies to non-debian distros but it can be a bit trickier. It generally involves taking the static qemu binary from the debian package and hunting down the magic incantation to teach the kernel how to run alien binaries (in Debian these form part of the binfmt-support package).

Lots: FAI Guide (Fully Automatic Installation)

However given FAI has grown extremely flexible you might prefer to use it as a reference rather than a tutorial (e.g. use the guide to learn about things in our CI scripts that are not clear).

1 Like