• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/streamlined-boot

• Created: 2005-10-27 by JaneWeideman

• Contributors: JaneWeideman, ScottJamesRemnant

• Packages affected:

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 be 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.

  • If /var is on a separate partition, it is necessary for these directories to exist on the root filesystem underneath the mount point. The installer and upgrade process ensure these exist.

• 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 up the system in any form, the resulting system may not have any non-essential services running and need not 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 to 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, including /usr and /var.

• 40-49 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. Scripts should probably not assume /usr is available until remote filesystems have mounted.

• 50-59 Catching up

  • Scripts in this area should be used to "catch up" on any writes to the filesystem needed by early scripts, restore any changes to the filesystem not reverted because of a bad shutdown and perform any urgent jobs needed once /usr is available.

• 60-69 Other programs

  • Scripts in this area may run any programs that require the /usr and /var filesystems to be mounted, and the filesystem to be in a pristine state.

• 70-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 seeding 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.