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
- Using a faster system shell
- Using sleep mode
- Using kexec for warm reboots
- Using Systemd
- Parallelizing init.d scripts
- Eliminating unnecessary services
- Defining extra runlevels
- Analyzing the boot process
- Tests results of users
- Use Linux Kernel as bootloader
- See Also
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
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.
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.
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:
Power off and then start the system. kexec automatically loads the kernel into memory during init.
Explicitly load the kernel into memory using kexec. For more information on this consult the kexec man page.
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.
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
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
You can 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 sshfs-storage.org 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 - GNOME
-- ?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
An article about improving Debian boot speed: http://www.debian-administration.org/article/Booting_Debian_in_14_seconds
Do read the comments as well as the article itself in ordeer to see all the ideas.