I would like to use SWUpdate on Colibri iMX7D to update rootfs. Unfortunately I am not able to get it working (resulting rootfs does not boot properly) with images based on tdx-image-fstype.
I have successfully added swupdate package into the image, defined sw-description file which basically tells where are which data supposed to go and swupdate itself is working as expected. Unfortunately it works only with UBIFS file obtained manually from Toradex specific .tar.bz2 archive (by extracting it and running update.sh with root privileges). I am unable to get it working either with UBIFS obtained directly from bitbake (it does produce .rootfs.ubifs file by default) nor with UBIFS extracted from .tar.bz2 archive in custom recipe using fakeroot. This makes me believe that the issue is related to permissions, but I am not sure what exactly happens here.
I have tested behavior using different UBIFS as shortly described above:
UBIFS produced by bitbake directly ( .rootfs.ubifs file in deploy/images/colibri-imx7 directory) - boot fails (boot log)
UBIFS manually extracted from .tar.bz2 archive (using Toradex specific update.sh script) - boot proceeds as expected, system is working in same way as updating using run update in U-Boot (boot log)
UBIFS automatically extracted from .tar.bz2 archive (using custom recipe with function running in fakeroot to avoid using sudo) - boot fails (boot log)
To be sure that it is not caused by swupdate or anything else in the update process, I have replaced ubifs.img produced by update.sh run manually with the files directly from bitbake and produced automatically by custom recipe, and updating with run update in U-Boot leads to same results (the machine will not boot properly), so I believe that it is safe to rule this out.
Main question: Can anyone point out what exactly is being done in update.sh that cannot be properly done using fakeroot environment but instead requires running it using sudo?
Also, if there is some convenient way to compare different UBIFS files and show differences between then, please let me know.
Also, could anyone help me understand if I should use pseudo instead of fakeroot? I have read that it might solve some issues with fakeroot, but I am unable to find use example in .bb recipe so I am unable to test it.
Main question: Can anyone point out what exactly is being done in update.sh that cannot be properly done using fakeroot environment but instead requires running it using sudo?
Also, if there is some convenient way to compare different UBIFS files and show differences between then, please let me know.
I don’t think so, at least not directly. One could however extract their content e.g. using one of the following methods.
Thanks a lot for any ideas.
You are very welcome.
Also, could anyone help me understand if I should use pseudo instead of fakeroot? I have read that it might solve some issues with fakeroot, but I am unable to find use example in .bb recipe so I am unable to test it.
Yes, I can read and I have read the script, but I do not understand why that could not be done using fakeroot (well, it could be done, but it will produce broken UBIFS). I have thought that fakeroot has been created exactly for cases like this when you need root permissions to achieve something (mostly correct permissions for special devices in rootfs) but can not run process under root or sudo.
By the way, why exactly has to be UBIFS created manually by update.sh, it is not possible to create it automatically during image recipe build?
I don’t think so, at least not directly. One could however extract their content e.g. using one of
the following methods.
Yes, I can read and I have read the script, but I do not understand why that could not be done using fakeroot (well, it could be done, but it will produce broken UBIFS). I have thought that fakeroot has been created exactly for cases like this when you need root permissions to achieve something (mostly correct permissions for special devices in rootfs) but can not run process under root or sudo.
For us such a use case was really just never required as our update.sh script anyway also has a recovery use case which will require root anyway. That said I would assume that the same could be run in some fakeroot environment no problem given you are adhering to the exact same command line parameters.
By the way, why exactly has to be UBIFS created manually by update.sh, it is not possible to create it automatically during image recipe build?
The reason for that is its dependency on certain flash chip properties which may not be known at build time resp. would potentially require several such files to be created. While this may not be the case for the current Colibri iMX7 this is definitely the case for Colibri T20 and/or Colibri VF50/VF61 also using raw NAND. This is also the reason that in the upcoming Toradex Easy Installer we do this truly at run-time when we can simply rely on the NAND geometry as detected by the Linux kernel.
