Fedora

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:

IMAG0651

IMAG0648

(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.

About Máirín Duffy

Máirín is a principal interaction designer at Red Hat. She is passionate about software freedom and free & open source tools, particularly in the creative domain: her favorite application is Inkscape. You can read more from Máirín on her blog at blog.linuxgrrl.com.

Discussion

17 thoughts on “Fedora Installation User Experience Improvements & Syslinux

  1. Yeah, gfxboot has lots of downsides even now that its merged. But nice progress on getting something good without!

    Posted by Jeremy Katz | November 18, 2010, 9:00 pm
  2. Hide everything if you are not pressing a key.

    A lot of BIOS does it at boot, Windows does it, MacOS X does it. Don’t mess the startup with text or options that the common user or most computers doesn’t need. No countdowns.

    Seamless startup, seamless startup. Important for the user experience.

    Posted by nodanero | November 19, 2010, 1:43 am
    • Hey, the problem is that if the user is in an error condition and they don’t know the magic incantation, they won’t be able to get to the menu to enter basic graphics mode. As I understand it we cannot auto-detect error conditions to automatically load reduced graphics mode for them. I would love to just skip it unless a key is pressed but it’s just not possible right now.

      Posted by mairin | November 19, 2010, 8:42 am
      • Right, I’d be heavily against it for that exact reason. Lots of discussions about whether a given bug is a release blocker end with ‘meh, you can always install in basic graphics mode and fix it later’. If we make it too hard for people to get to basic graphics mode, we’ll wind up with a lot more blocker bugs :)

        Posted by Adam Williamson | November 19, 2010, 9:23 pm
  3. Just about to upgrade to fc14 from 13.

    1. I had to use google to find the checksum file for fc14.
    IIRC it used to be on the same page as the download?

    I’ll let you know how the upgrade goes.

    Dave

    Posted by Dave Pawson | November 19, 2010, 4:16 am
    • Hi Dave, it’s in the right-hand sidebar of all the download pages, towards the bottom “Verify”

      Posted by mairin | November 19, 2010, 8:43 am
      • Doh! Wrong again. Sorry to waste bandwidth Mairin.
        Hope I can upgrade rather than start again (I have that
        nasty Redmond sw running uner vmware!)

        Dave

        Posted by Dave Pawson | November 19, 2010, 8:48 am
        • LOL no worries. The install DVD will let you upgrade :) Let me know how it goes since I’m looking at the UX for upgrading too.

          Posted by mairin | November 19, 2010, 10:36 am
  4. The splash artwork is beautiful !!

    Posted by Sylvain | November 19, 2010, 8:59 am
  5. Things I noticed during installation of F14 (my first Fedora) from DVD:

    – Boot message text dump (you call it “ugly black screen”)
    – Why is the media check a text UI? Can’t it look nice / be part of Anaconda?
    – A test input field is missing for the keyboard layout dialog
    – Time zone could be guessed and proposed if internet connection is available
    – Too many small pop-up dialogs just to show progress indicators or other things that could be part of the main window:

    Sometimes an embedded GtkSpinner could be used (like on web pages) instead of a progress bar dialog.

    Posted by vinhoverde | November 19, 2010, 1:49 pm
  6. One thing that has always bugged me in Anaconda is the keyboard layout choser.

    The list is different from the one in Gnome, so I always end up chosing the wrong keyboard layout and I have to change it again once installed with the Gnome tool.

    Couldn’t Anaconda display the same list?

    Posted by bochecha | November 19, 2010, 3:20 pm
  7. Great work! Mairin everything you touch looks and works amazingly. Thank you for doing this.

    Not sure who should I ask but it would be fabulous if in rescue menu we would have options for fixing grub issues, reinstalling grub, etc.

    Posted by valent | November 22, 2010, 9:39 am
  8. Just some ideas:
    1) For all datas that user enter (Name of the computer, root password, user(s) name(s), etc), make the option for two choices:
    – Enter these during the installation of packages (like in Ubiquity).
    – Enter these after the first boot (essential if you’re installing Fedora for a friend or a client.).

    2) I see it’s planed to have an Internet services accounts manager on Gnome 3 (http://live.gnome.org/Design/SystemSettings/Profile). It would be cool if we can add informations about these accounts on Anaconda or Firstboot.

    3) I think it’s good if we have slides during the installation to introduce to news or mains features of the Fedora’s version installed.

    4) After user have create an user account, ask it if he want to restore a Déjà Dup backup.

    5) An “Advanced options” button to change Firewall, System Services and SELinux options.

    What do you think?

    A question: It’s possible to activate the encryption of system after an installation?

    Posted by korbe | November 23, 2010, 5:04 am
  9. A couple of thoughts on this topic:

    It would be really cool and elegant if the plymouth image faded in early and then (apparently) stayed on the screen and ended up as the anaconda or desktop background image.

    It would be nice if syslinux could show the same image in the same resolution too, but generally it can’t and there will be flickering afterwards when KMS kicks in. For this reason I think it has some beauty to keep the syslinux display as understated and close to the bios look’n’feel as possible and thus “invisible” – usually black background and a short prompt with as little flickering as possible.

    But …

    Those who are able to troubleshoot and work around problems will also know how to press shift to get into the syslinux menu, so why not just hide it by default.

    Alternatively, I wonder if we can avoid displaying the boot menu with a scheme like this:
    The (existing or improved) syslinux menu is hidden unless shift is pressed.
    Syslinux prints something like “Booting Fedora. Reboot and press Shift for boot menu”, perhaps in discreet grey on black.
    Once plymouth kicks in it could show the same message until X starts.
    Anaconda could (in most cases) offer to Verify or kexec to Memory Test or Boot From Local Drive.
    In the rare cases where this wouldn’t work there would be a simple workaround and the user would in most cases have gotten good hints about how to find the workaround.

    (And perhaps some clever guy could improve syslinux to put a marker somewhere in memory or cmos so the boot menu could be shown automatically if the previous boot failed …)

    Posted by Mads Kiilerich | December 2, 2010, 7:48 pm
  10. you can install fedora 14 by connecting to an external monitor.

    The details are given in this blog:

    http://techrabbi.blogspot.com/2010/12/solution-fix-fedora-14-blank-screen.html#links

    Posted by Abialsh | December 10, 2010, 7:28 am

Trackbacks/Pingbacks

  1. Pingback: Making Fedora easier to use & the Installer UX redesign « Máirín Duffy - June 16, 2011

  2. Pingback: » Making Fedora easier to use & the Installer UX redesign Máirín Duffy - July 9, 2011

Follow

Get every new post delivered to your Inbox.

Join 62 other followers

%d bloggers like this: