Fedora Boot Order

http://hi.baidu.com/wwwkljoel/item/29620217882a585b2b3e2244

The start of the Fedora

When the Fedora system is power-on or reset, the central processing unit will clear all data in memory and verify the memory. If there are no errors, then the CS (Code Segment) registers all 1, while the IP (instruction pointer) registers all 0. The instruction stored in the [CS]:[IP] address cell is a jump instruction that jumps to the header of the BIOS code. The CPU is based on the value of CS and IP into the BIOS boot process. I. bios¶ when the microcomputer is connected to the power, the system will have a process of checking the internal devices, which is done by a program commonly called post (Power On Self test, power-on self-test). This is also a function of the BIOS. BIOS System Setup program The computer component configuration is placed in a read-write CMOS RAM chip, BIOS ROM will be in the system CMOS settings in the boot sequence to search for soft hard drive and CDROM, network server and other effective boot drive, read into the operating system boot record, Then the system control is given to the boot record, and the boot record completes the system startup. So sometimes starting the machine does not come up, the sound card decompression card display card conflict; CD-ROM is not up; some programs that run well under DOS and Windows 3.x may be closely related to the BIOS.

About BIOS
Note: Top two, boot Loader¶bios will record the available device search order. So, the system will start to read the first boot device on top of the boot program. The first thing to read is the main boot zone (master boot record, MBR) of the hard drive, and the system can start the core program with the boot boot (boot loader) installed in the main boot zone. * Simply put, the Boot Loader is a small program that runs before the operating system kernel runs. Through this small program, we can initialize the hardware device, the mapping of memory space, so that the system's hardware and software environment to a suitable state, so that the final call to the operating system kernel to prepare the correct environment.

Typically, the Boot Loader is heavily dependent on hardware, especially in the embedded world. Therefore, it is almost impossible to build a generic Boot Loader in the embedded world. But they still have some commonality. How can I execute the boot loader first? When the system is power-on or reset, all CPUs are typically taken from a predetermined address of the CPU manufacturer to take its first instruction (BIOS). Embedded systems based on CPUs typically have certain types of solid-state storage devices (such as ROM, EEPROM, or FLASH) that are mapped to this prearranged address. The BIOS will adjust the MBR boot loader to the memory 0x07c00, check 0x0000:7def is equal to 0xaa55, if not equal to try other boot media, if no other boot media on the display "No ROM BASIC", and then panic. The CPU reads the memory 0X07C00 code, executes. So after the system is power on, the CPU will perform the boot Loader program. The first sector of the 0 track of the hard disk is called the MBR (Master Boot Recorder), which is 512 bytes in size. The boot loader is usually a piece of assembly code, stored in the MBR, to read the system boot code into memory, and the current mainstream boot loader has grub, Lilo, and Spfdisk.

The next thing the system needs to do is to follow the code that is started step by step. For Linux source code the starting code flow is shown in Figure 1: BOOTSECT.S is used to load core systems and SETUP.S. Setup. S is the program code written in assembly language. SETUP.S the memory kernel code has been checked, if there is no error, it will be interrupted through the BIOS to obtain memory capacity information, set the basic display mode, get hard disk information, these operations are in the X86 real mode, when the operating system is ready to let the CPU into the protection mode. Enter the boot phase of the protection mode while handing control over to head. S,head. S is the assembly procedure for segment protection mode. Head.s, after the page table is initialized and the CPU type is checked, the Start_kernel () in/INIT/MAIN.C is invoked. Start_kernel () is used to initialize the most basic hardware-related parts of the processor, memory, and interrupt-related initialization, and to initialize the Linux file system. The kernel image is generally compressed, and the compressed kernel image is like a chunk of data, stitched together with the boot sector and the boot helper's image, to become the kernel's "boot image." After the uncompressed kernel image is always placed where the address is 0x100000 (1MB). After the Linux core is loaded, the INIT process initializes hardware and device drivers and then runs the init process in the background. The init process is the first process in the system, and the Init process runs with two important system boot configuration files/etc/inittab and/ETC/RC.D.

