Fedora Installation User Experience Improvements & Syslinux

Over the past couple of days I’ve been working with the Anaconda team trying to figure out how provide a better experience in syslinux. This is a work-in-progress, but here is some of the background, discussion that’s taken place so far, and where things are at currently.

Background

So we’ve been wanting to revamp the installer user experience in Fedora for a while. For Fedora 12 I worked with the Anaconda team on adding better support for specialized storage devices in Anaconda’s GUI. For Fedora 13, I worked with the Fedora websites team to improve the experience that immediately precedes interacting with Anaconda – the Fedora website download pages. To complete that work and to knock out a few other things that would help folks even make the decision as to whether or not Fedora was something they wanted to be installing in the first place, I and my awesome intern Jef van Schendel and Sijis Aviles from the websites team worked on a complete revamp of the Fedora website which was launched with F14.

The Strategy for the Installation User Experience

For F15 then, we’ve got some nice polish on the pre-install experience in place. So it’s time to go back to the install experience and try to get some solid polish there. My overall strategy is to learn everything I can about what our installation experience is like today, then use that knowledge to try to help users achieve the same goals in a more streamlined and polished manner. Along this course so far, I’ve started walking through various installation scenarios on my own, taking detailed notes and screenshots and comparing the different experiences against one another. Whenever a question comes up – “Why does the Live Media install work this way, but the DVD one work that way?” or “Can we remove x screen, it appearsto be extraneous?” – I’ve noted it on a specific wiki page for Q&A and asked the installer team in IRC when I had the chance, copying their answers back into the wiki. I also peppered the walkthrough wiki pages with questions which Chris and other installer team folks have gone through and tried to answer in-line (very awesome. 🙂 )
Going through this process has definitely sparked some interesting ideas. We have a whiteboard space on the wiki for any brainstorming / sketching / mockups / anything you can think of to help improve our install experience in Fedora. We also have a pretty active thread on the anaconda development mailing list. (You are of course, most welcome to participate; those two places are definitely the main places of action here.)

Syslinux

Since it’s the first thing you see during the Fedora install process for both Live Media and the Install DVD, and because I have been aching to do some mockups already and it seemed like it might be fun to think about, I’ve started to focus in on Syslinux’s role in the installation experience.

What is Syslinux?

So what is Syslinux? Syslinux is a lot of things – it’s an upstream project that includes Syslinux the filesystem bootloader; PXElinux for network booting; ISOlinux for CD-ROM booting, among other tools. It’s also specifically the bootloader within the Syslinux project.
Okay, so essentially I think it’s safe to say Syslinux is a bootloader (most commonly used to boot operating systems.)

What is a bootloader?

What’s a bootloader? I am far from an expert here, but what follows is my own explanation based on experience, pestering folks more technical than I, and reading Wikipedia:
A bootloader is a piece of software that enables a computer to ‘boot’ – which involves locating and running a full operating system. The etymology of ‘booting’ according to Wikipedia is pretty interesting:

The term bootstrap derives from the idiom pull oneself up by one’s bootstraps. The term refers to the fact that a computer cannot run without first loading software but must be running before any software can be loaded, which seems as impossible as to “pull yourself up by your own bootstraps.”

