I am thinking about possible bad case scenarios of a flash procedure with the EasyInstaller. One possible issue could be that the http server (serving the yaml files identifying an easyinstaller compatible directory) is not functioning when the SOM (flashed with the TK1 EI v1.5 image) is powered on.
In case the http server keeps not functioning the flashing is just not triggered.
In case the http server is functioning from a point in time after the SOM has been powered on:
Does EI check for yaml files regularly and trigger an autoinstallation (in case of autoinstall is set in one of the yaml files)? Or does EI check for yaml files just once after poweron and the flashing would not be executed?
The Toradex Easy Installer uses json files. I assume s/yaml/json…
This depends on what “not functioning” exactly means. If the server is not reachable (by IP), then an error message will be shown and there won’t be a retry mechanism. Similarly if the http server is not running (port closed). In case the http server is running and does not serve image list or image file, this will lead to an error message as well. However, in case the http server is running but the image files are not served (stalls or the connection gets disconnected for some reason), then the Toradex Easy Installer will retry up to 10 times before failing.
If the server is not reachable (by IP)
In this case the wrapup.sh script is not executed and the error message not communicated to the wrapup.sh script I guess? The overall procedure “hangs” after the prepare.sh script has been successfully executed which would have to be caught with a time-out check.
In case the http server is running and does not serve image list or image file
Same assumptions as above. Are they correct?
However, in case the http server is running but the image files are not served (stalls or the connection gets disconnected for some reason)
In case the retries would not be successful:
The wrapup.sh script is not executed and the error message not communicated to the wrapup.sh script I guess? The overall procedure “hangs” after the prepare.sh script has been successfully executed and after the 10 not successful retries. This case would have to be caught with a time-out check.
The above assumptions are correct.
Thx for cross-checking Stefan.
