Archive | June 2012

Anaconda’s Errors: A Comprehensive Gallery

Good afternoon!

Last week, I posted twice about error screens for Anaconda – beginning here.  I’ve taken in feedback and altered some of the designs accordingly, and now I’ve got a mockup of every error screen here for you to see.  Feel free, as always, to leave me comments.


Anaconda’s Errors, Part Two

Back on Wednesday, I posted about potential screen designs for Anaconda’s error screens.  I’ve cleaned up what I showed you and I’ve gotten more of them fleshed out.

If Anaconda can’t verify or deny the integrity of your install media, it could look somewhat like this:

What do you think?

Here’s what the network connection failure screen I showed you last time has been updated to look like (note, this is for wireless users doing a net-install, text is slightly different if either of those cases is not true):

There’s less empty space between the buttons & on the buttons, the icon has changed from a generic error icon to a network connection icon with a little X.  As requested, the user is now also informed that tty2 is available for troubleshooting.  Some wording has changed.

Then there’s this design for unknown errors:

Obviously we’d be hoping this screen never came up for anyone, but realistically software does have problems, and it’s better to have a nice screen for it than no screen.  So if you have any ideas for this one, especially what kind of options the user might benefit from having, post a comment!  Feedback is always appreciated.

There are five basic screens, as far as I can tell, that Anaconda will need.  There’s the network connection failure screen, the kickstart-prefill repository issue screen, the media verification screen, the unknown error screen, and the insufficient RAM screen.  There are some necessary variations for some of the screens, but if I pin down one case of each of those screens, the rest is just fine-tuning, a sentence here or there.  Two of these were in my previous post, this post revisits one of them and displays two more, and there’s one screen you haven’t seen: Insufficient RAM.

This screen’s gone through so many rough drafts.  There are so many technical details that I don’t know, or didn’t know, and have had to account for.  Currently, I believe the plan is to give the user a link to a page on the Fedora wiki that explains all the options someone with little RAM has.  It would cover ways to install for users with enough RAM for Fedora, but not enough for Anaconda.  It might cover potential solutions for people who don’t have enough RAM for Fedora – perhaps recommending similar distros with less taxing system requirements.  The biggest obstacle to this is that there is no such page as far as I can tell.  If you want to write a page, go ahead!  I will probably end up writing a page, but it really isn’t my field of expertise and I don’t think I’d be able to write a comprehensive one.

Thanks for reading!

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!