CPUs cannot execute instructions directly off of a hard drive, and operating systems tend to be substantial enough as to require the space ofa hard drive. CPUs can execute instructions out of Read-Only Memory and RAM. Your computer’s BIOS (“Basic Input Output System”), which is the very first thing you’ll see flicker on screen when you turn your computer on, is software usually stored on a Flash or ROM chip on the motherboard. The CPU executes the instructions on the BIOS chip as soon as you turn your computer on, and the BIOS performs tasks such as checking out what hardware is attached to the computer, making sure it works (POST – Power On Self Test), getting your keyboard and display working, etc. The BIOS also looks through the devices it finds and determines which ones are bootable, allowing the CPU to execute instructions on bootable candidates if it find sthem. That function I believe is essentially what a bootloader is, so the BIOS among many other things is a bootloader. It will look through the devices that are marked as bootable, and look for files it can load into memory as instructions for the CPU to start running an operating system (or some other bootable instructions.)
This is where bootloaders like Syslinux come in. Say you’ve got a Fedora DVD in your optical drive. You turn your computer on, and your BIOS will list out what devices it finds, including your DVD drive. You’ll tell the BIOS, go and try to boot using my DVD drive. The BIOS then finds instructions on the DVD that it can load into RAM for the CPU to start executing. However, if this is a Fedora DVD, the instructions that the BIOS finds at this point are the code for Syslinux. The BIOS bootloader will boot us into another bootloader – Syslinux – rather than a full operating system (or installer!) Bootloaders can apparently do this – one bootloader booting another bootloader booting another bootloader booting another bootloader – and that process is called chaining.
Okay, so why do we need Syslinux? Why can’t the BIOS just boot Fedora’s installer directly? Well, I don’t think any given BIOS out there is going to know how to boot any operating system. Rather, it knows to look for certain things within hardware that indicate the hardware is bootable, and it then relays the instructions starting at a particular address on that device to the CPU via RAM. At that point, it’s just the middle-man. So for any given operating system you need a bootloader that knows how to start running your particular operating system(s) of choice. Syslinux knows how to boot Windows systems (by chaining into the Windows bootloader, which it can find if configured correctly) and Linux systems. It’s got the instructions that need to be loaded into RAM to get Fedora (or many other operating systems) booting.
Okay, hopefully I haven’t butchered this and don’t have any fundamental misunderstandings or confusions I’m imparting onto you here. (Although if I have I am sure you’ll let me know in the comments, and I’m quite happy to revise the text based on your insight. 🙂 )

Syslinux and Fedora’s Installation Experience

So syslinux affects the Fedora installation experience in two ways I’ve encountered thus far:

1. Syslinux appears when you have a Live USB stick or a CD, and it is the first thing you see every time you boot that media.
2. Syslinux appears when you boot the DVD installer media for Fedora.

As you might be able to tell in the screenshots & the screenshot I’ve provided here, Syslinux for Fedora Live Media presents some different options and verbiage than Syslinux for Fedora’s DVD installer media:

Syslinux for the Fedora 14 Live Media has the following options:

• Boot
• Boot (Basic Video)
• Verify and Boot
• Memory Test
• Boot From Local Drive

While it is not the most blingariffic screen, there’s perhaps less obvious isuses going on here. As you may remember, I’ve been teaching Girl Scouts how to use Gimp and Inkscape, and we’ve been using Fedora bootable Live Media USB sticks to do that. So at the beginning of every class, these 14-year old girls see Syslinux. It does baffle them a bit, still, 5 classes later. By default, a 10-second countdown timer appears, but for some reason the girls always hit enter on this screen, and they see a menu close to what is depicted & described above. (The media they are using is Fedora 13, so the basic video item isn’t in their menu.) Sometimes they use “Boot” to boot, sometimes they use “Verify and Boot.” Other times they call me or one of the other instructors over and ask, “which one do I have to pick again?” I think to them, that menu looks like this:

• Snorfflegappusageraligusoriap
• Snorfflegappusageraligusoriap (Basic Video)
• Dezopanabbim and Snorfflegappusageraligusoriap
• Alskmonpawer Test
• Snorfflegappusageraligusoriap From typarklomapp weafalongu

I was thinking about this case when I put together a proposal for improving Fedora’s Syslinux screens. Two main points to my thinking in this proposal:

• Most users don’t need the Syslinux screen, it just works, passing them onward.Live Media users just want to run their media. In the case of my Girl Scouts, they aren’t just booting the Live Media one time for an install – they are booting it over and over and over. To make them navigate through an extra screen every time is a bit rude. Install DVD users also just want to get to the installer already. They have so many clicks and key presses in store for them already, why give them an extra two or three? In the case where there are no problems getting the keyboard and display and other things needed for installation or boot going, these folks don’t really need to know of or see Syslinux – it’s just there under the covers happily getting them from BIOS to install or OS boot.
• Trouble does strike sometimes, and Syslinux is a helpful tool in getting through it. Hardware can suck. It’s just not working – you get a black screen when you try to boot. Damaged hardware? Crappy drivers? Syslinux passed you off into a broken or corrupted installer process or OS? (Happened to me yesterday!) I don’t know all the reasons, but booting doesn’t always work out, and we need to help folks troubleshoot and work around problems when they happen.

