I’m using a imx8m with torizonOS, but I just started with a reference image with some docker containers just to have a base image to work with.
I just setup the image, I have all the OS configs set up as well as the docker containers running the apps.
Now, my main doubt is how can I create an image for production?
I did not use the torizon-builder for any of this process, and at least for now I would continue like this for the MVP, and later in the process, with some time to learn new tools, start migrating to using torizon-builder.
For now, not sure if this solution if the best one, but I was thinking of using dd to clone the eMMC drive to an external USB flash drive, and with this, I can get an image of the contents of the eMMC, the problem is the EasyInstaller can only work with specific images and cannot load these type of images.
How can I flash to the internal eMMC a saved image so I can replicate it for production?
Maybe using this GitHub - nxp-imx/mfgtools: Freescale/NXP I.MX Chip image deploy tools.?
I’m using a imx8m with torizonOS, but I just started with a reference image with some docker containers just to have a base image to work with.
Just to clarify which OS image are you using here? We have OS images called “reference images” but these are completely different from Torizon OS and do not feature Docker.
Now, my main doubt is how can I create an image for production?
I did not use the torizon-builder for any of this process, and at least for now I would continue like this for the MVP, and later in the process, with some time to learn new tools, start migrating to using torizon-builder.
For now, not sure if this solution if the best one, but I was thinking of using dd to clone the eMMC drive to an external USB flash drive, and with this, I can get an image of the contents of the eMMC, the problem is the EasyInstaller can only work with specific images and cannot load these type of images.
How can I flash to the internal eMMC a saved image so I can replicate it for production?
While not impossible, we do not recommend this path. We only recommend using Toradex Easy Installer to flash images on our hardware. Is there a reason you’re trying to clone the eMMC and flash things in this way?
The version used is torizon Core Linux verdin-imx8mm-14756371 5.15.129-6.5.0+git.6f8fd49366db #1-TorizonCore SMP PREEMPT Fri Dec 22 11:15:52 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
Regarding the use of TorizonCore Builder we need a lot of changes at the OS level, multiple services and scripts to do specific tasks and access specific hardware, that is why we opt not to use it.
Until now, I don’t see the need to use it, we just setup our OS and when it is good to go we should be able to replicate it.
Even without recommendation, can at least point to somewhere where we can flash standard images on the eMMC without using easyinstaller?
Regarding the use of TorizonCore Builder we need a lot of changes at the OS level, multiple services and scripts to do specific tasks and access specific hardware, that is why we opt not to use it.
Or is there a specific change that you have already determined TorizonCore Builder unable to do?
Until now, I don’t see the need to use it, we just setup our OS and when it is good to go we should be able to replicate it.
If this works for you then that is fine. I would still suggest you consider using TorizonCore Builder, it’s our recommended workflow and we would be able to provide you better support with this. Also if you plan to use any of our other tooling like our VSCode extensions, or our Torizon Cloud services, then the workflow would be smoother.
Even without recommendation, can at least point to somewhere where we can flash standard images on the eMMC without using easyinstaller?
We dont have many changes to be truth, but basically we have some services running, that run some scripts that we want that to run outside docker containers using systemd.
We also have docker containers with some specific apps.
So basically it is just the services and scripts outside the docker container, that I’m not sure how to include them with Torizon-Builder.
We dont have many changes to be truth, but basically we have some services running, that run some scripts that we want that to run outside docker containers using systemd.
This feature of TorizonCore Builder can capture any changes in the /etc directory of the OS. It does this by using a base image as a starting point then seeing what is different on your device. It then captures these changes. Systemd services are already in /etc, then you should be able to move your scripts here as well.
We also have docker containers with some specific apps.
Custom images produced by TorizonCore Builder should be compatible with Toradex Easy Installer for easy deployment.
If you still have any questions or concerns about TorizonCore Builder I’d be happy to clarify. Or we can even schedule a demonstration of the tool for you if you would prefer that.
Hello @jeremias.tx ,
I try to use first the changes but from what I can test, it can only reproduce the changes on etc/ which has some changes on services, apps, etc, so far so good.
But most of those services call scripts located in /home/user that the changes cannot capture.
Probably I’m not using changes correctly, is there any way I can capture specific folders or copy them to the changes so it can be applied to the new image?
But most of those services call scripts located in /home/user that the changes cannot capture.
Probably I’m not using changes correctly, is there any way I can capture specific folders or copy them to the changes so it can be applied to the new image?
In short, no. Torizon OS uses OSTree to manage changes to the OS. By design OSTree does not manage anything under /var. This is by design as to have a location that is not affected by updates/changes. The /home directory is symlinked under /var therefore it has this property of not being managed. This means TorizonCore Builder can’t capture/manage any new files or directories in this location on the device.
That said, can’t you just simply copy these scripts to somewhere in /etc instead? Is there a reason they need to be in /home?
No reason to be in /home, just to maintain backwards compatibility with previous systems.
Being said that, can be included in future version of the builder, custom paths to apply the changes instead on only the /etc? This limits a lot the usage of the capture changes feature.
UPDATE: I tried do create a new folder in /etc with the scripts, but then when running builder I get the following error: Unable to bundle up changes at target
If I delete the folder everything is ok
Being said that, can be included in future version of the builder, custom paths to apply the changes instead on only the /etc? This limits a lot the usage of the capture changes feature.
That said, as I said before /home is not an option. The underlying technology we use for managing changes and such is OSTree. OSTree does not track changes in /var (/home is symlinked under /var). This is by purposeful design as to have a persistent designated location that would not be affected by updates or changes.
If you really must have these files in /home could you not just have them in /etc then have a script that runs on system start-up that copies these files from /etc to their expected location in /home?
UPDATE: I tried do create a new folder in /etc with the scripts, but then when running builder I get the following error: Unable to bundle up changes at target
If I delete the folder everything is ok
Could you please elaborate on this point? How did your scripts create this new folder?
When I manually create a new folder in /etc I’m able to capture it without issues. Looking at the builder tool this error message, Unable to bundle up changes at target. Occurs when the changes on the device can not be packaged via tar. Perhaps your script creates these new folders in a strange way?
Even with this I can’t seem to reproduce this error you’re seeing. In summary I did the following:
Create some dummy files and directories in /home/torizon
Copy these files to /etc using the same commands as in your script you shared.
Run torizoncore-builder isolate
This all succeeded for me and I did not see the error you got earlier. Perhaps it has something to do with how you created your original files in /home/torizon? Could you try a sanity test and just creating a random test file/directory in /etc and try to isolate that. See if that works for you. If it works then there must be something different about your files that you’re trying to isolate.
So, I’ve done some testing and it seems the isolate changes only work if the scripts are in tar format.
If I create folders manually and copy the files and scripts to that folder in /etc/### when using isolate changes in verbose mode I get an error of permissions, which can be possible, because of the scripts.
My question is, is it possible to torizonbuilder have some pre and post-processing scripts?
In this case, before isolate the changes I’ve manually tar the scripts in /home/torizon and copy them to /etc/###.
The final image has this scripts in /etc/###, but then, when the image boots the first time I need them to be copied to /home/torizon.
I can use some startup script as OS level, but is it possible torizonbuilder do this for me in the build process?
I still don’t fully understand how these scripts of yours are getting created in /etc. Could you provide an exact example please?
So you create some script files in /etc and then isolate fails? I don’t understand. If I create some files/directories in /etc then isolate works fine for me.
In this case, before isolate the changes I’ve manually tar the scripts in /home/torizon and copy them to /etc/###.
Wait so your changes in /etc aren’t just normal files and directories you have a tar archive in /etc correct? Is there a reason you need to have a tar archive? Can’t you just copy the raw files and directories from /etc to /home/torizon without having them be in a tar archive? Though I just tried isolating a tar file and that works fine for me as well. I really need to see what you’re exactly doing as it does not make sense to me right now why you’re seeing errors.
I can use some startup script as OS level, but is it possible torizonbuilder do this for me in the build process?
You can create a startup script on Torizon with a systemd service that call this startup script then capture these as changes with the isolate command. Systemd service are naturally under /etc anyways.
Our system uses files in /home/torizon, a lot of scripts and python files.
Before I do the isolate, I copy all the contents from /home/torizon to /etc/new_folder.
If I do this the isolate fail. I think the problem can be permissions when I do the copy. cp -r /home/torizon/* /etc/new_folder
To work, I have to tar before I copy the scripts from /home/torizon to /etc/new_folder.
If I tar the contents of /home/torizon and copy then to /etc/new_folder/xpto.tar, I can isolate OK. cp /home/torizon/xpto.tar /etc/new_folder/xpto.tar
Okay I think I understand now. So isolate works fine for you, but only if you tar everything up first. I do find this a bit strange. If i just run sudo cp -r /home/torizon/* /etc/new_folder then isolate works fine like this. I’m not quite sure why your files need to be put into a tar archive first to work.
I guess there might be something different/special about the files you’re trying to isolate. Though I would need to see your exact files/directories to have any better idea.
