Revision 5 as of 2009-07-28 15:34:51

Clear message
  • Launchpad Entry: karmic-boot-experience

  • Created: 2009-05-25

  • Contributors: Ubuntu Platform, DX and Design teams

  • Packages affected: see dependencies below

Related specs:


This specification documents the changes planned for Karmic to the various /user visible/ steps of the boot sequence of the Ubuntu system, including KMS support at various level in the software stack, and work on ensuring smooth transitions between these steps.

By extension, other aspect of the user experience are covered in specifications linked to this one, namely:

  • the splash screen shown during system boot
  • the OS switcher, allowing the user to select another operating system to boot
  • the fallback "splash", that includes running file system checks or querying the user for a password to unlock a encrypted filesystem
  • the "login experience", that includes autologin, the gdm greeter, and also logout and session switching

These changes are also depending on the FastBoot effort lead by ScottJamesRemnant in the Foundation Team.

Release Note

Release notes, based on the above description and impacted packages, will be detailed as the integration progresses.


The current boot experience feels rather jerky with a lot of abrupt transitions between different system states. With the advent of KMS as a generally stable technology, it is now possible to reconsider the full "boot experience" and turn that into a more pleasing and visually consistent experience.

One of the main goals is to get rid of flicker caused either by resolution changes (KMS) or by visual flashes due to screen clears, replacing that with more modern color/opacity transitions for example.

User stories

Joe turns on his notebook. He sees the manufacturer's logo and then his system starts booting. After a few seconds, he sees a small animation to let him wait while the system automatically opens his user session in the background. As soon as his session is ready, the system smoothly fades-in the

Jane has a slow machine with a lot of disks that are hard to check and mount. When she boots, the system displays a small spinner after 3 seconds, as it determines that the boot sequence is going to be longer than usual.

Bob would like to use the other operating system installed on his machine. He turns on his computer, waits for a few seconds, then sees a graphical message on his Ubuntu system screen to invite him to press "Esc" if he wants to interrupt the Ubuntu boot and switch to another version. He presses 'Esc' and the system presents him a set of alternative boot choices, including other kernel version and legacy OSes. If he were to select the legacy OS, Ubuntu would shutdown and instruct the computer to reboot (but only for this time) directly into the legacy OS. But Bob would rather try the new experimental kernel he just installed, so he selects kernel-2.6.3X and his system shutdowns and reboots (for this time only) with the new kernel he selected.


This spec has been designed for conventional x86 systems. Parts of it may probably also apply to other hardware architectures.

(User Interface) Design

The overall look & feel and design requirements for the new boot experience are expressed in a separate document: see DesktopExperienceTeam/KarmicBootExperienceDesignSpec

(Technical Design and) Implementation

The implementation is split into the different dependent blueprints:

Code changes or migration issues and strategies are detailed within the different blueprints.

Test/Demo Plan

The test plan will be documented, based on the user stories above, at http://testcases.qa.ubuntu.com/Plans/KarmicBootExperience

Unresolved issues

  • Plymouth vs usplash: for displaying splash screens in case of issues or as a fallback scenario when the boot sequence is longer than usual, we're still considering both alternatives. They both have advantages and inconvenients
  • User testing: initial feedback indicates that users can accept 3-4s of blank screen time during at the beginning of the boot sequence, but that may require further testing to validate this assumption.

BoF agenda and discussion