I have observed the following issue on some verdin am62 boards, hoping to get some feedback on what had gone wrong.
I create a custom TorizonOS image using overlays and TorizonOS 6.7 as a base image. In my custom image I also include the provisioning data for auto provisioning.
I have flashed a few boards with this image using Tezi, then booted them with internet connection, to make sure that device gets provisioned. Once I have confirmed that device was provisioned and added to torizon cloud, I switched it off.
Some weeks after, when I boot the same board, i see some provisioning data corruption error, rac fails and hence it is not seen as online in torizon cloud.
I have attached the RAC journalctl log. Any insight on what happenned? rac.log (59.9 KB)
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
It sounds like you’re encountering an issue with provisioning data corruption on your Verdin AM62 boards after they were initially provisioned successfully. This can happen due to several reasons, such as file system corruption or improper shutdowns affecting the integrity of the provisioning data.
Here are some steps you can take to troubleshoot and resolve this issue:
Check File System Integrity: Ensure that the file system on your device is stable and not corrupted. You can use tools like fsck to check and repair any file system issues.
Review RAC Logs: Examine the RAC log you provided for specific error messages that might indicate what went wrong. Look for any signs of file corruption or network issues that could have affected the provisioning data.
Network Stability: Ensure that the device has a stable internet connection during both the initial provisioning and subsequent operations. Network interruptions can sometimes lead to incomplete or corrupted provisioning data.
Re-provisioning: If the provisioning data is indeed corrupted, you may need to re-provision the device. This involves re-flashing the device with a clean TorizonOS image that includes the correct provisioning data.
Best Practices: Follow best practices for device provisioning, such as ensuring the device is properly shut down and rebooted after provisioning, and using a reliable power source to prevent unexpected shutdowns.
By following these steps, you should be able to identify and resolve the issue with your device provisioning. 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:
Another important question: I see you have 2 email accounts. The issue you are facing is related to devices on the email of this @stasgil user or on the other email?
Hi Henrique,
I have to confess, i have no idea what other email you are talking about. Do you mean that there is another user with my name but a different email account, or another user from my organisation? I’ve made several posts / requests on the community website by now, and i believe they were all from the same account (this one)
The thing is: due to repository sharing feature of Torizon Cloud, you can manage devices that are not owned (were not provisioned) by your Torizon Cloud account.
I am just asking if the devices you are talking about were provisioned to your Torizon Cloud account (the same email of your @stasgil user here on Community),
OR
They were provisioned to some other account (still from your company, e.g. something like torizon@your-company.com) and you are just managing them (due to repository sharing).
Ah, i see. I have used the credentials.zip for the email address of this account i believe.
Interestingly, I just went to torizon cloud website to download my credentials.zip again to compare with the one I have (downloaded a while ago, sometime in summer), and apparently i no longer have permission to download it…
However, i’m not sure if that is the issue, because if there was a problem with my credentials, then I would expect to lose provisioning for all of the devices I have provisioned. But that is not the case…
Could you please share specific details on how your workflow for flashing the devices?
Right now the main point of interest is what happens with the devices when the provisioning step is ongoing. There was a case where the power was cut so early that the provisioning was not completed. This kind of fits your case since it didn’t happen to all the devices. But getting more information on how exactly the first boot for provisioning was done can help us to understand it better.
Another thing we would like you to check are the contents of /var/sota/import on the device. Could you please check if the files there are empty 0-byte files or not?
Apologies, I got buried with some other tasks… My process for the provisioning was the following:
1. Plug USB stick with the firmware image into the Yavia board
2. Put the Verdin board into the Yavia board
3. Power on the Yavia board
(The image yaml file has following options:
autoinstall: true
autoreboot: true
accept-licence: true
So the image download is automatic on power on)
4. After board rebooted, login to the board over ssh as torizon user (over ethernet)
5. Wait until provisioning is complete
(journalctl --lines=all -f -u auto-provisioning and look for " Finished Automatically provision the device to the Platform Services." message)
6. Confirm device appears on the torizon cloud
Re /var/sota/import/ I can confirm that all files there are 0 byte files
root@verdin-am62-15361834:/var/sota/import# ls -al
total 8
drwxr-xr-x 2 root root 4096 Dec 9 11:51 .
drwx------ 4 root root 4096 Jan 3 12:12 ..
-rw-r--r-- 1 root root 0 Dec 9 11:51 client.pem
-rw-r--r-- 1 root root 0 Dec 9 11:51 gateway.url
-rw-r--r-- 1 root root 0 Dec 9 11:51 info.json
-rw-r--r-- 1 root root 0 Dec 9 11:51 pkey.pem
-rw-r--r-- 1 root root 0 Dec 9 11:51 root.crt
Could you please also let us know what is the next step after 6. Confirm device appears on the torizon cloud?
I am asking this because for instance, if the devices are shut down after step 6, the best approach is to issue a shutdown, which will guarantee that the writings to the disk are all flushed out. On the other hand, a sudden power cut (e.g. simply removing the power source) can lead to the files not be written.