Error Handling in Anaconda

Hi, folks!

I’m working on designing error handling screens in Anaconda.  I’ve come up with a list of different screens and their issues, and I’ve begun to sketch a few of them out.

Error Screens:

  • Insufficient RAM for Anaconda
    • This needs two different screens, one if RAM is sufficient for Fedora but not for the installer being used and the other for if RAM is insufficient for Fedora.
  • Media Verification Failure
  • Incompatible Repository
    • This is only an issue if the user is going through a graphical install, but using a Kickstart file to automatically pre-fill some of the fields with the user’s choices.
  • Unreacheable/Nonexistent Repository
    • Same as above
  • Incompatible Graphics Card
    • With an incompatible graphics card, would we even be able to show them anything?  I don’t know what this error would do to the screen output.
  • Network Connection Interrupted
    • This needs two slightly different screens – netinstall requires a connection, whereas a full install only uses it for optional packages.  This could actually be a total of four screens, if the user’s got a wireless connection we may want to suggest they use a wired one instead.  Wired connections are usually more reliable for this sort of thing.
  • Unknown Error
    • What kind of choices should there be for the user?  The current version of Anaconda has Debug, Save, and Exit.  Debug  sends the user to tty1 and opens pdb, a python debugger. This choice is useless for most people, but it is useful for the Anaconda developers. It is also useful if an Anaconda developer is in contact with the person experiencing an error, as the developer can direct a user on how to use it to help troubleshoot.  Exit will take the user out of the installation process.  Save will save the details of the error to a location of the user’s choice. This uses libreport/ABRT, and might have Bugzilla integrated.

I’ve come up with some potential screen designs based on the required elements of the error screen and the optional elements.  Required elements are things like a statement of the problem; there’s no point having an error screen that doesn’t tell the user what the error is.  Optional elements are things like error icons, or potential reasons the user may be having this problem.  For example, the Network Failure screen requires the problem and the user’s choices, but it could optionally include an icon, suggestions for how to fix/diagnose the problem and avoid a repeat, and possible reasons the problem may have occurred.

I’m trying to stay consistent with the designs for the other Anaconda screens, you can see some of them on Máirín Duffy’s blog.

Here’s a mock-up of what someone using a graphical install and pre-filling fields with a Kickstart file may see:

If it’s feasible to detect their architecture for them, it might be helpful to display it, which is what the grey text under the URL is for- where it says [architecture] it would be neat if we could tell them what architecture it is.  If that’s not an option we can just delete that part.

And here’s what it might look like if you’ve lost your network connection:

What do you think?  Have I missed anything?  Is there anything that could be done better?  Tell me what you think in the comments!

Advertisements

Tags: , , ,

About beefybeliever

I love potatoes and garlic.

8 responses to “Error Handling in Anaconda”

  1. Cameron says :

    You can determine the architecture type pretty easily. It’s available as part of uname. Then again, that only shows what the current kernel is running.

    For the network failure screen it would be really nice to have a few basic utilities available (ping, traceroute, dig). If that’s not an option then a small message telling the user that tty2 is available for such tests would be nice.

  2. Mark says :

    “Incompatible Graphics Card

    With an incompatible graphics card, would we even be able to show them anything? I don’t know what this error would do to the screen output.”

    If X doesn’t start, there’s a chance it will be able to fall back to a console-based install.

    • beefybeliever says :

      I could be wrong, but I think the console-based install is not supported as an option anymore. I’ll ask around to find whether or not we can have a message just in text telling the user what the problem was and how to get around it. Kickstart is probably an option for users with this issue; we might be able to recommend that.

      • Adam Williamson says :

        Right, a text mode error if X fails would be the only option there. I can’t imagine any practical use for a graphical screen telling you graphics aren’t working. =)

      • beefybeliever says :

        Yes, perhaps I didn’t phrase that quite right. I should avoid seemingly paradoxical statements in the future.

      • Bob says :

        The only use for a graphical incompatible graphics screen I can think of is one where the card technically works, but is stuck with the VESA 2D driver or something where there is picture and the installer works, but the OS with its eye candy won’t work.

  3. Bob says :

    For the incompatible repository, would it be possible to try to guess the correct url, test it, and offer it as a possible correction? Ie I booted i386 and accidentally entered repository/packages/arm instead, it could try to swap i386 in for arm and see if that’s a valid repository.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: