Handling complete failure in the installer

[Evan Dandrea]

On Thu, Nov 12, 2009 at 2:40 PM, Roman Shtylman <shtylman at gmail.com> wrote:
> Overall, I like the idea of a more fault tolerant installer... who wouldn't :)

Indeed.  As Lucid is a Long Term Support release, I'm very keen on
really giving some thought to better handling failures such as this,
and either recovering from them automatically or providing a clear
path for the user to do so.  I'd also like to add more code to protect
the users from feeding bad data into the installer
(ubiquity/validation.py), continuing Colin's work on static testing,
adding automated and unit testing, and so on.

Further ideas and code welcome :).

For example, today I finished up a "retry grub installation" dialog
for the GTK frontend that will come up when grub-installer fails.  By
the way, it would be wonderful if you could port that to the KDE
frontend whenever you have some free time.

> Out of the three options that Evan presented, I have concerns about
> option #2 (install then upgrade). To me this feels like back-peddling
> and basically giving off the impression that this release is not
> complete enough (since the installer couldn't even work). They may be
> less likely to update once they go back and install the previous
> version. It also may require them to go download a whole new disk
> image (a concern for some).

The installer didn't work.  We shouldn't shy away from that.

This is all about giving them something more than a shrug and apology.
 While I can empathize with your concerns, if a previous release could
work for them, I don't believe we should discourage it because it's
not an ideal path.

I think if downloading a new image is a concern, they wont do it.  But
they may not be aware that they can easily upgrade between Ubuntu
releases, and that it's free.  So I think it's important that we
present the upgrading option.

> The other two options are more proactive and suggest what the user can
> do in the immediate sense to solve their problem. Option #1 I believe
> to be the best. We may even want to remind the user what step they
> were on and maybe which set of options they have selected to that
> point? It might refresh their memory and possibly make any bug report
> their choose to file more complete.

Just to be clear, my intention is for the dialog to present all the options.

The difficulty I see in incorporating what page the user was on when
the install failed into the retry the install message is that it's
likely they were already at install.py (the main progress bar, for the
unfamiliar), and thus it's unclear what particular component caused a
failure.  Of course, we could mark this as we progress through
scripts/install.py, but that would leave copy_all as a grey area
(which admittedly, it would be anyway).  Any suggestion on how we
would word this?

Thanks for the input; it's very much appreciated.