Error Handling in Anaconda
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.
- 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!