Boot procedure

can be roughly divided to the following steps:

  1. Hardware Boot
  2. OS Loader
  3. Kernel Startup
  4. System Initialization

Boot keys and GRUB config

The following keys can be used during Hardware Boot stage:

DelBIOS setup (some computers)
F2BIOS setup (some computers)
Fn+F2BIOS setup (some notebooks)
F8MS Windows safe mode (after POST press and hold / it does not work, of course, if Windows is not installed)
F9System recovery (if manufacturer or supplier provides this option / you can also prepare it yourself)
Fn+F9Boot device selection (some notebooks with UEFI)
or ESC
Show hidden GRUB menu (press and hold at the end of the Hardware Boot stage); see details below
TabBoot info (some computers / at splash screen)

GRUB menu allows you to load different versions of kernel, to run memtest, etc. By default it's usually configured not to be displayed if there is only one OS installed. Still you can get it by pressing and holding the SHIFT key (or ESC in systems with old GRUB) when BIOS outputs misc info about devices. When menu appears, press or (Down/Up arrow keys) to select option, then ENTER to continue the boot process.

To force GRUB menu always to be displayed, edit /etc/default/grub (the root priv is required!):





By default Ubuntu starts quite silently. If you want to see the boot process details, edit /etc/default/grub:


To run Ubuntu in text mode, set:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash text"

If you need the text mode just to solve some system problems, then may be you should select a recovery boot option in the GRUB menu!

Note that GRUB config changes are ineffective until you run

sudo update-grub

Also note that if you do something wrong, reboot may fail. You can then try recovery, or boot from USB or CD (whichever suits better), but in first case, root fs would be mounted read-only (i.e., you cannot edit config), in second case, update-grub cmd is not as simple as shown above. All these problems can be solved, but it requires some knowledge and manual work.

To run custom tasks at the end of the system start, add your code to


There are also some options in /etc/default/rcS, e.g.:




The first option requires /tmp dir to be cleaned at each reboot, non-zero values set the number of days to keep stuff (except -1 which means "never clean"). The second option requires to minimize the output during startup (man 5 rcS gives details).

Note about EFI/UEFI


EFI/UEFI is mostly for 64-bit operating systems!

The following description of the first two stages (Hardware boot, OS loader) applies to a classical BIOS/MBR system configuration. However, as new computers (2010 and newer) usually have a firmware of a new type named UEFI (EFI), and use GPT partitioning instead of MBR, the boot procedure may be not exactly as described below.

A typical PC with UEFI firmware usually supports two boot modes:

(from this point consider EFI and UEFI as synonyms)

If your PC has a UEFI firmware, it does not mean that Linux must be installed to use EFI boot mode (though it may be reasonable). However, if you plan dual boot (e.g., Linux + Windows 7/8), EFI boot mode may be the only option. It is also necessary if HDD has (or is planned to have) a GPT partitioning.

EFI boot requires a special EFI partition. It is assumed to be common for all bootable operating systems, and in ideal case Ubuntu Linux (since 12.04) can use EFI partition created by Windows 7/8 setup. However, in non-trivial cases (like manual Ubuntu installation) you may need to create this partition manually (GParted latest version, like the one included in Ubuntu 12.04, is one of the appropriate tools). An EFI partition must comply to the following requirements:

Hardware boot

After power-on (cold reset), control is given to a program stored in BIOS. This prog performs basic Power-On Self-Tests (POST), then reads params from CMOS. As a minimum, it needs to know what is the boot device, or which devices to probe as possible boot devices. If boot device is found, the program tries to load the OS Loader, which is located on a fixed position on the boot device, and, in case of success, transfers control to it.

The successful completion of this stage is usually signaled by one short beep; more than one means problems. See BIOS Beep Codes for details.

OS Loader (Boot Loader)

is located in the first sector of the boot device (MBR, cyl 0, head 0, sec 1). This primary loader is limited due to the size of MBR (446 bytes; the rest is occupied by partition table), therefore, it usually calls a secondary OS loader which may be located on a specified disk partition. The main job of the OS loader is to locate, load and run the kernel. The most popular Linux OS loaders are lilo (Linux Loader, old) and grub (Grand Unified Bootloader). Most distros nowdays use grub. Currently, there are 2 branches: grub 0.9x (GRUB Legacy) and grub 1.xx (GRUB2). To find your version (must be root):

grub-install -v

GRUB Legacy main config file is /boot/grub/menu.lst (usually linked to /boot/grub/grub.conf) that looks like:





