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

Currently 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).

    • [JeromeHaltom]: It would obviously be nice to allow users to see the login ASAP, and only require the network if they are doing a network login. This should be knowable. That is, after they enter their username/password, pop up a "Waiting for Network" message of some sort... which of course would switch to a crediantial cache if network wasn't up.

    • [MichaelZKrog]: This hole "we need network because it might be a remote login" is one of the mental states that keeps Linux off the desktop a lot of places. Ask your self: "How often would my Mom use a remote login on her computer?". I think we need to change our minds into KISS(Keep It Simple, Stupid).

    • [ChrisJones2]: I think it's worth mentioning that starting the login sooner means the user has to endure significantly more grinding of disks during and after their login. My laptop takes a significant amount of time to log in because of all the seeking while it's still starting system processes. I agree that starting the login sooner makes a good impression, but if you then take a minute to actually start their session you are going to tarnish the impression. Perhaps the system stuff (ie init scripts) could be given a much lower io priority so it doesn't impede the user?

• Redhat is working on smooth GUI booting, and plans to have it ready when Fedora 9 releases in June 2008 (that's the schedule anyway). Reference: http://www.x.org/wiki/Events/XDS2007/Notes (and other notes from XDS2007) - TimoAaltonen

• [porl]: i think it is important to allow a keyboard shortcut to hide the splash and return to text boot. often if the splash screen seems to be taking a while it is difficult to know whether it has hung or is just doing some long running process. i believe 64studio does this by putting a message like 'press f2 to view boot messages'. i know you can edit the grub boot to remove splash, but often it isn't until afterwards that i decide i want to watch the boot messages.
• [danfolkes]: I think the Cntl+Alt+F1 will show boot messages. I agree, this should stay there. Hopefully verbose will not frighten any users.
• [zeth0] With all due respect, I think the biggest problem is not what happens before the login manager but what happens after it. The Ubuntu system boots up halfway and then does nothing at all while it waits for login. Then when you log in, the graphical desktop slowly splutters into life. A better setup would for the desktop environment to begin preloading in the background while the login screen is being shown. Then when you login, you instantly see a fully ready to use system. Now that would be slick. After all, most desktop users use one desktop environment. However the default setup is optimised for more than one desktop installed (a small minority). The Mac login is currently better because it is optimised for one desktop.

• [garba] What about removing all those nasty boot up messages? it's been already discussed on the forums and most users seem to agree see this post: http://ubuntuforums.org/showthread.php?t=519081

• [ricjd] I was actually thinking about this the other day. The one thing i don't think works on the boot screen, is after the disk has been mounted x times a force check is done. This enabled by default on a standard ubuntu install. so when this happens the user is thrown into a screen where there is lots of messages and the system checking the hard drive. To me this is similar to the screen windows users get when the computer has been turned of without a shutdown and it checks the disks. Basically it could scare someone using ubuntu for a while and make them think it's 'unstable', when it's not. If it could be done that the checks are routine and have a graphical representation this would be better for the window migratory and linux newbies
• Agree - and - on "slower" computers (e.g. like mine, Athlon 2500+, Geforce5900FX, and that's not THAT old) you can see the panel loading after login, then the panel icons appear - but they are the GNOME standard icons - and then they change into the Ubuntu ones. Isn't that a waste of resources? Better draw the icons when is determined which theme and icons are used.

Sound

• [brettalton] I think this is a big issue not to miss: the login sound -- "ahhhhh". Right now, in Gutsy, especially with Compiz enabled, the sound plays while the screen is blank (brown background). Then after 5-15 seconds - depending on the hardware - the first gnome-panel and wallpaper are slowly built onto screen. What about caching all the desktop loading and waiting until it's fully loaded to show the desktop, showing a 'loading' or 'Ubuntu is loading' screen while doing so, THEN play the sound when everything fades in. If that's not plausible, I say at least play the sound once the very first gnome-panel is built and displayed else you're playing that euphoric introduction noise to nothing...