I build my first secure boot image for the Verdin AM62 module using the Yocto build container CROPS (with the variables for secure boot enabling) and that resulted in a correct build. I then was able to flash this build to the module using easy installer and a custom build USB flash drive.
I setup the secure boot using the “torizon-signed” bbclas so ECoT is enabled in the build.
my local.conf file specific settings for these are the following:
Also i noticed that at every module reset i have to reset the password, this i not being saved, now i read on the secure boot manual page that the /etc/ directory is volatile when using the “torizon-signed” bbclass and i was wondering if the errors i am seeing and the not saving of the new user password was related to this?
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Richard,
Thank you for reaching out with your question. It sounds like you’ve made significant progress in building and deploying a secure boot image for your Verdin AM62 module. However, I understand you’re encountering some runtime errors and issues with password persistence.
The use of the “torizon-signed” bbclass indeed results in a volatile /etc directory, which means changes like password updates won’t persist after a reboot. To address this, you can utilize the systemd-tmpfiles service to create persistent configurations. This service allows you to define files and directories that should be created or modified at boot time, ensuring your configurations are retained across reboots.
Regarding the runtime errors, here are a few steps you can take to troubleshoot:
Examine Boot Logs: Carefully review the boot logs for any specific error messages that might indicate the source of the problem. This can provide clues about what might be going wrong.
Verify Secure Boot Configuration: Double-check all configurations related to secure boot, including key management and signing processes, to ensure they are correctly set up.
Test Without Secure Boot: If feasible, try booting the module without secure boot enabled to determine if the errors are related to the secure boot setup.
By following these steps, you should be able to identify and resolve the issues you’re experiencing. If you have further questions or need additional assistance, feel free to reach out.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
I performed a complete Yocto rebuild and know all errors available at bootup related to failed services are completely gone.
No idea wat was the issue but a complete rebuild fixed the issue.
Resetting of the passwd is still there but i think that is to be expected when working with the volatile /etc/ directory, if someone could verify this is expected behavior with secure boot setup i would appreciate it.
Glad to see you got this issue resolved with a rebuild. I assume some configuration or artifact from a previous build was somehow polluting your secure boot build and caused these issues.
Resetting of the passwd is still there but i think that is to be expected when working with the volatile /etc/ directory, if someone could verify this is expected behavior with secure boot setup i would appreciate it.
That is correct yes. WIth composefs /etc becomes volatile, since /etc is also where the password reset information lives, this causes the password reset to happen on system reset since the information is volatile now. We do have some suggestions here on how to work with a volatile /etc: Secure Boot | Toradex Developer Center
Though we do plan to provide further documentation, examples, and polishing regarding this feature as time goes on.
