StreamlinedBoot

Differences between revisions 13 and 15 (spanning 2 versions)
⇤ ← Revision 13 as of 2006-02-08 03:22:21 →
Size: 2086
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 17: Line 17:
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.
Line 19: Line 18:
attachment:streamlinesplash.gif === All scripts ===
Line 21: Line 20:
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 common needs. Can we reorder the boot targets to shorten the percieved time-to-boot? Consider starting programs like hplip, cupsys, makedev, sshd, powernowd, rsync, openafs, cron, anacron, atd, binfmt-support, alsa, apmd, bluez-utils, fetchmail and acpi-support after the login screen (graphical or not) has been displayed and even suspending their startup until after the user has logged in and the basic encironment (terminal or desktop) is set up. -PhilipGanchev All scripts and daemons should observe the following:
Line 23: Line 22:
== 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 ===		  * `/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 27: Line 24:
=== Data preservation and migration ===  * 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 29: Line 26:
== Outstanding issues ==
Bug comparing Breezy to Mandriva's boot speed: https://launchpad.net/distros/ubuntu/+source/boot/+bug/3485		  * 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 32: Line 28:
== BoF agenda and discussion ==  * 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 34: Line 30:
viper550:
Why not do this like the KDE splash screen, this might be a feasable approach to this idea.
----
CategorySpec		 === 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.

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)