About the boot loader
Note: Top three, initrd¶ why to separate INITRD take out as a separate step. Hehe, because INITRD is very important, without this or a bit of error can not start the file system in the above process will use the boot loader to load initrd, with INITRD to make virtual hard disk (RAM Disk) and uses the LINUXRC program to carry out the module loading. The main feature of the LINUXRC is that it must be the filename of the LINUXRC, the topmost directory of the virtual disk set up in INITRD, which must be performed by the core. INITRD (boot loader initialized RAM disk) the boot loader loads INITRD files from the storage media into memory before the Linux kernel starts, and the kernel starts by accessing the Init in memory before accessing the real root file system Rd file System. When the boot loader is configured with INITRD, the kernel boot is divided into two stages, the first stage executes the INITRD file system "a file", completes the load drive module and so on the task, the second phase will execute the real root file system/sbin/init process.
Version 2.4 of the INITRD and 2.6 version of the INITRD is not the same: in order to enable readers to clearly understand the Linux2.6 kernel initrd mechanism changes, in the focus on Linux2.6 kernel initrd before the linux2.4 kernel of the INITRD a simple introduction. The INITRD format for the Linux2.4 kernel is the file system mirroring file, which this article calls IMAGE-INITRD to distinguish cpio from the INITRD format of the linux2.6 kernel described later. The processing flow of the linux2.4 kernel to INITRD is as follows: 1. The boot loader loads the kernel and/DEV/INITRD content into memory,/DEV/INITRD is a device initialized by the boot loader, which stores initrd. 2. During kernel initialization, the kernel/dev/initrd the contents of the device and copies it to the/DEV/RAM0 device. 3. The kernel mounts the/DEV/RAM0 device as the original root file system in a readable and writable manner. 4. If/DEV/RAM0 is designated as the real root file system, then the kernel jumps to the last step to start normally. 5. Execute the/LINUXRC file on the INITRD, LINUXRC is usually a script file that is responsible for loading the kernel to access the drive required by the root file system and loading the root file system. 6./LINUXRC execution completed, the real root file system was mounted. 7. If the real root file system exists in the/INITRD directory, then/DEV/RAM0 will move from/to/INITRD. Otherwise, if the/INITRD directory does not exist,/DEV/RAM0 will be uninstalled. 8. Perform the normal boot process on the real root file system and execute the/sbin/init. The initrd execution of the linux2.4 kernel is an intermediate phase of the kernel boot, that is, after INITRD/LINUXRC executes, the kernel will continue to execute the initialization code, and we will see later that this is the linux2.4 process of the INITRD kernel and the 2.6 kernel. A significant difference. The Linux2.6 kernel supports the INITRD of the two formats in the INITRD process linux2.6 kernel, one of which is the traditional format of file system mirroring linux2.4, which is described in the 3rd part of the previous section, which is made in the same way as-IMAGE-INITRD Kernel of the INITRD, its core file is/LINUXRC. Another form of INITRD is the cpio format, and this latticeThe INITRD is introduced from linux2.5, and the Cpio tool is used to generate the core file, which is no longer/linuxrc, but/init, this initrd is called CPIO-INITRD. Although the linux2.6 kernel supports both CPIO-INITRD and IMAGE-INITRD INITRD, there are significant differences in their processing processes, and the linux2.6 kernel's process for both initrd is described below. The processing process of CPIO-INITRD 1. The boot loader loads the kernel and initrd files into a specific location in memory. 2. The kernel determines the INITRD file format, if it is a cpio format. 3. Releases the contents of the INITRD into Rootfs. 4. Execute the/init file in Initrd, execute to this point, the kernel work is complete, completely handing over to/init file. The processing process of IMAGE-INITRD 1. The boot loader loads the kernel and initrd files into a specific location in memory. 2. The kernel determines the INITRD file format and, if not the cpio format, handles it as a image-initrd. 3. The kernel stores the contents of the INITRD in the/initrd.image file under Rootfs. 4. The kernel reads the/initrd.image content into the/DEV/RAM0 device, which is read into a memory disk. 5. The kernel then mounts the/DEV/RAM0 device as the original root file system in a readable and writable manner. 6. If/DEV/RAM0 is designated as the real root file system, then the kernel jumps to the last step to start normally. 7. Execute the/LINUXRC file on INITRD, LINUXRC is usually a script file that loads the kernel to access the root file system must drive and load the root file system. 8. /LINUXRC execution completed, the regular root file system is mounted 9. If the regular root file system exists in the/INITRD directory, then/DEV/RAM0 will move from/to/INITRD. Otherwise, if the/INITRD directory does not exist,/DEV/RAM0 will be uninstalled. 10. Performs the normal boot process on the regular root file system, executing the/sbin/init. Through the above process, it can be seen that the Linux2.6 kernel has no significant changes to the IMAGE-INITRD process flow compared with the linux2.4 kernel, and CPIO-INITRD processing process is quite different from the IMAGE-INITRD process. The process is very simple, in the back of the source code analysis, the reader can appreciate the simplicity of processing. For a simple example

