Add files to rootfs with pre-built system image

Hello.

I have a problem of which I’m not sure if there’s even a solution.

We have a TX2 NX custom image to flash jetsons every time we need. Those custom images are cloned from one jetson that we have for the purpose of installing/configuring the system and cloning it to use for other jetsons.

With that said, we would like to add a serial number, to a .txt file, in rootfs to every jetson we clone. So let’s say (with a custom flash.sh script) we do sudo ./flash -r jetson-xavier-nx-devkit-tx2-nx mmcblk0p1 --serial-number abc123, this would put in rootfs a txt file with the serial number provided.

Would something like this be possible at all? Since we’re not building the system.img (using the system image of the cloned TX2 NX made previously). Is there a solution for a problem like this were we want to add files to rootf while reusing a system.img ?

Thank you,
Francisco

The “flash.sh” script is human readable shell script. You should be able to fairly easily add an option for “--serial-number ...” if you know what file to change in “Linux_for_Tegra/rootfs/”. Just save an unmodified copy of flash.sh, and then edit the original flash.sh until satisfied with the result. The effort would be in the “simple” realm. You’d still be building “system.img”, but it would be built from the rootfs content which contains your file.

Alternatively, you could just create a separate script which has as its only purpose to create the serial number file in “Linux_for_Tegra/rootfs/”, and then call “flash.sh” normally. So long as flash.sh does not get the argument “-r” (to “reuse” rootfs) a new image will be created complete with your serial number file.

If you want to avoid the time of building a new image, then you could simply loopback mount a clone, add the file, umount the loopback, and put a copy in “Linux_for_Tegra/bootloader/system.img” while passing the “-r” option to “reuse” the rootfs (your modified clone).

Hi @linuxdev, thank you for your answer.

Yes, this is not the problem. I’m fairly confident I could add an argument that would generate a file in rootfs with the serial number!

That is my exact problem because I DO want to reuse an image, I.e., I have to use the -r argument, thus not building a new system image with the file I would’ve written to rootfs. My problem lies on the premise that I want to be reusing an image and not building a new one. How would I “insert” a file in rootfs of a system that is already built?

Also, I’m not sure if I understand your third paragraph. Would that help in reusing a system.img while adding a file (with the serial number) to the system?

Does that make sense or am I missing something?

Thank you for your answer.

While I answer this keep in mind that there are two different types of images, and both work when placed at “Linux_for_Tegra/bootloader/system.img”. The raw file (which when generated would show up as “bootloader/system.img.raw”) is an exact bit-for-bit copy of the partition. The sparse file leaves out the “empty” space as a way of making it smaller, and shows up as “bootloader/system.img”. The smaller sparse file takes less time to flash than does the larger raw file, but both work for flash. You could rename “system.img” to some backup location, and then rename “system.img.raw” to “system.img”, and then use the “-r” option, and flash would have exactly the same result (but would take longer).

Raw images can be loopback mounted. The loopback mount makes the image appear like an actual block device (a disk partition in this case). The loopback mount point allows you to go there, examine content, edit content, so on. Then you could umount the loopback point and flash with “-r” using your raw image. Alternatively, you could create a sparse form of your raw image using “mksparse”. Example of converting a raw to sparse:
sudo mksparse -v --fillpattern=0 system.img.raw system.img
(which would convert the raw image to the sparse image exactly the way flash.sh does this)

If you have multiple flashes to perform, and if you don’t have to edit each one, then you are better off converting to sparse; if you have to edit each run, then you are better off accepting the longer flash and just directly using the raw image (you could test once to see the time difference since this depends on how much empty space is present).

As for actual details, let’s say you have your image in “Linux_for_Tegra/bootloader/custom.img.raw” (obviously a raw image…a clone produces both raw and sparse). You could mount and work on this image as follows (mount point is traditional, but you could easily use any other mount point):

sudo mount -o loop custom.img.raw /mnt
ls /mnt
cd /mnt
sudo echo "1234" > my_serial.txt
cat my_serial.txt
cd
sudo umount /mnt

This would alter the raw file and create a file with a serial number. If your file happens to be raw format and at “Linux_for_Tegra/bootloader/system.img”, then flashing with “-r” will flash with this edited image with serial number “1234. Or you could copy the image to that location, or you could mksparse and copy the sparse to that location, and use “-r” with the other version. Such files are quite large though, so you might avoid lots of file copy, but failing to use “-r” once would destroy your original.

Note that it is also possible to place a symbolic link at “Linux_for_Tegra/bootloader/system.img” which points at “custom.img.raw” somewhere else. If something were to edit this sym link over loopback, then the original would be edited, but if something were to overwrite the sym link (such as flashing without “-r”), then the original would be unharmed and you’d just need to add the sym link back in to get the custom version.

1 Like

Hello @linuxdev
That was incredibly helpful.
Thank you for the in depth answer.

Francisco

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.