Comment 4 for bug 1913087

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
>