Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad entry: https://features.launchpad.net/distros/ubuntu/+spec/slick-boot

• Packages affected: usplash

Summary

Improve the boot sequence to reduce the number of mode switches and jarring look and feel changes.

Rationale

While our current boot sequence has evolved beyond a verbose scroll of text on the console, it is still not as elegant as it could be. Increased elegance would result in a much improved user experience, and increase user confidence in the distribution.

Use cases

• Simon's computer rapidly switches between the splash screen, a black screen, a flashing cursor, a brown screen and finally the login screen on boot. This makes him feel that the operating system is unprofessional.
• Matthew's monitor takes a couple of seconds to switch between different modes. The multiple mode switches in the current boot sequence make him nervous.
• When Rodger shuts down his machine, the progress bar appears to stop and then the screen goes blank. He panics and believes the machine has crashed, when in fact this is normal.

Scope

The scope of this specification is the changes needed to usplash and the associated themes to improve the elegance of the ordinary boot sequence, and decisions about what will not be permitted.

The SetupConsoleUnderUsplash specification addresses current technical limitations and the solution for that.

The UsplashFsckProgress and NoUsplashTimeout specifications address feedback issues that cause unusual changes to the boot sequence.

The UsplashUntilDesktop specification proposes altering the location of the switch between usplash and the display manager to further improve the elegance.

Design

We have up to three console modes used during the boot sequence:

• text mode inherited from BIOS (not PowerPC or Sparc)
• SVGA or framebuffer graphical mode used for usplash
• high-resolution, accelerated mode used for X

Currently we switch between these in a fairly haphazard manner. The goal is to only iterate through the modes once in each direction.

Implementation

This will be accomplished as follows for the boot sequence:

• Do not use a graphical boot loader, as that introduces yet another mode
• Output as little as possible in the initial text mode, this should be limited to essential boot loader prompts and messages.

• Through the SetupConsoleUnderUsplash and NoUsplashTimeout specifications, avoid switches back to the initial text mode.

• Allow usplash to be terminated by the VT switch into X itself.

• Optionally implement the UsplashUntilDesktop specification to further reduce visual jarring.

The shutdown sequence is more tricky, as the flicker is caused by usplash being killed in order to unmount the root filesystem. The killall command will need to be modified so that usplash is not killed; ideally we would also run usplash from a temporary filesystem so that the root can be made read-only before shutdown.

Visual Aspects

Current the theme used for the splash screen and the login screen are distinct, this creates a visual break between the two. These should be altered to be complementary, ideally from a user point of view, the screen has the progress bar replaced with the text box in which to type their user name.

Comments

• Why not target for a time based boot process too simultaneously - say a 5 second boot at the maximum, so that the development on a more stylized boot process is not wasted in the future when attention turns to speed due to another competitor's product? Also, let's extend the concept of 'Themes' to the startup process by providing configuration variables through a GUI in the Gnome->System->Preferences menu. --SisirKoppaka

• I'm sure this won't be an easy task - don't even know if it's possible at all, but: Why not show the GDM login directly after the boot menu, let the user input its username and password and continue the boot-process (showing a progress-bar somewhere on the login screen) in the background? So the user wouldn't be required to wait for the boot to be completed, until he can "interact" with the system again? --CharlieBravo

  • ["Warbo"]: As far as I understand it Ubuntu was seen to boot much quicker then Debian (at least when I first started using it, just before Breezy's release) because the boot order was changed. In Debian the order used to be: Get everything up and running, then let people log in. Ubuntu's boot order has been: Do whatever is required to let users log in, then let them log in. This appeared to be a massive improvement in bootup time, when in fact it took just as long, but people could be logging in whilst some of the less important system services were starting. Upstart should improve this even more (when the startup scripts are modified to make proper use of Upstart at least). This sounds like what you describe, however there are many system services needed before users can log in. Networking has to be running, since logins might be remote, and even local services make use of the loopback networking (localhost), mailer systems need to be started to keep track of any errors, logs need to be started to accept various outputs, proposed implementations of ConsoleKit would need the DBUS message system to be running, having a fancy GDM login screen needs X to be running (which requires networking and loads of other stuff) and altogether it takes a while. Even logging a user in directly (ie. setting a default user in the login window preferences) requires all of this stuff, since GDM looks after the graphical user session. Having a username and password entered at the very beginning of the process would create problems I'm sure, with filesystem availability questionable, all manner of things being juggled in memory, the security concerns would be profound, etc. I think that in order for some heavy development to work in this area there needs to be some key architectural changes to the way systems boot, since many technological advances seem to have been accounted for by bolting addons to less than ideal processes, but Ubuntu's UpStart is a key step in the right direction, and RedHat people are working on the issue as well with ConsoleKit and a replacement for the stagnating GDM (GNOME Display Manager). This should enable distributions to focus their startup sequence on a single process (for example a basic login screen) without worrying about what is needed to make that work (UpStart does that), all login sessions should work in the same way with regards to needed permissions and things so a fancy display manager isn't needed (ConsoleKit does that), then many frontends can be chosen from to run the actual login manager for the session, depending on the capabilities available (text only, framebuffer, X, OpenGL, etc.) (GDM does that). This should not only make bootup more responsive, but it should make the whole system more flexible for failure handling and future directions (as it stands there is a ton of issues to juggle before any small changes can be made, since the whole stack seems built like a Jenga tower of new features adding and performance tweaks taking away).