Linux Server startup process

With the widespread application of Linux, especially in the network applications, there are a large number of network servers using the Linux operating system. Because Linux desktop applications and Windows have a certain gap, so in enterprise applications is often the Linux and Windows operating systems coexist to form a heterogeneous network. Linux and Unix are mostly used on the server side, and Linux is currently adept at application-based server applications such as DNS and DHCP servers, Web servers, directory servers, firewalls, file and print servers, and intranet proxy servers. The process of starting a Linux system involves many stages. Whether you're booting a standard x86 processor or a PowerPC machine, many processes are surprisingly similar. This article describes the entire Linux boot process from boot to login.

(1) from BIOS to kernel

BIOS self-Test

The computer is self-checking by the BIOS after power-on, which is called post (power on
Test), and then read the "boot block" from the hard disk, floppy disk, or CDROM according to the boot order set in the BIOS. In a PC, booting Linux starts at the address 0xffff0 in the BIOS. The first step in the BIOS is a power-on self-test (POST). The job of POST is to detect the hardware. The second step of the BIOS is to enumerate and initialize the local device. Given the different uses of BIOS functionality, the BIOS consists of two parts: the POST code and the runtime service. When the POST is finished, it is cleaned out of memory, but the BIOS runtime service remains in memory and the target operating system can use the services.

To boot an operating system, the BIOS runtime searches for active and bootable devices in the order defined by the CMOS settings. The boot device can be a floppy disk, a CD-ROM, a partition on the hard disk, a device on the network, or even a USB flash. Typically, Linux is booted from the hard disk, where the master boot Record (MBR) contains the primary boot loader. The MBR is a 512-byte sector that is located in the first sector on the disk (0 0 Cylinder 1 sectors). When the MBR is loaded into RAM, the BIOS will give control to the MBR.

Extracting information from MBR

To view the contents of your MBR, use the following command:

# dd If=/dev/hda of=mbr.bin bs=512 count=1 # od-xa Mbr.bin

This DD command needs to run as the root user, which reads the first 512 bytes of content from/dev/hda (the first IDE disk) and writes it to the Mbr.bin file. The OD command prints the contents of this binary file in 16 binary and ASCII format.
(2) Start Grub/lilo

Both grub and Lilo are boot loaders. In the simplest sense, the boot loader boot loader boots the operating system. When the machine boots its operating system, the BIOS reads the first 512 bytes on the boot media (known as the Master boot record,mbr). Only one operating system's boot record can be stored in a single MBR, so there is a problem when more than one operating system is required. Therefore, a more flexible boot loader is required.

The comparison between GRUB and LILO

Ubuntu Forum

• LILO no interactive Command interface, and GRUB has.   

• lilo does not support network booting, and GRUB supports it.   

• lilo The information about the location of the operating system that can be booted is physically stored in the MBR. If you modify the Lilo configuration file, you must rewrite the Lilo first stage boot loader to the MBR. This is a more dangerous option than GRUB, because an incorrectly configured MBR may make the system unable to boot. With grub, if the configuration file is misconfigured, it simply goes to the GRUB command-line interface by default.

Safety tips:

With regard to security, anyone who has access to the boot disk/CD can bypass all of the security measures mentioned in this article by simply using grub.conf or lilo.conf without setting security. In particular, when using GRUB, it is a serious security vulnerability because it is capable of booting into single-user mode. An easy way to solve this problem is to disable booting through CDs and floppy disks in the machine's BIOS and make sure that a password is set for the BIOS so that others cannot modify the settings.
(3) loading the kernel

When the kernel image is loaded into memory, the kernel phase begins. The kernel image is not an executable kernel, but a compressed kernel image. Usually it is a zimage (compressed image, less than 512KB) or a bzimage (larger compressed image, greater than 512KB), which is compressed in advance using zlib. In front of this kernel image is a routine that implements a small set of hardware settings, extracts the kernel contained in the kernel image, and then puts it into high-end memory, and if there is an initial RAM disk image, it is moved into memory and marked for later use. The routine then invokes the kernel and starts the process of booting the kernel.

Manual Boot in GRUB

In the GRUB command line, we can use the INITRD image to boot a specific kernel, as follows:

Grub> kernel/bzimage-2.6.14.2
[Linux-bzimage, setup=0x1400, size=0x29672e]

Grub> initrd/initrd-2.6.14.2.img
[Linux-initrd @ 0x5f13000, 0xcc199 bytes]

grub> Boot

Uncompressing Linux ... Ok, booting the kernel.
If you do not know the name of the kernel to boot, simply use the slash (/) and press the Tab key. GRUB displays a list of kernel and INITRD images.
(4) Executing the init process