title Linux Fedora Core (

  root (hd0,0)

  kernel /vmlinuz- ro root=LABEL=/ rhgb quiet

  initrd /initrd-


title Other

  rootnoverify (hd0,1)

  chainloader +1

where default=0 means that the first kernel in the list will be loaded by default, timeout=5 sets the timeout in seconds (if you do nothing during this timeout, GRUB waits for 5 sec, then loads default kernel; to cut timeout, press ENTER).

GRUB2 uses following files/dirs:

Some useful (editable) options in /etc/default/grub are:





Note, that GRUB_DEFAULT=saved sets the default menu entry with whatever was selected last. Custom entries to GRUB menu can be added by editing /etc/grub.d/40_custom file. To activate changes in these and other files, you should run update-grub (it looks for new kernels, operating systems and re-creates grub.cfg). If you install or remove kernels using rpm or apt-get, GRUB menu is edited automatically.

Some of GRUB shell cmds

(when GRUB menu is displayed, press 'c')

boot boot OS or chain-loader;

chainloader file   prepare to boot other bootloader;

configfile file   load an alternative config file;

halt shutdown computer;

help [cmd]   show help;

initrd file   load the specified initramfs;

insmod file   insert (load) grub2 module (GRUB2);

kernel file [args]   load a kernel (GRUB Legacy);

linux file [args]   load a kernel (GRUB2);

ls [-alh] [file]   list files (all, long, human-readable) (GRUB2);

lsmod show loaded modules (GRUB2);
quit exit from GRUB shell (GRUB Legacy);
reboot reboot computer;
root set GRUB’s root device (GRUB Legacy);

set [var=value]   set/show env variables (GRUB2);


GRUB2 uses partition notation that starts with 1, not 0 like GRUB Legacy, devices are still numbered from 0, so /dev/sda1 is now (hd0,1), NOT (hd0,0) as before!

Recovery mode (single user mode)

Some systems have recovery mode menu item added as the part of the new kernel installation procedure. Recovery mode is not the same as rescue mode.

Rescue mode

GRUB's functionality is provided by loadable modules residing in /boot/grub. If there are some problems with disks, partitions, files, several kinds of GRUB prompt may pop up. Normal GRUB prompt instead of menu means that there are config problems (like grub.cfg is bad or missing). In worse cases (bad partition/filesystem/files) you may fall back to the rescue prompt (grub rescue>). This usually means that GRUB cannot load the required modules and only a limited subset of the normal GRUB cmds is available (ls, insmod, set, unset). The first move in rescue mode is to try to load the appropriate modules and become normal GRUB shell (rescue shell cannot even load a kernel). Assuming that GRUB resides in a separate boot partition /dev/sda1 (otherwise use /boot/grub instead of just /grub):

grub rescue> set prefix=(hd0,1)/grub

grub rescue> insmod (hd0,1)/grub/normal.mod

rescue:grub> normal

If the above fails, try:

grub rescue> set prefix=(hd0,1)/grub

grub rescue> insmod (hd0,1)/grub/linux.mod

grub> set root=(hd0,2)

grub> linux /vmlinuz-2.6.31 root=/dev/sda2 ro

grub> initrd /initrd-2.6.31.img

grub> boot

Note, that you can use ls to see known devices and partitions:

ls -al show all devices available;
ls -alh (hd0,1)/boot/   show files in (hd0,1)/boot dir;

If all attempts have failured, or if there are no GRUB prompt at all, reinstall GRUB. Total disapperance of GRUB may be the signal of a wide-scale disaster. However, in some cases this may be just the result of Windows installation procedure.

How to restore (reinstall) GRUB2

Some modern Linux distro DVDs can function as LiveCD, or have some kind of rescue mode. The best way to reinstall GRUB is to use the same distro DVD you used to install Linux. However, if it doesn't provide the required function (or is not available), use some other LiveCDs (except old stuff). Alternatively, you can create a special USB flash drive with GRUB software (stored files won't be erased or damaged).

One of possible algorithms:

How to restore GRUB Legacy

This is a variation of the above procedure: LiveCD is only used to get GRUB prompt, then the existing system is loaded from HDD. Note, that some commands and device notation are slightly different:

grub> root (hd0,0)

grub> kernel /vmlinuz- ro root=LABEL=/ rhgb quiet

grub> initrd /initrd-

grub> boot

When the system is loaded, there are two methods to reinstall GRUB. The first method is considered a little bit dangerous:

cd /

grub-install /dev/sda

Second method gives you more control.


grub> find /grub/stage1


grub> find /boot/grub/stage1

This is not required, but helps to find root device as GRUB understands it in the current situation. Most likely it is (hd0,0) which means first partition on Primary IDE Master or SATA0 or SCSI 0.

grub> root (hd0,0)

grub> setup (hd0)

grub> quit

Note, that similar cmd setup (hd0,0) installs GRUB into the boot sector of the first partition (most likely you don't need this).

See also "How to..":

restore DOS MBR         create GRUB boot floppy

Kernel startup

When the kernel is loaded, it initializes the devices (via their drivers), starts the swapper (kernel process kswapd), and mounts the root file system. Then it creates first user land process init (/sbin/init; pid = 1), passing to it any params that weren’t handled by the kernel already.

In the old Linux (Unix) systems there was a /dev dir with a static set of device nodes (special files). It was large, because for every device, that might possibly appear in the system, there was a device node created beforehand. However, since Linux kernel 2.6.13 (?) device manager udev dynamically creates only the nodes for the devices actually present on a system. udev runs as a daemon and listens to uevents the kernel sends out via netlink socket when a new device is initialized or a device is removed from the system. The main components of udev are:

For some device classes (e.g., storage devices) udev supports persistent device naming, that does not depend on the order in which devices are plugged into the system. You can affect the process of device node creation by adding (modifying) rule files in /etc/udev/rules.d

sysfs is a filesystem managed by the kernel and mounted at /sys dir. It exports basic info about the devices currently plugged into your system. udev can use this info to create device nodes corresponding to your hardware.

System Initialization

There are 2 well-known old-style initialization procedures: BSD and SysV (System V). Currently, some Linux distros (e.g., Fedora since v.15) use systemd, while others (like Ubuntu) prefer Upstart. Anyway, backward compatibilty with SysV is also supported, because old-style init scripts are still widely used. This mixture of different styles slightly complicates the understanding of the initialization process.

System V init (sysvinit)

is based on a runlevel concept. The SysV init examines /etc/inittab for a line that sets a default runlevel:


If there is no such line, user is prompted to enter runlevel value manually. The initialization process is synchronous, i.e., the next task wouldn't start until the current one is finished. The init daemon runs scripts in /etc/init.d dir. The order of execution is defined by the symlinks in /etc/rc.d dir. The names of these symlinks are interpreted as follows: first letter S means that the script must be invoked during startup, first letter K - during shutdown, digits set the order of invocation. By modern standards sysvinit is slow and resource-consuming. It is also inconvenient for the desktop systems, that require fast and reliable interaction with USB devices, removable storage, etc.


is an event-based system, that starts and stops services and tasks asynchronously, and supervises them while OS is running. The time and the order [of the specific service start] depend on a set of conditions (like the presence of processes that a service depends upon). The main Upstart programs are the init (daemon) and the initctl (it starts and stops init jobs, sends signals, and queries the status of jobs. The Upstart init daemon tries to perform tasks in parallel to finish the boot procedure as fast as possible. Upstart service config files (equivalent of Sys V init scripts) are in /etc/init dir. Here is an example of a simple service config file for a permanently running daemon (server application listening on some tcp port); this config file provides start/stop and auto restart in case of an abnormal exit:

# htpasd - this server app provides ... ...;


description "third-party daemon"


start on (net-device-up and local-filesystems)

stop on runlevel [!2345]


expect fork



exec htpasd

You can find details using  man 5 init  and multiple examples in /etc/init (if your system is Upstart-based, of course).

Classical /etc/inittab is not neccessary any more, though it can be present. To set the default runlevel, edit


Upstart consists of 5 packages:

See usage examples in initctl.

Though Upstart is backward-compatible with sysvinit and runs the old-style scripts unmodified, you should not rely on the old tools like chkconfig, rc-sysv-conf, ntsysv - they control old-style services only. The new-style services are being started and stopped if/when the pre-defined conditions are met. To prevent the start of a new-style service during system start, change the extension of the corresponding config file, e.g.:

cd /etc/init

mv dovecot.conf dovecot.disabled

stop dovecot

You also have such options as moving the service .conf file to some other dir, or totally deleting it (unwise), or removing the appropriate software pkg from the system (should be carefully considered). The last cmd (stop) is required if the service is currently running.


defines the certain system's state, characterized by the set of the running services (daemons). It is a System V paradigm. The last Ubuntu releases emulate runlevels for backward compatibility with the old-style scripts and for compatibility with the third-party applications intended for other distributions.

There could be up to 8 runlevels, but only 3 are mandatory:

RL Name Description
0 Halt Modern x86 computers usually power off when run level 0 is reached; older x86, and some different architectures display a message and stay on;
1 Single user mode In run level 1 no daemons (services) are started; GRUB / Recovery mode (single user mode) explains how to boot into a single user mode;
6 Reboot This is like runlevel 0 except a reboot is issued at the end of the sequence instead of a power off;

The other runlevels are treated differently by different systems. It's supposed, that for each supported runlevel, /etc/inittab has a description of what should be done when the system switches from one runlevel to another.

RL Description
2 Full scale multi-user mode without GUI; default runlevel for Red Hat/Fedora server, Ubuntu, Debian (see note below);
3 Same as previous plus NFS (?); default runlevel for Arch Linux, Gentoo, Slackware;
4 Usually undefined;
5 Full scale multi-user mode with GUI, i.e., the most appropriate mode for the desktop systems; default runlevel for Mandriva Linux, SUSE Linux, Red Hat/Fedora desktop;

In Ubuntu/Debian runlevels 2, 3, 5 are all the same (multi-user, GUI). To check the current runlevel:



who -r