There’s animated mockups in the proposal that show my rough idea at how Syslinux might better behave, look, & feel in those two scenarios above. I’m very open to feedback and comments and suggestions for those, please feel free!

Making the mockups possible

So one thing that kind of sucks about being a designer at times is that you come up with these ideas and these beautiful pixel-perfect mockups, everyone’s excited, look at the pretty pictures! Then you talk to your developer friends and come to understand how they just aren’t possible to implement in the way you designed – they are either entirely not feasible, or just an insane amount of work for the benefits reaped. It’s a bummer.
I really hate to be the bearer of more work for folks who already have pretty full plates, all for the sake of particular text alignment or type of graphic that wasn’t really that vital to the mockup, anyway. Time and trouble invested up front by developers to make for a better end user experience absolutely has the potential to save a ton of time and trouble multiplied many times over for the end users. It’s a delicate balance though – is it really worth a day of a developer’s time to enable some design element that in the end might not actually add that much impact to the end user experience?
So I really wanted to play around with Syslinux and get a feel for what is possible in it. Syslinux is a somewhat limited environment – we don’t know what resolutions the display can support, for example. I fell down into a little bit of a rathole here, though. I looked at screenshots of various distros’ syslinux screens, and quickly came to note that the most aesthetically-pleasing ones were created using a Syslinux add-on module called Gfxboot. I started (rather irrationally) trying to get Gfxboot running to try to play with it.
First, my environment. Jesse Keating suggested a simple environment for poking at Syslinux theming that has proved very helpful – I basically have a Fedora 14 Live Media USB stick. I pop the stick into my full-blown Fedora 14 install on my laptop, Nautilus pops open a window for it, I browse into the ‘syslinux’ folder of the stick and I can directly modify and save the syslinux.cfg file that among other things controls the appearance of syslinux.
For Gfxboot, I grabbed the latest tarball of Syslinux (Gfxboot has been included in Syslinux as a module since Syslinux versoin 3.84 or so) and grabbed the Gfxboot.c32 file out of it, copying it into my Live USB stick’s ‘syslinux’ directory. Then, I grabbed the Gfxboot RPM from SuSE and cracked it open, baffled at how the SuSE Gfxboot as packaged interacted with the c32 module for syslinux. Then it finally dawned on me – the SuSE gfxboot package was actually a command-line program that you run to create bootsplash files, which are essentially Gfxboot theme files. I would need to create a bootsplash file, copy it into the syslinux directory on my USB stick, then reference it in the syslinux.cfg configuration file.
I was a bit overwhelmed at trying to figure out how to get a bootsplash file put together when I had the good fortune of running into hpa, Syslinux’s author, in IRC. As much as bcl on the Anaconda team warned me that Gfxboot probably wasn’t a good idea, the blingification possibilities wooed me in so much I had thought there was hope. But hpa set me straight – the showstopper is that if your Syslinux theme uses Gfxboot, you’re not going to be able to present syslinux over a serial console. I don’t want to cripple functionality we already have without a really good reason to do so. Happily, hpa also showed me how to achieve almost everything I really wanted from my mockups – turning off the menu borders, changing various default messages on screen, etc. So I ended up with the following results as of this afternoon:


(Forgive the banding in these photos – it’s not there in real-life; I’m guessing it’s due to some interaction between my camera & the refresh rate of the screen.)
I think it’s a big improvement over what we had for F14. I want to try to figure out better wording for the [Tab] message, and I also want to try to get a nicer-looking font in there (it supports .psf fonts, a beast with which I’ve no experience). A good start I think!

Try the prototype on your own

I wrote up some instructions on how you can try this prototype out on your own. It’s really, really easy. If you want to poke around with it once you’ve tried it out, just edit the syslinux.cfg file in the syslinux directory.
If you know what you’re doing, here is the syslinux.cfg, and here is the splash artwork.