Linux Plumbers’ Conference Shirt

The Linux Plumbers’ Conference is in San Diego this August.  It’s going to be a lot of fun for the participants, who I’m sure are looking forward to it.  I’ve been asked to design a shirt for them, and I’d like to show the world what I’ve made:

(the back of the shirt)

(the front of the shirt, pocket alignment)

I’m proud of this design, I love it and I hope you do too!  I was inspired by the beauty of circuit boards, plumbing, and the city skyline in San Diego.  The font I used is called Changa One.

Advertisement

Kickstart Autodetection

Some Fedora users don’t just pop in a disk and install.  Instead, they use something called Kickstart.  With Kickstart, you can write a file that tells Anaconda what choices you want it to make, you can just hook it all up, turn it on, walk away, and come back with your machine installed exactly like you asked. It’s a great tool, especially if you have a lot of machines that you want configured identically.  With the new UI for Anaconda, Kickstart’s about to get a whole lot cooler.  It’ll still work the way it has always worked, but it will also now be able to accompany a traditional graphical install and pre-fill all the selections with what you’ve picked out.  The problems we ran into here include: What if someone has multiple Kickstart files?  How can the person be sure they have the right file?  What if someone only wants part of the Kickstart file?

We came up with the following four images to represent a potential screen layout.  There’s a different screen for multiple Kickstart files detected than there is for only one, because the drop-down would be a waste of screen space if there was only one choice.  If you click the little plus box for “More Options” you can choose which parts (roughly) you want to use of the Kickstart file; you can turn off everything in %post if you want, or everything in %packages, for example.  There’s no good way to differentiate between separate sections of the same type, so you cannot choose one %post and another %post.  You can use all of the %post sections or none of the %post sections.  If you click on an item in the list on the left, you can read the relevant portion on the right so you don’t accidentally use the wrong Kickstart file, and you can review what you’ve chosen before you put it into effect.

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!