Subiquity in inconsistent state after crash/respawn

[Paride Legovini]

When subiquity crashes it restarts automatically and the installation process begin from the first step (language selection). The impression the user gets is that the installation process restarted from scratch, everything is in a clean state and the installation can be retried. This is however not true if curtin already started installing when the crash happens, as:

 * /target is still mounted
 * curtin is still running in background

Proceeding with the installation from this state may bring it to the end, but with settings which are different from those entered during the second try, e.g. different storage/LVM settings. This can be confusing and can lead to unexpected results.

Should subiquity not autorestart on crashes, at least if the crash happens after a given point of no return (curtin called already)?

[Ryan Harper (raharper)]

I've had this very experience just last week. Beyond /target (and many things under it) being mounted there is some persistent state between subiquity restarts (which is nice for the auto-update path) however it may be causing issues when some selections changes. For example, I played with setting/removing proxy and setting/removing mirror; the result after a few failures was subiquity writing an apt file in the /target/etc/apt overlay mount which apt could not parse (it had errors).

There should be a way to clear out this persistent setting surfaced to the user on restart after crash (do you want to keep your previous choices?)

[Michael Hudson-Doyle (mwhudson)]

I can see how if client UI crashes while the install is running confusing things are going to result, and I can have a think about what to do about that.

I'm not sure I understand what happened to Ryan though. Probably the state subiquity does save to disk should be cleared when the server is restarted after an install failure, but I'm still curious as to how /target/etc/apt ended up malformed.

[Paride Legovini (paride)]

I tried to reproduce the failure Ryan described (malformed sources file), but couldn't.

On handling an install failure (subiquity crash): I think that failing in a clear way is better than retrying in an unclear way. Testing the retry-after-failure path is quite difficult as real world failure modes are unexpected, by definition we could say. IMHO on a crash it could make sense for subiquity to allow the user to:

 - submit logs
 - jump to a shell to inspect the failure
 - reboot the system

without allowing the user to retry the install without rebooting.

[Ryan Harper (raharper)]

On Wed, Feb 10, 2021 at 7:56 AM Paride Legovini <email address hidden>
wrote:

> I tried to reproduce the failure Ryan described (malformed sources
> file), but couldn't.
>
> On handling an install failure (subiquity crash): I think that failing
> in a clear way is better than retrying in an unclear way. Testing the
> retry-after-failure path is quite difficult as real world failure modes
> are unexpected, by definition we could say. IMHO on a crash it could
> make sense for subiquity to allow the user to:
>
> - submit logs
> - jump to a shell to inspect the failure
> - reboot the system
>
> without allowing the user to retry the install without rebooting.
>

I'd really really prefer a way to restart from a clean slate. A number
of baremetal systems just *take* forever to boot up. I don't want
to have to wait *again* to try something "different" in the installer.

We need to find where this subiquity state is and clean it out after
failure. We know *at minimum* it remembers the choices you
made on the last run as it pre-selects values and puts inputs into
fields.

> --
> You received this bug notification because you are subscribed to
> subiquity.
> Matching subscriptions: subiquity-bugs
> https://bugs.launchpad.net/bugs/1913087
>
> Title:
> Subiquity in inconsistent state after crash/respawn
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/subiquity/+bug/1913087/+subscriptions
>