StreamlinedBoot

Differences between revisions 14 and 15
⇤ ← Revision 14 as of 2006-02-09 02:02:53 →
Size: 2884
Editor: ganchev
Comment:
← Revision 15 as of 2006-02-23 14:17:24 → ⇥
Size: 5036
Editor: 213-78-32-60
Comment: write it down
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''': JaneWeideman, ScottJamesRemnant, PhilipGanchev  * '''Contributors''': JaneWeideman, ScottJamesRemnant
Line 9: Line 9:
Identify what we're actually doing during boot up, and decide what we actually need to be doing and drop (or move) anything we don't; regroup the boot sequence into clear targets ("hardware detection", "console setup", "filesystem checking and mounting", etc.).
This is an informational specification that documents the order of the dapper boot sequence, and the policy for all init scripts.
Line 12: Line 14:
== Use cases ==

== Scope ==		 Over the last few releases Ubuntu has been taking longer and longer to boot, mostly because of a lack of clear policy concerning what may done during boot, what may be done at shutdown and whether there are alternatives to either.
Line 18: Line 18:
A good idea would be to do this like the KDE and Gnome splash screens. But instead of using icons, we'd use flashing text on Usplash and the progress bar to show the boot progress. === All scripts ===
Line 20: Line 20:
attachment:streamlinesplash.gif All scripts and daemons should observe the following:
Line 22: Line 22:
=== Interactivity ===  * `/var/run` and `/var/lock` are available as writable temporary filesystems throughout the entire boot process. This should be taken advantage of wherever possible, and used instead of trying to clean up temporary directories on boot.
Line 24: Line 24:
The percieved time-to-boot is the time from pushing the power button till the user can interact with the system for his/her most frequent tasks. Can we reorder the boot targets to shorten the percieved time-to-boot? Consider showing the login screen (terminal or graphical) before starting programs like hplip, cupsys, makedev, sshd, powernowd, rsync, openafs, cron, anacron, atd, binfmt-support, alsa, apmd, bluez-utils, fetchmail and acpi-support, and suspending their startup while the basic interactive environment (terminal or desktop) is being set up. -PhilipGanchev  * Messages should only be printed if the action is expected to take a long to complete, or can fail in anything other than unusual circumstances and is repairable by the user once the boot has completed.
Line 26: Line 26:
The Canon Cat (designed by Jef Raskin) even displayed a graphical image at bootup of the system as it was when the user logged out, so that the user percieved an almost-instant boot, and could recall what he/she was doing. -PhilipGanchev  * The boot sequence is not to be used for displaying messages the user is supposed to read, and no script may pause or halt the boot. If a package configuration is not possible, that should be informed at install/upgrade time, not at boot time. A slight exception is granted to repairing filesystems, but that is all.
Line 28: Line 28:
=== State Recovery ===  * If a script is only used for a particular piece of hardware, consider moving it to a udev rule so that it happens whenever that hardware is inserted.
Line 30: Line 30:
It is also important to improve the recovery of the environment (desktop) to the state it was in when the user logged in. I realize that this is largely a Gnome issue, but we can discuss with Gnome. -PhilipGanchev === rcS.d ===
Line 32: Line 32:
Currently, Firefox sessions are not saved, and so Gnome asks before killing them, which complicates the process of logging out. I suggest that Firefox be shipped with the SessionSaver extension. -PhilipGanchev `/etc/rcS.d` should be only used to perform essential tasks to bring the system up in any form, the resulting system may not have any non-essential services running and need not necessarily be ready to start the X server.
Line 34: Line 34:
Could terminal emulators be made to recover their history and output? -PhilipGanchev Scripts in `/etc/rcS.d` need not worry about starting in parallel, and may assert that by placing themselves at the right point in the sequence using other scripts as milestones, that those scripts will happen before hand.
Line 36: Line 36:
== Implementation ==
The best idea would be to make Usplash only draw those multiple strings, but then code in a system that still works with our output system for the current Usplash, making Usplash flash different text based off coded triggers in the Usplash code.
=== Code ===		 If a script or task is not in the critical path, it may choose to run itself in the background using the usual methods.
Line 40: Line 38:
=== Data preservation and migration === The sequence is split into several distinct task areas, scripts should try and place themselves into the appropriate area and must obey the restrictions associated with each task.
Line 42: Line 40:
== Outstanding issues ==
Bug comparing Breezy to Mandriva's boot speed: https://launchpad.net/distros/ubuntu/+source/boot/+bug/3485		  * `00-09` '''Mandatory initialisation'''
  Scripts in this area must be only performing that initialisation which can be considered mandatory for the correct operation of the computer. They may only rely on the root filesystem being available read-only (no `/usr`, `/var`, `/boot`, etc.), and may only rely on `/proc`, `/sys`, `/var/run` and `/var/lock` being available after `S01mountvirtfs` has run. They may not rely on any devices other than `/dev/null` and `/dev/console` existing.
Line 45: Line 43:
== BoF agenda and discussion ==  * `10-19` '''Driver loading'''
  Scripts in this area should be used to load drivers and configure the hardware. They may only rely on the root filesystem being available read-only (they may write to `/var/run` if necessary), along with other virtual filesystems. They may rely on all expected devices existing after `S10udev` has run.
Line 47: Line 46:
viper550:
Why not do this like the KDE splash screen, this might be a feasable approach to this idea.
----
CategorySpec		  * `20-29` '''Root filesystem preparation'''
  Scripts in this area should be used to check and prepare the root filesystem, including initialising any daemons that may be required to mount further filesystems. Once `S20checkroot.sh` has run the root filesystem is writable, so they may also "catch up" on writes that were delayed from previous scripts.

 * `30-39` '''Other filesystem mounting'''
  Scripts in this area should be used to mount the other filesystems, and perform any catch up tasks delayed from previous scripts now that `/usr` and `/var` are available.

 * `40-49` '''Filesystem restoration'''
  Scripts in this area should restore the filesystem to a pristine state, fixing anything caused by a bad shutdown; for example restoring user files if modified by the system, etc.

 * `50-59` '''Networking'''
  Scripts in this area should perform any tasks that could rely on networking, such as mounting of remote filesystems. While most network devices are available from `S10udev` onwards, some user configured devices may not be available until after `S50networking` has run, so should wait until this point to run.

 * `60-79` '''Sanity checking'''
  Scripts in this area should be used to perform any sanity checking on the system, or make such directories in `/var/run`, etc. that may be necessary for users to run programs.

 * `80-99` '''Final tasks'''
  Scripts in this area should perform any final tasks, such as cleaning up `/tmp` and seeing the random number generator.

=== rc2.d ===

Less policy is specified for `/etc/rc2.d`, except that scripts should avoid starting before `S13gdm` unless they are critical for the correct functioning of the user's desktop.

Summary

This is an informational specification that documents the order of the dapper boot sequence, and the policy for all init scripts.

Rationale

Over the last few releases Ubuntu has been taking longer and longer to boot, mostly because of a lack of clear policy concerning what may done during boot, what may be done at shutdown and whether there are alternatives to either.

Design

All scripts

All scripts and daemons should observe the following:

  • /var/run and /var/lock are available as writable temporary filesystems throughout the entire boot process. This should be taken advantage of wherever possible, and used instead of trying to clean up temporary directories on boot.

  • Messages should only be printed if the action is expected to take a long to complete, or can fail in anything other than unusual circumstances and is repairable by the user once the boot has completed.
  • The boot sequence is not to be used for displaying messages the user is supposed to read, and no script may pause or halt the boot. If a package configuration is not possible, that should be informed at install/upgrade time, not at boot time. A slight exception is granted to repairing filesystems, but that is all.
  • If a script is only used for a particular piece of hardware, consider moving it to a udev rule so that it happens whenever that hardware is inserted.

rcS.d

/etc/rcS.d should be only used to perform essential tasks to bring the system up in any form, the resulting system may not have any non-essential services running and need not necessarily be ready to start the X server.

Scripts in /etc/rcS.d need not worry about starting in parallel, and may assert that by placing themselves at the right point in the sequence using other scripts as milestones, that those scripts will happen before hand.

If a script or task is not in the critical path, it may choose to run itself in the background using the usual methods.

The sequence is split into several distinct task areas, scripts should try and place themselves into the appropriate area and must obey the restrictions associated with each task.

  • 00-09 Mandatory initialisation

    • Scripts in this area must be only performing that initialisation which can be considered mandatory for the correct operation of the computer. They may only rely on the root filesystem being available read-only (no /usr, /var, /boot, etc.), and may only rely on /proc, /sys, /var/run and /var/lock being available after S01mountvirtfs has run. They may not rely on any devices other than /dev/null and /dev/console existing.

  • 10-19 Driver loading

    • Scripts in this area should be used to load drivers and configure the hardware. They may only rely on the root filesystem being available read-only (they may write to /var/run if necessary), along with other virtual filesystems. They may rely on all expected devices existing after S10udev has run.

  • 20-29 Root filesystem preparation

    • Scripts in this area should be used to check and prepare the root filesystem, including initialising any daemons that may be required to mount further filesystems. Once S20checkroot.sh has run the root filesystem is writable, so they may also "catch up" on writes that were delayed from previous scripts.

  • 30-39 Other filesystem mounting

    • Scripts in this area should be used to mount the other filesystems, and perform any catch up tasks delayed from previous scripts now that /usr and /var are available.

  • 40-49 Filesystem restoration

    • Scripts in this area should restore the filesystem to a pristine state, fixing anything caused by a bad shutdown; for example restoring user files if modified by the system, etc.

  • 50-59 Networking

    • Scripts in this area should perform any tasks that could rely on networking, such as mounting of remote filesystems. While most network devices are available from S10udev onwards, some user configured devices may not be available until after S50networking has run, so should wait until this point to run.

  • 60-79 Sanity checking

    • Scripts in this area should be used to perform any sanity checking on the system, or make such directories in /var/run, etc. that may be necessary for users to run programs.

  • 80-99 Final tasks

    • Scripts in this area should perform any final tasks, such as cleaning up /tmp and seeing the random number generator.

rc2.d

Less policy is specified for /etc/rc2.d, except that scripts should avoid starting before S13gdm unless they are critical for the correct functioning of the user's desktop.

StreamlinedBoot (last edited 2008-08-06 16:20:57 by localhost)