More references on INITRD and LINUXRC
Note: Top four, Init¶1.init will run different run level according to the profile, the profile is/etc/inittab, and depending on the run level, different services will be started at boot time.
The format in the Inittab is this:
Id:runlevels:action:process The following table: ID is a unique sequence of 1-4 characters which identifies the entry in Inittab (for vers Ions of Sysvinit compiled with libraries < 5.2.18 or a.out libraries The limit is 2 characters). Note:for Gettys or other login processes, the ID field should is the TTY suffix of the corresponding TTY, e.g. 1 for tty1 . Otherwise, the login accounting might not work correctly. Runlevels lists the runlevels for which the specified action should to be taken. Action "describes which action should be taken. Valid Actions for the Action field are: "respawn the process would be restarted whenever it terminates (e.g. Getty). The process would be started once the specified RunLevel is entered and init'll wait for its termination. Once the process would be executed once the specified RunLevel is entered. The boot process would be executed during system boot. The Runlevels field is ignored. Bootwait the process would 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 A OnDemand RunLevel'll be executed whenever the specified OnDemand RunLevel-is called. However, no runlevel change would occur (OnDemand runlevels are  a ',  B ', and ' C '). Initdefault An Initdefault entry specifies the runlevel which is should after system boot. If none exists, Init'll ask for a runlevel on the console. The process field is ignored. Sysinit the process would be executed during system boot. It is executed before any boot or bootwait entries. The Runlevels field is ignored. Powerwait the process would be executed when Init receives the SIGPWR signal, indicating so there is something wrong with The power. Init would wait for the process to finish before continuing. Powerfail as for powerwait, except which Init does not wait for the process ' s completion. Powerokwait the process would be executed when Init receives the SIGPWR siGnal, provided there is a file called/etc/powerstatus containing the word OK. This means is has come back again. Ctrlaltdel the process would be executed when Init receives the SIGINT signal. This means is 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 would be executed as Init receives a signal from the keyboard of that a handler key special n is pressed on the console keyboard. The documentation for this function is not complete yet; More documentation can is found in the kbdx.xx packages (most recent is kbd-0.94 at the "time" of this writing). Basically you want to map some keyboard combination to the "keyboardsignal?" action. For example, to map alt-uparrow for this purpose use the following in your keymaps, File:alt keycode 103=? &NBSP;PROCESS Specifies the process to be executed. If The Process field starts with a ' + ' character, Init won't do utmp and wtmp accounting the for that process. This is needed to gettys that insist on doing their own utmp/wtmp. This is also a historic bug.

There are several run level:

# 0-Downtime (never set the Initdefault to 0)

# 1-Single user mode

# 2-Multiuser, no NFS

# 3-Full multiuser mode (standard run level)

# 4-Preset retention

# 5-x11 (Xwindow)

# 6-Reboot (don't set the Initdefault to 6)

Commonly used in the 3 and 5 mode, where 3 is the text mode, contains network features, 2 mode less than 3 network functions, 5 is desktop mode, but also the most commonly used, and Windows desktop mode is much like, if accustomed to Windows users, it is recommended to use this mode.

When Init starts, it looks for a line of code within the/etc/inittab, which specifies the default run level:

Id:5: Initdefault: This line indicates that startup 5 mode is by default

According to the data set in the Inittab, the corresponding service will be started, and the first service to be run is the file placed in the/ETC/RC.D directory. In most Linux distributions, startup scripts are located in/etc/rc.d/init.d. These scripts are connected to the/ETC/RC.D/RC*.D directory using the ln command. (Here's * is run level 0-6)

The specific contents of the Inittab can be found in the relevant information, do not explain here 2. Next Init executes the/etc/rc.d/rc.sysinit file, this file is mainly for us to set the system environment, such as environment variables, set the system time, set the terminal style, Clear the boot process of the temporary archive, load modules, etc., do a lot of things.

3. Service, is generally placed under the/etc/init.d/, there are also placed in the/ETC/XINETD.D, placed in these two directories down the difference is that under the/etc/init.d/is always in memory, that is, boot on the start, in the/etc/xinet.d/ Under the use of the time before the start, its profile for/etc/xinetd.conf. Now to understand the service under the/etc/init.d/, here is saved all the boot service, no matter what mode, in each mode boot service is not the same, such as 5 mode, we will go to/etc/rc.d/rc5.d/view, The names of the scripts inside are all kind of weird, all K (S) **name, does not apply to the beginning of K is to start with S, with the beginning of the start of the service, K is the beginning of the start of the service is not started, followed by two digits, on the boot when the order of service execution, with nice value a bit like, are Is the smaller the more the first to be executed. Why start with S is to be executed, the service beginning with K will not be started. In Inittab there is a similar sentence L5:5:WAIT:/ETC/RC.D/RC 5 of course there are a few similar to it, above this sentence in 5 mode execution: "/ETC/RC.D/RC 5" Such an order, There are two for loops in the script RC that indicate the service to start with S, and to turn off the service starting with K, since the login interface has not been started, the service that just started becomes the boot service. RC contents can refer to their own. If you want to boot up the customization program, you can modify the/etc/rc.d/rc.local, because this is the shell login interface before the start of the final execution of the script. So even if you start to forget which script to shut down a program so that it doesn't run at boot time, you can write it here because it's the last thing to do. If you write a program yourself and want to boot it like a/etc/rc.d/rc.d/service, you can use the Chkconfig command. You can also use man chkconfig to refer to the most important point of use, such as you write a script Liuwenhan, which format like the following format
#!/bin/bash
# CHKCONFIG:35 80 70
#接下来就是写你所需要的内容 Note that the second line above is important and must be written in the format above, with at least one spacebar between # and Chkconfig, and to put the written script under/etc/init.d/, this line represents only starting the program in 3 and 5 mode. And under/etc/rc.d/rc3.d/and/etc/rc.d/rc5.d/the name is S80liuwenhan. In other directories for K70liuwenhan How to add chkconfig, delete the custom program, please refer to man chkconfig or info chkconfig 4. Start the login interface, enter the username and password login.

to find out about specific services, you can refer to service