Hi,
I use the ALEOS framework to deploy and run a custom application (dotnet, compiled to a linux armv7 binary) on a fleet of RV50x.
I manually generate a zip file(so not using the IDE) with the proper Application Model xml and the tar file with my binaries and then upload this to AirVantage.
I can clean install the application (meaning going into the RV50x’s web interface, clicking Applications->ALEOS Application Framework-> Uninstall then “Install Application” in AirVantage) but I cannot update an RV50x with the application already installed; I get that “[m3da.commandfailiure][Cannot extract update package, tar res=[1,nil]]” error in AirVantage.
Thank you for any help.
Hi @development,
Welcome to our community!
Have you followed the ALEOS Application Framework guide at this link: https://source.sierrawireless.com/resources/airlink/aleos_af/aleos_af_home/#sthash.ry81Y7Pw.dpbs
“I manually generate a zip file(so not using the IDE) with the proper Application Model xml and the tar file with my binaries”? → I still don’t understand what you mean by this? Please describe it more clearly.
Thanks.
Hello jerdung,
We have a custom application built using .net that runs on a device (RV50x).
What he means by “I manually generate a zip file(so not using the IDE) with the proper Application Model xml and the tar file with my binaries” is that our application was zipped up, and the xml file used to define the application and version was generated and used as the update package so that the deployment system can recognize the application properly.
We have been able to deploy a version of our app to the device and that worked fine.
However, when trying to update the RV50x with a new version after the application is installed, suddenly there is an error saying the package cannot be extracted.
We can, however, manually uninstall the application and then install the next version.
Since the ability to do a clean install means the update package is fine, we are wondering why we are not able to perform an update.
Hopefully, that helped.
We discovered this was a space issue. Our custom binary’s tar was 80mb; after cutting some files down to 70.4mb we no longer saw this issue.