From Boot to Halt

MJ Ray

During this session, we covered:-

• viewing the Linux kernel boot messages
• finding information on installing a boot manager
• where to configure drivers and how to test them
• what ”runlevels” are and which files and commands control them
• ...and much else besides
• .

This session was run by MJ Ray as a demonstration of the taught sessions for the forthcoming Turo Technology LLP training for the LPI certification exam.

The session took place in a seminar form. A number of cards were handed out out to the participants in 2 work groups in batches, each card representing a step in the normal work cycle of a GNU/Linux system. Each batch added more detail to the boot process, starting with the simple "Power on" and "Power off" and finishing with a complete description of the process.

During the session, groups made notes on the cards from the discussion and placed them in order in the centre of the table, with ”power on” at the top and ”power off” at the bottom. If two cards were interchangeable, the cards were put side by site.

Session Outline

1. Power on - start fans, light lights...
2. Power On Self Test - check basic hardware responds: memory, graphics, extra CPUs, CPU sensors; beep codes.
3. “BIOS boot” - print list of hardware, offer setup screens
4. Boot record - check drives in order (normally configured in BIOS setup) looking for the first active partition. Partitions are subdivisions of the disk, usually edited with fdisk, cfdisk or similar
5. Boot manager - most popular are the LInux LOader (LILO) and the GRand Unified Bootloader (GRUB). They have to be installed to a place where the BIOS can find them: the command to do this for LILO is lilo and for GRUB, use grub-install. They have configuration files which tell them what kernel to use by default, what other options, how long to pause and wait for user instructions, and much more. GRUB reads its config file from disk, but LILO’s is stored with it. Keith mentioned the GRUB in Debian HOWTO from LinuxOrbit.
6. Load kernel and initialised RAM disk - the boot manager copies the Linux kernel into memory and possibly an initrd containing more drivers.
7. Kernel startup - the boot manager’s work is done and it calls the kernel code. Normally, its first actions are to decompress itself, work out what memory and processors it has and then start device drivers.
8. Initialise built-in drivers - device drivers come in two forms: they can be built into the kernel and they can be add-on modules loaded by the kernel. The built-in ones cannot normally be deactivated and may cause conflicts with other drivers, so it’s recommended to use as few as possible, but some are necessary. If you make your own kernel, more advice on this is in the instructions.
9. Load initrd modules - It used to be that you had to have built-in drivers for your main disks and so on, but recent kernels can use modules for these. A special ”RAM disk image” is made and loaded into memory by the boot manager. The kernel can load modules from this.
10. Mount root filesystem - The RAM disk is a useful tool, but the next task is to get some permanent disks. The kernel mounts its main ”root” disk next. The drivers for it must have been loaded by now, else there will be a panic. Forgetting your disk drivers is a common error when compiling a kernel.
11. Start “init” - The kernel has completed its basic startup and runs a program called “init” as its first task. This keeps track of the basic state of the machine and manages changes of state. It is told what commands to run when entering a particular state (or “runlevel”) by its config file at /etc/inittab and controlled manually using the command “telinit”
12. Check disks, mount disks, add swap - init does some basic tasks, often stored in /etc/rcS.d, before picking a runlevel. The root partition was read-only until now, so it is checked for errors (throughly if necessary) and mounted. The same is done for other disks. Any “swap” partitions are added as virtual memory using the “swapon” command.
13. Single-user mode - init enters runlevel S, the startup single-user mode. Any leftover process are killed and a command from inittab is run on /dev/console. This normally lets the superuser login and repair the machine.
14. Multi-user mode - init enters a numbered runlevel like 2. This is set by a line in inittab. Normally commands in /etc/rc2.d starting with K are run with a parameter “stop” then any left-over processes are killed, and finally any commands in /etc/rc2.d starting with S are run with a parameter “start”.
15. Graphical mode - some distributions and some system adminstrators use one of the numbered runlevels to start a graphical user interface. 5 is a popular choice. All numbered runlevels from 0 to 9 exist but 0, 1 and 6 have special meaning.
16. Start server daemons - some of the S programs will start server daemons like the Apache webserver or PostgreSQL database server.
17. Start graphical user interface - one of the S programs may start a graphical login interface like xdm, wdm, Login.app, kdm or gdm.
18. Start “login” - the text-mode login is not normally started by an S program, but by “getty” which is controlled by lines in inittab for each virtual console.
19. Prepare for reboot - runlevel 6 is special. After running K programs in /etc/rc6.d and killing leftovers, init calls reboot.
20. Prepare for halt - runlevel 0 is special. After running any K programs in /etc/rc0.d and killing leftovers, init calls the halt command, which can switch power off on suitable machines.
21. Power off

fdisk output

dmesg

inittab