Booting a Linux installation involves multiple stages and software components,
including firmware initialization, execution of a boot loader, loading and startup of a Linux kernel image, and execution of various startup scripts and daemons. For each of these stages and components there are different variations and approaches based on various hardware; for example, GRUB, LILO, SYSLINUX or Loadlin can be used as boot loaders, while the startup scripts can be either traditional init-style, or the system configuration can be performed through modern alternatives such as systemd or Upstart.
The following diagram shows a typical x86 based linux boot steps.
In this post, I will go throught sysvinit based boot up process using a yocto based linux system running inside qemu.
What version of init in the system?
sysvinit based init File structure
/etc/initab : top level set up
/etc/init.d/: directory contains all init scripts for initial boot setup, including "/etc/init.d/rc" which will kicks in the right runlevel, e.g. " /etc/init.d/rc 5"
under each directory, it can have script name starts with "K[0-9][0-9]*.sh", which is to stop the service, and name starts with "S[0-9][0-9]*.sh", to start service.
what is runlevel?
What is runlevel?
Runlevel is a mode of linux system operation, possible value:
0: Halt, Shuts down the system.
1: Single-user mode, Mode for administrative tasks.
2: Multi-user mode, Does not configure network interfaces and does not export networks services.
3: Multi-user mode with networking Starts the system normally.
4: Not used/user-definable For special purposes.
5: Start the system normally with appropriate display manager (with GUI) Same as runlevel 3 + display manager.
6: Reboot, Reboots the system.
How to know what runlevel the system is in:
switch runlevel, use the following command:
or telinit [0-6]
e.g. often we will do “init 6” to reboot box, after command is entered, the scripts under “rc6.d” will be executed, the last one is S90reboot, which is a softlink to “reboot” script, which eventually runs /sbin/reboot.sysvinit.
The inittab file describes which processes are started at bootup and during normal operation (e.g. /etc/init.d/boot, /etc/init.d/rc, gettys…). Init distinguishes multiple runlevels, each of which can have its own set of processes that are started. Valid runlevels are 0-6 plus A, B, and C for ondemand entries. An entry in the inittab file has the following format:
Lines beginning with ‘#’ are ignored.
id: is a unique sequence of 1-4 characters which identifies an entry in inittab (for versions of sysvinit compiled with the old libc5 (< 5.2.18) or a.out libraries the limit is 2 characters).
(Note: traditionally, for getty and other login processes, the value of the id field is kept the same as the suffix of the corresponding tty, e.g. 1 for tty1. Some ancient login accounting programs might expect this, though I can’t think of any.)
runlevels: lists the runlevels for which the specified action should be taken.
The runlevels field may contain multiple characters for different runlevels. For example, 123 specifies that the process should be started in runlevels 1, 2, and 3. The runlevels for ondemand entries may contain an A, B, or C. The runlevels field of sysinit, boot, and bootwait entries are ignored.
When the system runlevel is changed, any running processes that are not specified for the new runlevel are killed, first with SIGTERM , then with SIGKILL.
action: describes which action should be taken.
Valid actions for the action field are:
respawn: The process will be restarted whenever it terminates (e.g. getty).
wait:: The process will be started once when the specified runlevel is entered and init will wait for its termination.
once: The process will be executed once when the specified runlevel is entered.
boot : The process will be executed during system boot. The runlevels field is ignored.
bootwait: The process will be executed during system boot, while init waits for its termination (e.g. /etc/rc). The runlevels field is ignored.
off : This does nothing.
ondemand: A process marked with an ondemand runlevel will be executed whenever the specified ondemand runlevel is called. However, no runlevel change will occur (ondemand runlevels are ‘a’, ‘b’, and ‘c’).
initdefault: An initdefault entry specifies the runlevel which should be entered after system boot. If none exists, init will ask for a runlevel on the console. The process field is ignored.
sysinit: The process will be executed during system boot. It will be executed before any boot or bootwait entries. The runlevels field is ignored.
powerwait: The process will be executed when the power goes down. Init is usually informed about this by a process talking to a UPS connected to the computer. Init will wait for the process to finish before continuing.
powerfail : As for powerwait, except that init does not wait for the process’s completion.
powerokwait: This process will be executed as soon as init is informormed that the power has been restored.
powerfailnow: This process will be executed when init is told that the battery of the external UPS is almost empty and the power is failing (provided that the external UPS and the monitoring process are able to detect this condition).
ctrlaltdel: The process will be executed when init receives the SIGINT signal. This means that someone on the system console has pressed the CTRL-ALT-DEL key combination. Typically one wants to execute some sort of shutdown either to get into single-user level or to reboot the machine.
kbrequest: The process will be executed when init receives a signal from the keyboard handler that a special key combination was pressed on the console keyboard.
process: specifies the process to be executed. If the process field starts with a ‘+’ character, init will not do utmp and wtmp accounting for that process. This is needed for gettys that insist on doing their own utmp/wtmp housekeeping. This is also a historic bug.
line#5 tell system goes to runlevel 5 after system boot.
line#9 and 12: runs when it boots in single user mode.
line#22 - 28: invoke set up for each runlevel.
In the above setup, this is what will occur:
system goes into runlevel 5, which will trigger all scripts under "/etc/rc5.d/" to be executed.
After this is done, the system is ready to be used!
# Example : adding a script to do something after box is up running
Let's try to do an exercise to create a script do something after box bootup.
## Create a script under /etc/init.d/
## Create a softlink under /etc/rc5.d/
## Verify it after reboot