Desktop workstations commonly tend to be rebooted more frequently than servers, and laptops more often than either. A few simple steps can do a lot to shorten the wait while the machine gets from power-on to login.

Using readahead to load files from disk

The readahead package runs at boot and populates the kernel disk cache with the files that are going to be needed during boot. To activate it, install readahead, touch the file /etc/readahead/profile-once and reboot once. The profiling boot is very slow, and will tune the list of files loaded to match the list of files used during the profile run.

aptitude install readahead
touch /etc/readahead/profile-once

In squeeze, this is /.readahead_collect

Using a faster system shell

*now default*

The standard system shell /bin/sh was once provided by bash. Bash is very slow at startup, because it does quite a lot of things before it starts to process shell statements. During bootup, a lot of shell scripts are executed, and using to a quicker shell has a noticeable impact. To switch /bin/sh to point back to bash, use dpkg-reconfigure.

dpkg-reconfigure dash

Using sleep mode

It is also possible to take advantage of the system's swap space to obtain very fast booting via sleep mode. This can give a boot process that completes in as little as five seconds after BIOS initialization. However, using sleep mode may require nonfree hardware-specific setup utilities, and/or poorly documented kernel-patching voodoo; and you still need to wait for hardware initialization before swap becomes available.

Using kexec for warm reboots

When your system is performing a warm reboot rather than being powered on in the morning, there's a way to avoid the wait while your computer pointlessly checks and re-initializes its hardware. Rather than go through the BIOS and bootloader, your system can simply go to a minimal runlevel, load the new kernel image into memory, and come back up. This requires a kernel configured with CONFIG_KEXEC=y (standard for Debian kernels) and the package kexec-tools.

Using kexec can save a lot of time if you frequently need to do warm reboots to try a new /vmlinuz, but don't let it set itself up as the default restart-handler if you more often want to reboot into a different O.S. (that is, on dual-boot systems).

You can set up kexec as the default restart-handler using dpkg-reconfigure.

dpkg-reconfigure kexec-tools

If you've just installed kexec-tools and set it up as the default restart-handler don't reboot. kexec will try to execute without having a kernel loaded in memory and reboot will fail. There are two ways to fix this:

  1. Power off and then start the system. kexec automatically loads the kernel into memory during init.

  2. Explicitly load the kernel into memory using kexec. For more information on this consult the kexec man page.

Using Systemd

systemd - Now default

Parallelizing init.d scripts

The order in which scripts run at startup is controlled by the RunLevel system. From Lenny onwards, it is possible to reorder the boot scripts according to the script dependencies. Some init.d scripts can then be launched in parallel during startup and shutdown, so that (for instance) the boot process won't have to stop dead while it waits for the Internet connection to come up. This can be especially important for slow ISPs, or slow DHCP servers!

There are several ways to achieve this.

Using insserv

To enable dependency-based boot-ordering, install the package insserv, and use dpkg-reconfigure to activate it.

aptitude install insserv
dpkg-reconfigure insserv

Parallel concurrent booting (using startpar) should now be active by default. Check that CONCURRENCY=makefile is set in /etc/init.d/rc.

Reorder it manually

insserv does not know about your preferences what services should be started fasted, like your login manager for example. Reordering it manually you can influence this.

Eliminating unnecessary services

It's quite possible that the services that are taking all the time to start are ones you don't need in the first place. This is particularly likely for neophyte users who have simply accepted every installation suggestion their chosen desktop environment task dragged in. What's needed is a way to distinguish between the services you really need and the ones you don't; the surplus packages can then be purged (or their services disabled).

The problem is that documentation for free software is often not very easy for novices to understand, or even find; in particular, scripts in /etc/init.d may contain comments, but they don't provide anything resembling a standard --help option. Fortunately, for most init.d scripts the service name is the same as the package name, so you can find out about it by running apt-cache show <servicename>. If they aren't the same, the script is likely to be named after the daemon it launches, so you can try just checking directly for man <servicename>. Alternatively, dpkg -S /etc/init.d/<service> will give the name of the package that owns that file.

Defining extra runlevels

The Debian system by default uses RunLevel 2 and doesn't define any special function for levels 3-5. If you have services that you want to run only on rare occasions, you can avoid the wait while they start up by declaring that they don't start in the default runlevel, but do in some other runlevel. For instance, you might keep databases you use occasionally on runlevel 3 and a slow MUD server you almost never use on runlevel 4.

You can then switch these sets of extra services on and off by running init (even under X) - for instance, sudo init 4 to activate the MUD server.

Reorganizing runlevels can be carried out "manually" or via interactive runlevel editors such as (the package) sysv-rc-conf. The precautions required for ensuring your changes are not automatically overwritten are not particularly intuitive; for a start, if you delete all of a service's rc.d symlinks, the next package upgrade will put all of them back in "factory default" locations. See man update-rc.d for details.

Analyzing the boot process

Native Method

The official and most accurate way to analyze which processes are increasing boot time in recent Debian releases is using the systemd-analyze tool. The tool is already present in all GNU/Linux distributions which use systemd as an init system, including Debian (default since Debian 8).

Time to boot measurement:

systemd-analyze time

Critical chain analytics (services/daemons which need to be started during boot and affect boot time, please research every daemon's functions before disabling it):

systemd-analyze blame

[Advanced] Nice plot of boot process times (including all daemons):

systemd-analyze plot > boot.svg

You can open the resulting .svg file in any graphical vector image editor such as Inkscape, Gimp, etc.

xdg-open boot.svg

Pybootchartgui method(legacy)

You can also analyze the boot process and where time is spent using Bootchart2.

aptitude install bootchart2 pybootchartgui

This may suggest services that can usefully be eliminated or reordered.

Tests results of users

5 Second desktop by -- [[Jelle de Jong]] <<DateTime(2009-06-23T19:22:32+0100)>>


remaining issues: grub2 and bios integration can be better, grub2 currently flashes through some screens before the "loading the system" screens settles. A nice generic, good looking and unbranded boot splash screen would be really welcome in the Debian main repositories.

My 5 second boot, it takes around 1 additional second for the grub2 to start the kernel and less then one second for the rest of the desktop systems to settle


system: Asus eeepc 901 Linux edition
I use:
- bluetooth keyboard
- bluetooth mouse
- bluetooth speakers and headsets
- usb gigabit ethernet (5 MB faster then build in Ethernet)
- sshfs remote online storage systems, contact me if you want to help out with for real flexible online linux storage
- debian xfce based pct-desktop-environment, please contact me if you want to help get it into Debian preseeding systems and live cds
- usb dvb-t digital tv and radio (not used during 5 second bootchart)
- custom thunar action systems and key bindings, please contact me if you want to help out with the thunar-actions-plugin plugin
I don't use:
- DRI or GLX

-- ?Jelle de Jong 2009-06-23 18:22:32

Use Linux Kernel as bootloader

On a system which has UEFI , you can bypass all traditional bootloaders(like Grub,Lilo,syslinux etc) and make the UEFI boot the kernel. You can also support multi-boot with UEFI this way. A simple setup to try out the Linux kernel as direct bootloader in UEFI is by installing the package

aptitude install efibootmgr

Then issue the efibootmgr command as documented on this page and this page

See Also

An article about improving Debian boot speed:

Do read the comments as well as the article itself in ordeer to see all the ideas.

CategorySystemAdministration | CategoryBootProcess