I am building a custom yocto image for a Verdin iMX8MP SoM.
My image is based on the tdx-reference-minimal-image.
As I cannot use Torizon OS at present I have been looking at alternative update implementations.
Ideally I am looking to implement one that uses an A/B Update process, but I am unsure if the current recipes have a way for me to “duplicate” the deployment of the rootfs to 2 partitions on the eMMC.
I will also be using the tdx-data-partition and tdx-signed classes from the meta-toradex-security layer in my image.
What I need initially is to have the second copy of the rootfs as a partition on the eMMC along with the existing partitions that are created.
I am also interested in how to add an overlayfs for the /etc directory as when I switch to the tdxref-signed class the rootfs will be read-only.
Is there anything already to make this possible with minimal changes in my custom layer? And are there any caveats/gotchas I should know about before I embark on a possibly impossible mission?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
To set up a dual root filesystem (rootfs) for A/B updates on your Verdin iMX8MP SoM using Yocto, you can follow these steps:
Partitioning the eMMC: Modify your Yocto build configuration to define two rootfs partitions. This involves editing the wks file used by the wic tool to create the image, ensuring both partitions are included.
Duplicating the Rootfs: Create a custom Yocto image recipe that deploys the rootfs to both partitions. You might need a post-processing script to copy the rootfs to the second partition after the initial deployment.
Bootloader Configuration: Configure your bootloader (e.g., U-Boot) to support booting from either rootfs partition. This typically involves setting environment variables or scripts to switch between partitions based on update status or failure detection.
For implementing an overlay filesystem (overlayfs) for the /etc directory:
Overlayfs Setup: Configure overlayfs to mount a writable layer over the read-only /etc directory. This can be done by creating a writable partition or using a tmpfs for the overlay’s upper layer.
Integration with Yocto: Modify your image recipe to include the necessary overlayfs setup scripts and ensure they execute at boot time to mount the overlay.
Considerations: Be mindful that overlayfs can add complexity in managing persistent changes across reboots and updates. Ensure your update mechanism accounts for changes in the overlay.
Regarding the tdx-data-partition and tdx-signed classes, ensure your partitioning and signing processes are compatible with these classes. You may need to adjust your build configuration to accommodate the security features they provide.
While setting up a dual rootfs and overlayfs can be complex, it is achievable with careful planning and configuration in your Yocto build environment. Thorough testing will help ensure reliability and robustness in your update process.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
I have had a quick delve into the image_type_tezi.bbclass in meta-toradex-bsp-common, and it would seem this is not currently possible.
As this is something I will need I have created a patch for the kirkstone branch that would appear to add the ability I require.
Is there a way I can submit this as a PR/MR for consideration into the BSP?
With this patch and adding TEZI_DUAL_ROOT_ENABLED = "1" to local.conf, this appears to create the required manifest.json to create a second rootfs partition with the same content as the existing rootfs partition.
NOTE: this partition in my case will be added to “/dev/mmcblk2p3” and will make my data tezi partition “/dev/mmcblk2p4” - Noted here as this will mean a change to the configuration of the tdx-encrypted variables to point to the correct partition if/when dual boot is configured.
I have also got a patch that makes the new data partition easier to extract and deploy.
This should extract the specified data mount point from the rootfs and create a data.tar.xz image file that can then be referenced in the image manifest.
Any recipes putting data into the data folder using the normal FILES approach will automatically get pulled out into the new data image archive.
Extra possible benefit that this can also be used in OTA updates (if not using the TorizonOS implementations).