The init process is the starting point for all processes in the system, and after the kernel is booted inside, the INIT program is loaded in this thread (process) space, and its process number is 1. The init process is the initiator and controller of all processes. Because it is the first process to run on any UNIX-based system (such as Linux), the Init process's number (process Id,pid) is always 1. If there is a problem with Init, the rest of the system collapses.

The INIT process has two functions. The first function is to play the role of ending the parent process. Because the init process is never terminated, the system can always be sure of its existence and refer to it when necessary. If a process is terminated before the end of all the child processes it derives from, the case must be referenced with Init. At this point, those child processes that have lost the parent process will have Init as their parent process. To quickly execute the PS-AF command, you can list a number of processes that have a parent process id,ppid of 1.

The second role of Init is to manage various run levels by running the appropriate program at a specific runlevel (Runlevel). Its role is defined by the/etc/inittab file.
(5) initialization via/etc/inittab file

Init's job is to execute the appropriate scripts for system initialization based on/etc/inittab, such as setting up keyboards, fonts, loading modules, setting up networks, and so on.

For Redhatlinux, the Order of execution is:

• /etc/rc.d/rc.sysinit # The first script executed by Init
  The/etc/rc.d/rc.sysinit primarily does the same initialization work in each operating mode, including:
  Sets the initial $path variable.
  Configure the network.
  Initiates an interchange for virtual memory.
  Sets the host name of the system.
  Check the root file system for necessary repairs.
  Check the root file system quota.
  Open quotas for users and groups for the root file system.
  Reloads the root file system in read/write mode.
  Clears the mounted File system table/etc/mtab.
  Enter the root file system into the mTAB.
  Prepare the system for loading the module.
  Find the relevant files for the module.
  Check the file system to make the necessary repairs.
  Load all other file systems.
  Clears several/etc files:/etc/mtab,/etc/fastboot, and/etc/nologin.
  Delete the UUCP lock file.
  Delete obsolete subsystem files.
  Delete the outdated PID file.
  Sets the system clock.
  Open the interchange.
  Initializes the serial port.
  Loading the module.

• /etc /rc.d/rcx.d/[ks]
  
  Terminates the service beginning with "K" first, and then starts the service with "S".
  
      For each run level, there is a subordinate directory in the/ETC/RC.D subdirectory. The naming method for the subordinate subdirectories of these runlevel is RCX.D, where x is the number representing the run level. For example, all command scripts running level 3 are stored in the/ETC/RC.D/RC3.D subdirectory. In sub-directories at each runlevel, there are symbolic links to the command scripts in the/ETC/RC.D/INIT.D subdirectory, but these symbolic links do not use the original name of the command script in the/ETC/RC.D/INIT.D subdirectory. If the command script is used to start a service, its symbolic link name begins with the letter S; if the command script is used to close a service, its symbolic link will begin with the letter K. In many cases, the order in which these command scripts are executed is important. If you do not configure the network interface first, there is no way to use the DNS service to resolve the host name! In order to arrange their execution sequence, the letter S or K is followed by a two-digit number, the value is small in front of the large number of execution. For example:/etc/rc.d/rc3.d/s50inet will be executed before/etc/rc.d/rc3.d/s55named. The command scripts stored in the/ETC/RC.D/INIT.D subdirectory, which are symbolic links, are the real doers, and they complete the process of starting or stopping various services. When/ETC/RC.D/RC runs through each specific run-level subdirectory, it invokes each command script execution sequentially, in order of the number. It runs the command script that starts with the letter K, and then runs the command script that begins with the letter S. For a command script that starts with the letter K, the stop parameter is passed, and the start parameter is passed similarly to a command script that begins with the letter S.

• Executive/etc/ec.d/rc.local
  Redhat Linux Operating modes 2, 3, 5 all make/etc/rc.d/rc.local the last one in the init script, so the user can add in this file some commands that need to be executed before the other initialization work. In the days of maintaining the Linux system, it is certain that the system administrator will need to modify the boot or shutdown command scripts. If the changes are only useful when booting the boot, and the changes are not significant, consider simply editing the/etc/rc.d/rc.local script. This command script is executed at the last step of the boot process.

• Execute/bin/login Program
  
  The login program will prompt the user to enter the account number and password, and then code and confirm the correctness of the password, if the two are consistent, the users to initialize the environment, and give control to the shell, that is, waiting for users to log in.
  The Linux boot process has ended many times.

Finally, the author uses Figure 1 to explain the whole process.

Summary: very similar to Linux itself, the boot-boot process for Linux is also very flexible and can support many processor and hardware platforms. The LILO bootloader extends the boot capability, but it lacks the ability to perceive the file system. The latest generation of boot loaders, such as GRUB, will be more flexible.