The Linux startup process is the process of Linux-operating system initialization. It is in many ways similar to the BSD and other Unix style boot processes, from which it derives.
Contents |
In Linux, the flow of control during a boot is from BIOS, to boot loader, to kernel. The kernel then starts the scheduler (to allow multi-tasking) and runs first userland (i.e. outside kernel space) program Init (which sets up the user environment and allows user interaction and login), at which point the kernel goes idle unless called externally.
In detail:
Wikis
Quiz
Search
start_kernel().start_kernel() then performs the majority of
system setup (interrupts, the rest of memory management, device
initialization, drivers, etc) before spawning separately, the idle
process and scheduler, and the Init process (which is
executed in user space).On shutdown, Init is called to close down all user space functionality in a controlled manner, again via scripted directions, following which Init terminates and the Kernel executes its own shutdown.
The boot loader phase varies by platform. Since the earlier phases are not specific to the OS, the boot process is considered to start:
From that point, the boot process continues as follows:
The first stage BOOT Loader loads the remainder of the boot
loader, which typically gives a prompt asking which operating
system (or type of session) the user wishes to initialize.
Under LILO, this is done via the map installer which reads the
configuration file /etc/lilo.conf to identify the
available systems. It includes data such as boot partition
and kernel
location for each, as well as customized options if any. Upon
selection, the appropriate operating system is loaded into RAM memory as an image file ("initrd"), and along with the
appropriate parameters, control is passed to it.
LILO and GRUB differ in some ways:[1]
GRUB supports both direct and chain-loading boot methods, LBA, ext2, and "a true command-based, pre-OS environment on x86 machines". It contains three interfaces: a selection menu, a configuration editor, and a command line console. The new Grub version 2, has support for ext4 file system.
LILO, the older of the two boot loaders, is almost identical to GRUB in process, except that it does not contain a command line interface. Thus all changes must be made to its configuration and written to the MBR, and then the system restarted. An error in configuration can therefore leave a disk unable to be booted without use of a separate boot device (floppy disk etc) containing a program capable of fixing this.[3] Additionally it does not understand file systems, instead locations of image files are stored within the MBR directly[3] and the BIOS is used to access them directly.
Yet another way to boot Linux is from DOS or Windows 9x, where the Linux kernel
completely replaces the running copy of this operating system. This
can be useful in the case of hardware which needs to be switched on
via software and for which such configuration programs are only
available for DOS, whereas not for Linux, those being proprietary
to the manufacturer and kept an industry secret. This tedious
booting method is less necessary nowadays, as Linux has drivers for
a multitude of hardware devices, but it used to be helpful in the
past.
Another case is when the Linux is located on a storage device which
is not available to the BIOS for booting: DOS or Windows can load
the appropriate drivers to make up for the BIOS limitation, and
boot Linux from there.
The kernel in Linux handles all operating system processes, such as memory management, task scheduling, I/O, interprocess communication, and overall system control. This is loaded in two stages - in the first stage the kernel (as a compressed image file) is loaded into memory and decompressed, and a few fundamentals such as basic memory management are set up. Control is then switched one final time to the main kernel start process. Once the kernel is fully operational – and as part of its startup, upon being loaded and executing – the kernel looks for an init process to run, which (separately) sets up a user space and the processes needed for a user environment and ultimate login. The kernel itself is then allowed to go idle, subject to calls from other processes.
The kernel as loaded is typically an image file, compressed into
either zImage or bzImage formats with zlib. It contains a header program
which does a minimal amount of hardware setup, decompresses the
image fully into high
memory, taking note of any RAM disk if configured.[4]
It then executes kernel startup via
./arch/i386/boot/head and the startup_32
() (for x86 based processors) process.
The startup function for the kernel (also called the swapper or
process 0) establishes memory management (paging tables and
memory paging), detects the type of CPU and any additional
functionality such as floating point capabilities, and then
switches to non-architecture specific Linux kernel functionality
via a call to start_kernel ().
start_kernel executes a wide range of initialization functions.
It sets up interrupt handling (IRQs), further configures
memory, starts the Init process (the first user-space process), and
then starts the idle task via cpu_idle (). Notably,
the kernel startup process also mounts the initial RAM disk ("initrd") that was loaded
previously as the temporary root filing system during the boot
phase. This allows driver modules to be loaded without reliance
upon other physical devices and drivers, and keeps the kernel
smaller. The root file system is later switched via a call to
pivot_root () which unmounts the temporary root file
system and replaces it with the use of the real one, once the
latter is accessible. The memory used by the temporary root file
system is then reclaimed.
Thus, the kernel initializes devices, mounts the root filesystem
specified by the boot loader as read only, and runs Init (/sbin/init) which is
designated as the first process run by the system (PID =
1).[1]
A message is printed by the kernel upon mounting the file system,
and by Init upon starting the Init process. It may also optionally
run Initrd to allow setup and
device related matters (RAM
disk or similar) to be handled before the root file system is
mounted.[1]
According to Red Hat, the detailed kernel process at this stage is therefore summarized as follows: [2]
At this point, with interrupts enabled, the scheduler can take control of the overall management of the system, to provide pre-emptive multi-tasking, and the init process is left to continue booting the user environment in user space.
"Init is the father of all processes. Its primary role is to
create processes from a script stored in the file
/etc/inittab. This file usually has entries which
cause init to spawn gettys on each line that users can log in.
It also controls autonomous processes required by any particular
system. A run level is a software configuration of the system which
allows only a selected group of processes to exist. The processes
spawned by init for each of these run levels are defined in the
/etc/inittab file. |
| – manual page for Init[5] |
Init's job is "to get everything running the way it should be"
[6]
once the kernel is fully running. Essentially it establishes and
operates the entire user
space. This includes checking and mounting file systems, starting
up necessary user services, and ultimately switching to a
user-environment when system startup is completed. It is similar to
the Unix and BSD init processes, from which
it derived, but in some cases has diverged or became customized. In
a standard Linux system, Init is executed with a parameter, known
as a runlevel, that takes
a value from 1 to 6, and that determines which subsystems are to be
made operational. Each runlevel has its own scripts which codify the various processes
involved in setting up or leaving the given runlevel, and it is
these scripts which are referenced as necessary in the boot
process. Init scripts are typically held in directories with names
such as "/etc/rc...". The top level configuration file
for init is at /etc/inittab.[6]
During system boot, it checks whether a default runlevel is specified in /etc/inittab, and requests the runlevel to enter via the system console if not. It then proceeds to run all the relevant boot scripts for the given runlevel, including loading modules, checking the integrity of the root file system (which was mounted read-only) and then remounting it for full read-write access, and sets up the network.[1]
In detail, according to Red Hat, the init process follows the following steps:[2]
swap, checks the file
systems, and takes care of everything the system needs to have done
at system initialization." This includes the system and hardware
clock, special serial port processes, and the like.After it has spawned all of the processes specified, init goes
dormant, and waits for one of three events to happen:- processes it
started to end or die, a power failure signal, or a request via
/sbin/telinit to further change the runlevel.[5]
This applies to SysV-style init binaries. Other init binaries may behave differently.
|
|||||||||||||||||||||||||||||||
   | Greg O'Keefe - From Power Up To Bash Prompt - From Power Up To Bash Prompt |
| | IBM description of Linux boot process - Inside the Linux boot process |
|
|
