Hello everyone,
I have an Apalix IMX8 QuadMax 4GB mounted on an Ixora V1.2 running TorizonCore with pre-evaluation containers.
I made a list of steps with one board to change the overlays to enable HDMI and disable LVDS ( which works fine)
the issue here is that my coworked used the hash code from the list of steps by mistake instead of the one generated by his board
you can see here that he initially changed the overlays in the following folder :
apalis-imx8-07107575:~$ ls /sysroot/boot/ostree/torizon-7c4c05bc34d4f4af22b2cea64f9e588f747e3ad5f8b28b1ca053d9f5f277430d/dtb/overlays
in the screenshot he then followed the right steps and changed the hash code to the proper one d3fc26b*****************
The question here is how is it possible to have the same folders with different hash codes, it seems like something that could lead to unintended errors
I am not entirely sure if he used the same ixora board I used while doing my list of steps or another one, probably the same one but after updating the firmware from the PREEMPT_RT version to the normal one
sorry if the explanation is confusing, please let me know if this hash codes are unique for each device or not
Thank you
Hi @AhmedMobarez,
Thanks for reaching out. TorizonCore images use libostree to handle file system updates ( OSTree | Toradex Developer Center). Every time you upload a new image to your board either through the platform or via the deploy command on TorizonCore Builder, the following may usually happen:
- If there was only one update sent, the OSTree would create a second
torizon-checksum folder. This way, if there was a problem with the custom image, the library would do a rollback and return to the previous File System.
- If there were two of these folders already, it would delete the older one and then create a new one following the same idea as above.
It is possible to change the default Ostree behaviour and retain more than 2 deployments as explained in the article.
This is why you have two “identical folders” with different hashes. As you updated from the PREEMPT_RT to the normal one, it explains this behaviour. Every deployment will have its checksum.
If you run
ostree admin status
you’ll have all the available deployments and the one tagged with an * will be the active one.
You can get the correct checksum also by running this command:
awk -F "ostree=" '{print $2}' /proc/cmdline | awk '{print $1}' | awk -F "/" '{print $5}'
Does this explain the topic to you?
Have you also tried to update device trees/overlays by creating a custom TorizonCore Builder image?
Best regards,
Hey @gclaudino.tx ,
Thank you for your quick reply, this explains the issue clearly.
I have two follow-up questions, if the default behavior is to delete the older folder, why did it retain it in my case ? and how to delete it ?
I deployed the update online using the torizon web app.
Second question, Is there any advantage in updating the tree/overlay using the TorizonCore Builder as opposed to what I did ?
I did it this way because it was more straightforward to do it like this when I checked the documentation on the developer website
Hi @AhmedMobarez,
Thanks for reporting.
It will delete the older folder only if you have already 2 deployments and wants to do a new one. We do not recommend manipulating these files directly as they’re managed by Ostree. So please, do not delete it.
Yes, if you create a custom TorizonCore image using the Builder, you’ll be able to have your overlays by default to any device that you want to flash them to. You can also upload your images to the platform and do the remote deployment as you’ve done before. TorizonCore Builder has also other tools that would allow you, for instance, to put some default files on your image. Torizoncore builder overview | Toradex Developer Center
This will make your deployments more maintainable and reproducible as you update your module.
Best regards,
