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 a faster system shell
now the use of dash is the 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.
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.
Using 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
systemd -- Now default -- The boot process is parallelized.
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, systemd configuration files under /etc/systemd and /lib/systemd may contain comments, but they don't provide anything resembling a standard --help option. Fortunately, for most systemd configuration files, 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 /lib/sysyemd/configuration_file_path will give the name of the package that owns that file.
Defining extra runlevels
The Debian system under systemd defines runlevel by using symlinks such as /lib/systemd/system/runlevel5.target pointing to graphical.target which defines its behavior. Normally:
- runLevel 1 for booting the rescue system
- runLevel 2 for booting the multiuser system (normally used for the Linux virtual console only system)
- runLevel 3 for booting the multiuser system
- runLevel 4 for booting the multiuser system
- runLevel 5 for booting the multiuser system (normally used for the GUI system)
- runLevel 6 for rebooting the system
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 by tweaking systemd configuration.
You can then switch these sets of extra services on and off by running runlevel - for instance, sudo runlevel 4 to activate the MUD server.
Analyzing the boot process
The official and most accurate way to analyze which processes are increasing boot time in recent Debian releases is to use the systemd-analyze tool in systemd package
Time to boot measurement:
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):
[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.
There is also systemd-bootchart package which is essentially a more detailed version of the systemd-analyze plot function mentioned above.
Tests results of users (outdated)
This section needs to be updated.
Pybootchartgui method (outdated, kept here as reference for next section)
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.
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