Provisioner got stuck

[benoit74]

At 12:54 pm, provisionner was still at 48%. It had been so since at least 2 hours.

Disk is one of the models of #37, since it was expected to take some time, but not to stay there forever.

I interrupted with Ctrl-C and it looks like it interrupted correctly:

I wasn't able to shutdown properly (I had to "force press" the power button to force shutdown).

I boot the device and it was fine until it complained about aborted journal.

What could/should I do in such a situation (besides restarting provisioning of course) to diagnose where the process got stuck / whether it is just a display issue / find traces of where it might have stopped.

[rgaudin]

At 12:54 pm, provisionner was still at 48%. It had been so since at least 2 hours.

Thank you ; this confirms displaying the ETA is useful.

I interrupted with Ctrl-C and it looks like it interrupted correctly:

This means the device/OS/app was not frozen which is good to know (and better for diagnostics)

I wasn't able to shutdown properly (I had to "force press" the power button to force shutdown).

Have your tried single-press? This is independent of our software so unless the system is frozen, it should shutdown and would be the correct course of action if there is no progress (we intentionally don't allow cancel or anything once provision has started)

I boot the device and it was fine until it complained about aborted journal.

Given the force-shutdown, it's to be expected and we cannot conclude for sure that it's due to disk not completely written.

What could/should I do in such a situation (besides restarting provisioning of course) to diagnose where the process got stuck / whether it is just a display issue / find traces of where it might have stopped.

Post-shutdown, there's nothing to do.

Instead of ^C, it would have been helpful to use q which is completely under the app control and if working would mean that the app is still working OK. What happens on ^C still triggers in-app code as shown in the screenshot but is partly handled by the interpreter.

Ideally we'd want to not exit the app, open a separate shell and look at the rpi-imager process: still there? not zombie? Then check iotop (not installed).

It's not possible at the moment as there's a single tty opened and it started the app. Exiting the app would kill its children including rpi-imager process, so not helping. We could have a shortcut start a shell though or have another tty open.

My hypothesis at this stage is that rpi-imager was still running. Was it not progressing? Possible. Did it encounter an error and displayed something that's unexpected (and thus not reported)? That's possible.

One thing I considered at some point was to write what we read from rpi-imager's output to /tmp. This would have help in this case.

I don't think it's possible for rpi-imager to fail (or succeed) without the UI not updating (or crashing) which is why I see this more as an enhancement than a bug at this stage 😅

[benoit74]

I tried to "single-press" and it looked like it did something (terminal change resolution and text inviting to shutdown by pressing the button disappeared) and then froze (forcing the "force-press")