Hi,
I’ve staged a x86_64 common-torizon builder system for scarthgap-7.x.y, did a bitbake torizon-minimal, saved the .wic on an usb media, booted a new VMware virtual machine from it, and registered that virtual device on Torizon Cloud. My intention is to have a first Torizon homelab for secure boot and secure updates research.
Actually, after that vanilla setup, aktualizr throws a few error messages, e.g. ‘Current versions in storage and reported by OSTree do not match’, etc.
What’s the reason?
torizon@torizon-x86:~$ sudo journalctl -f -u aktualizr*
Password:
Mar 11 14:34:08 torizon-x86 aktualizr-torizon[867]: Current versions in storage and reported by OSTree do not match
Mar 11 14:34:08 torizon-x86 aktualizr-torizon[953]: FATAL: Program not found /usr/bin/fw_printenv.
Mar 11 14:34:08 torizon-x86 aktualizr-torizon[867]: Action-handler "/usr/bin/bl_actions.sh" (action=get-firmware-info) returned an exit code of 113 which is unexpected at the moment and will be handled as an error
Mar 11 14:34:08 torizon-x86 aktualizr-torizon[867]: Failed to get a valid manifest from Secondary with serial 9e084a5ebfa21b5c58856710348bfd21ce6af2a84003d8774d065f3567c6fc08 or from cache!
Mar 11 14:34:08 torizon-x86 aktualizr-torizon[867]: Event: UpdateCheckComplete, Result - No updates available
Mar 11 14:39:08 torizon-x86 aktualizr-torizon[867]: Current versions in storage and reported by OSTree do not match
Mar 11 14:39:08 torizon-x86 aktualizr-torizon[966]: FATAL: Program not found /usr/bin/fw_printenv.
Mar 11 14:39:08 torizon-x86 aktualizr-torizon[867]: Action-handler "/usr/bin/bl_actions.sh" (action=get-firmware-info) returned an exit code of 113 which is unexpected at the moment and will be handled as an error
Mar 11 14:39:08 torizon-x86 aktualizr-torizon[867]: Failed to get a valid manifest from Secondary with serial 9e084a5ebfa21b5c58856710348bfd21ce6af2a84003d8774d065f3567c6fc08 or from cache!
Mar 11 14:39:08 torizon-x86 aktualizr-torizon[867]: Event: UpdateCheckComplete, Result - No updates available
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
The error message ‘Current versions in storage and reported by OSTree do not match’ typically indicates a discrepancy between the version information stored in the device’s metadata and what OSTree reports. This can occur due to several reasons:
Incomplete Update Process: If an update was interrupted or not completed successfully, it might lead to such mismatches. Ensure that any updates are fully completed and that the device is not powered off during the process.
Manual Changes: If there were manual changes made to the OSTree repository or the file system, it could cause version mismatches. Verify that no unauthorized changes have been made.
Corrupted Metadata: Sometimes, the metadata used by OSTree or aktualizr can become corrupted. You might need to reset or reinitialize the OSTree repository to resolve this.
Regarding the error ‘FATAL: Program not found /usr/bin/fw_printenv’, this indicates that the fw_printenv utility, which is used to read environment variables from the U-Boot environment, is missing. This utility is crucial for certain operations, especially if your setup involves U-Boot. You can resolve this by installing the necessary package that provides fw_printenv.
For the error related to the action-handler returning an unexpected exit code, ensure that all scripts and handlers are correctly installed and configured. The exit code 113 might indicate a specific issue with the script or its environment.
To troubleshoot further:
Check the logs for more detailed error messages that might provide additional context.
Ensure that your Torizon setup is correctly configured for the intended use case, whether it’s for secure boot or updates.
Verify that all necessary packages and dependencies are installed on your system.
I hope this helps resolve the issues you’re encountering. If you have any more questions, feel free to ask.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Actually, after that vanilla setup, aktualizr throws a few error messages, e.g. ‘Current versions in storage and reported by OSTree do not match’, etc.
What’s the reason?
Please disregard this log message. It’s not an error it’s an informational statement. I see the message all the time, especially on initial boot/setup.
To explain, Aktualizr has a sql storage containing information like what versions of things are currently installed. However, it only stores version information if it came from an update. Therefore, if you have never done an OS/OSTree update the storage has nothing in it.
In this context, the log message makes sense since the version in storage (which is nothing) is not the same as the version reported by OSTree. It’s just informational.
The same can happen if you update the OSTree version outside of the scope of Aktualizr (i.e you do an OSTree deployment without using an update via Aktualizr). In this case the sql storage information from Aktualizr and OSTree would also mismatch. Which is not inherently a problem. It would only be a problem if you expected these to match.
As for the rest of your log that would be the bootloader component complaining since you’re on an X86 VMware machine and it’s probably confused since it’s missing some things that it expects to find.
You are right, the severity for the issue is low as it is a virtual device and not a SoM hardware. This constellation is not handled properly, and ignoring low priority issues is a good solution.
A few interoperability and security tests can be accomplished without SoM hardware.
ToradexAI addressed the issue cause, which is what I was looking for, but the solution proposed wasn’t pretrained for the model context protocolled as build-corei7-64. I’m new to TorizonOS/Yocto and bitbake/aktualizr. How should I handle the VMware v17 x86_64 virtual machine hardware and add fw_printenv/fw_setenv with the libs required of uboot-tools?
This is because those build configurations don’t use U-Boot. It does not really make sense to add U-Boot utilities to a build configuration that does not use U-Boot. So again, you can probably just ignore these messages related to the U-Boot/bootloader component, as they do not pertain to your setup.
A few interoperability and security tests can be accomplished without SoM hardware.
What kind of security tests are you trying to run on a VMWare setup? The early stages of our chain-of-trust/secure-boot process rely on hardware features of the SoC. Which obviously you will not have in a VMWare environment.
Sure. I’m summarizing the similarities between VMware Photon OS and Yocto OS (Torizon OS). Both teams maintain documentation for users, admins, and developers, with additional insights from the community with security benefits from active community involvement. For the moment, I simply took the issue mentioned as a challenge and with that I want to learn more about the build process and customization. Thanks for the web links. Along with the Yocto and Torizon docs, I believe I can gain sufficient knowledge for populating a fix for the issue.
IT security testing isn’t within the scope… I accidentally had to reset my password today. Well, I’m human
