EasyInstaller error handling

Technical Support
, , ,
1

I am successfully flashing the TK1 (pre-flashed with EasyInstaller) with “unattended flashing”.

I thought about possible bad case flashing scenarios and wondered

  • if the EasyInstaller implements error handling
  • in case: which error handling
  • in case: how is error implemented/communicated to the outside world.

Is there some undocumented environment variable (comparable to $1 - PRODUCT_ID, $2 - BOARD_REV, etc.) set between the call of the prepare_script and the wrapup_script to indicate bad cases (e.g. EXIT_CODE) like “image files removed” and other bad case scenarios to the wrapup_script? Or it the wrapup_script not executed at all in error cases? How do I get to know about the error root cause then?

2

The Toradex Easy Installer has primarily design for interactive use. Even in the unattended installation case, the current assumption is that a production worker has a screen and would see an error message and act accordingly. If any step during the installation fails, the Toradex Easy Installer stops and displays an error message. In this case the user is expected to press OK and retry/sort out that module.

So if an error happens before prepare or the wrapup script gets usually called, then the script won’t be called at all. But the scripts can report errors back to the Toradex Easy Installer: If the exit code is not zero, an error message with the output of the stderr will be displayed.

For a fully automated environment, or an environment without any display, the Toradex Easy Installer in its current state is not well suited. If you have some outside automation which can access the serial console, your best chance is probably to timeout in case image installation fails and read/store the Toradex Easy Installer log located at /var/volatile/tezi.log.

3

Thx for the fast response. I’ll adjust our scripts to the current state of the EasyInstaller.

4

I am only able to commuicate the EasyInstaller logs from the EasyInstaller to a remote machine (e.g. via nc) not the other way around, right? This means that I am limited to transmitting the log of the EasyInstaller in some error handling routine in the prepare and wrapup scripts. Would I have some possibility to get the log for e.g. the timeout bad case (where I am not able to send it from the EasyInstaller to a remote machine via nc)?

5

Not sure I understand your question correctly. Currently there is no way to execute something “on error”, hence with the built-in functionality there is no way to get the log file transferred.

What I would suggest to do is using pexpect (or similar) serial port automation on a connected host. Use echo "Production flashing complete" > /dev/console in the wrap up script to get a string on the serial console. Use something like this in your pexpect script:

m.expect(["Production flashing complete", pexpect.TIMEOUT], timeout=120)

# At this point we either timed out or finished flashing. Copy log either way...
m.sendline("nc 192.168.10.1 1234 < /var/volatile/tezi.log")
m.expect("# ")

if ret == 0:
    print("Successfully flashed!")
else
    print("Error during flashing!")
6

Hi Stefan, yes that’s what I was asking for. Thx for the hint with pexpect. In case we timed out: What would be contained in /var/volatile/tezi.log?

7

tezi.log also contains the text shown in the error message shown on the UI. You should be able to simulate a failure e.g. by plugging out Ethernet during installation (assuming you install the image over Ethernet)… It may take a while since curl will retry several times, but it should fail ultimately.

8

The hint that the log file potentially contains all UI messages as strings is valuable. Thx.