Improvement suggestion: crinit should not stall when a task file is corrupt

[jochen-messner]

My target (qemu) was accidentally rebooted while I edited a .crinit task file. Since the file was corrupted, it had a wrong syntax. During reboot crinit reported the wrong syntax and stalled forever.

That happened in the initial phase when all files get parsed. As a consequence the target did not boot anymore.

Suggestion: Just report/log the parse error, continue, and ignore the corrupt task files in the remaining initialization steps.

[gmcn42]

Thanks for the input! In fact, the behavior you encountered is - as of now - intended. To elaborate, crinit is targeted at embedded systems usage where the boot configuration is well-defined and a broken file may indicate that "something is seriously wrong". Our strategy here is to "fail early and fail hard" if crinit detects such an error (or general data corruption, if signatures are used) and stop the boot process.

In our design phase, we also thought of the best-effort approach you describe but chose not to implement it that way as it might obscure an error that could lead to undefined system behavior down the line (e.g. due to a service not being present).

That said, we realize this can be an inconvenience during the development / prototype phase and are open to counter-arguments. We'll leave this issue open for further discussion.

[simone-weiss]

Hi, how about to have some variable for this in the default.series conf? Like DEBUG?