You can use the following two files regarding boot logs:
/var/log/boot.log
/var/log/dmesg
On a Ubuntu/Debian, Bootlog is turned off by default. Turn it on like this:
vi /etc/default/bootlogd
# Run bootlogd at startup ?
BOOTLOGD_ENABLE=Yes
Following stages for boot up for an x86 system:
1.System BIOS(Basic Input Output System) checks the system and launches the first stage boot loader on the MBR(Master Boot Record) of the primary hard disk.
2.First stage boot loader loads itself into memory and launches the second stage boot loader from the /boot/ partition.
3.Second stage boot loader loads the kernel into memory, which in turn loads any necessary modules and mounts the root partition read-only.
4.The boot loader often presents the user with a menu of possible boot options. The boot loader can be configured to time out if the user does not interact with the boot loader, thus selecting a default kernel and system configuration. After the selection is made, or after reaching a selection time-out, boot loader loads the kernel, which decompresses itself and sets up system functions such as essential hardware and memory paging, before calling start_kernel().
5.start_kernel() then performs the majority of system setup (interrupts, the rest of memory management, device and driver initialization, etc.) before spawning separately, the idle process and scheduler, and the /sbin/init process (which is executed in user space).
6.The /sbin/init program loads all services and user-space tools, and mounts all partitions listed in /etc/fstab.
7.The user is presented with a login screen for the freshly booted Linux system.
Beginning of boot process is different for different hardware platform .However, once the kernel is found and loaded by the boot loader, the default boot process is identical across all architectures.Here we are focusing on x86 architecture.
Details:
1.The BIOS:
When an x86 computer is booted, the processor looks at the end of system memory for the Basic Input/Output System or BIOS program and runs it. The BIOS controls not only the first step of the boot process, but also provides the lowest level interface to peripheral devices. For this reason it is written into read-only, permanent memory and is always available for use.
Other platforms use different programs to perform low-level tasks roughly equivalent to those of the BIOS on an x86 system. For instance, Itanium-based computers use the Extensible Firmware Interface (EFI) Shell.
Once loaded, the BIOS tests the system, looks for and checks peripherals, and then locates a valid device with which to boot the system. Usually, it checks any diskette drives and CD-ROM drives present for bootable media, then, failing that, looks to the system's hard drives. In most cases, the order of the drives searched while booting is controlled with a setting in the BIOS, and it looks on the master IDE device on the primary IDE bus. The BIOS then loads into memory whatever program is residing in the first sector of this device, called the Master Boot Record or MBR. The MBR is only 512 bytes in size and contains machine code instructions for booting the machine, called a boot loader, along with the partition table. Once the BIOS finds and loads the boot loader program into memory, it yields control of the boot process to it.
2.Boot Loader:
Grub(GNU GRand Unified Bootloader) ,default boot loader for x86 platform.Boot process may differ slightly on the basis of system architecture.
The x86 platform boot loader has at least two stages
a)The first stage is a small machine code binary on the MBR. Its sole job is to locate the second stage boot loader and load the first part of it into memory.
b)Once the second stage boot loader is in memory, it presents the user with a graphical screen showing the different operating systems or kernels it has been configured to boot. On this screen a user can use the arrow keys to choose which operating system or kernel they wish to boot and press Enter.
Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the /boot/ directory. The kernel binary is named using the following format — /boot/vmlinuz-<kernel-version> file (where <kernel-version> corresponds to the kernel version specified in the boot loader's settings).
The boot loader then places one or more appropriate initramfs images into memory. Next, the kernel decompresses these images from memory to /sysroot/, a RAM-based virtual file system, via cpio. The initramfs is used by the kernel to load drivers and modules necessary to boot the system. This is particularly important if SCSI hard drives are present or if the systems use the ext3 file system.
Once the kernel and the initramfs image(s) are loaded into memory, the boot loader hands control of the boot process to the kernel.
Boot Loaders for Other Architectures:
Once the kernel loads and hands off the boot process to the init command, the same sequence of events occurs on every architecture. So the main difference between each architecture's boot process is in the application used to find and load the kernel.
For example, the Itanium architecture uses the ELILO boot loader, the IBM eServer pSeries architecture uses yaboot, and the IBM System z systems use the z/IPL boot loader.
3.The Kernel:
When the kernel is loaded, it immediately initializes and configures the computer's memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed initramfs image(s) in a predetermined location in memory, decompresses it directly to /sysroot/, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID, before completing the initramfs processes and freeing up all the memory the disk image once occupied.
The kernel then creates a root device, mounts the root partition read-only, and frees any unused memory.
At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with the system.
To set up the user environment, the kernel executes the /sbin/init program.
4./sbin/init Program:
When the init command starts, it becomes the parent or grandparent of all of the processes that start up automatically on the system. First, it runs the /etc/rc.d/rc.sysinit script, which sets the environment path, starts swap, checks the file systems, and executes all other steps required for system initialization.
The init command then runs the /etc/inittab script, which describes how the system should be set up in each SysV init runlevel. Runlevels are a state, or mode, defined by the services listed in the SysV /etc/rc.d/rc<x>.d/ directory, where <x> is the number of the runlevel.
ID Name Description
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.
Next, the init command sets the source function library, /etc/rc.d/init.d/functions, for the system, which configures how to start, kill, and determine the PID of a program.
The init program starts all of the background processes by looking in the appropriate rc directory for the runlevel specified as the default in /etc/inittab. The rc directories are numbered to correspond to the runlevel they represent. For instance, /etc/rc.d/rc5.d/ is the directory for runlevel 5.
When booting to runlevel 5, the init program looks in the /etc/rc.d/rc5.d/ directory to determine which processes to start and stop.
Below is an example listing of the /etc/rc.d/rc5.d/ directory:
K05innd -> ../init.d/innd
K05saslauthd -> ../init.d/saslauthd
K10dc_server -> ../init.d/dc_server
.
.
.
K89netplugd -> ../init.d/netplugd
K99microcode_ctl -> ../init.d/microcode_ctl
S04readahead_early -> ../init.d/readahead_early
S05kudzu -> ../init.d/kudzu
S06cpuspeed -> ../init.d/cpuspeed
S08ip6tables -> ../init.d/ip6tables
S08iptables -> ../init.d/iptables
.
.
.
S97messagebus -> ../init.d/messagebus
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local
As illustrated in this listing, none of the scripts that actually start and stop the services are located in the /etc/rc.d/rc5.d/ directory. Rather, all of the files in /etc/rc.d/rc5.d/ are symbolic links pointing to scripts located in the /etc/rc.d/init.d/ directory. Symbolic links are used in each of the rc directories so that the runlevels can be reconfigured by creating, modifying, and deleting the symbolic links without affecting the actual scripts they reference.
The name of each symbolic link begins with either a K or an S. The K links are processes that are killed on that runlevel, while those beginning with an S are started.
The init command first stops all of the K symbolic links in the directory by issuing the /etc/rc.d/init.d/<command> stop command, where <command> is the process to be killed. It then starts all of the S symbolic links by issuing /etc/rc.d/init.d/<command> start.
After the init command has progressed through the appropriate rc directory for the runlevel, the /etc/inittab script forks an /sbin/mingetty process for each virtual console (login prompt) allocated to the runlevel. Runlevels 2 through 5 have all six virtual consoles, while runlevel 1 (single user mode) has one, and runlevels 0 and 6 have none. The /sbin/mingetty process opens communication pathways to tty devices, sets their modes, prints the login prompt, accepts the user's username and password, and initiates the login process.
In runlevel 5, the /etc/inittab runs a script called /etc/X11/prefdm. The prefdm script executes the preferred X display manager — gdm, kdm, or xdm, depending on the contents of the /etc/sysconfig/desktop file.
Once finished, the system operates on runlevel 5 and displays a login screen.
Running Additional Programs at Boot Time:
The /etc/rc.d/rc.local script is executed by the init command at boot time or when changing runlevels. Adding commands to the bottom of this script is an easy way to perform necessary tasks like starting special services or initialize devices without writing complex initialization scripts in the /etc/rc.d/init.d/ directory and creating symbolic links.
The /etc/rc.serial script is used if serial ports must be setup at boot time. This script runs setserial commands to configure the system's serial ports. Refer to the setserial man page for more information.
SysV Init Runlevels details:
The SysV init runlevel system provides a standard process for controlling which programs init launches or halts when initializing a runlevel. SysV init was chosen because it is easier to use and more flexible than the traditional BSD-style init process.
The configuration files for SysV init are located in the /etc/rc.d/ directory. Within this directory, are the rc, rc.local, rc.sysinit, and, optionally, the rc.serial scripts as well as the following directories:
init.d/ rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/
The init.d/ directory contains the scripts used by the /sbin/init command when controlling services. Each of the numbered directories represent the six runlevels configured by default under Red Hat Enterprise Linux.
Runlevels:
The idea behind SysV init runlevels revolves around the idea that different systems can be used in different ways. For example, a server runs more efficiently without the drag on system resources created by the X Window System. Or there may be times when a system administrator may need to operate the system at a lower runlevel to perform diagnostic tasks, like fixing disk corruption in
runlevel 1.
The characteristics of a given runlevel determine which services are halted and started by init. For instance, runlevel 1 (single user mode) halts any network services, while runlevel 3 starts these services. By assigning specific services to be halted or started on a given runlevel, init can quickly change the mode of the machine without the user manually stopping and starting services.
The following runlevels are defined by default under Fedora/Red Hat Enterprise Linux:
0 — Halt
1 — Single-user text mode
2 — Not used (user-definable)
3 — Full multi-user text mode
4 — Not used (user-definable)
5 — Full multi-user graphical mode (with an X-based login screen)
6 — Reboot
In general, users operate Red Hat Enterprise Linux at runlevel 3 or runlevel 5 — both full multi-user modes. Users sometimes customize runlevels 2 and 4 to meet specific needs, since they are not used.
The default runlevel for the system is listed in /etc/inittab. To find out the default runlevel for a system, look for the line similar to the following near the top of /etc/inittab:
id:5:initdefault:
The default runlevel listed in this example is five, as the number after the first colon indicates. To change it, edit /etc/inittab as root.
It is possible to change the default runlevel at boot time by modifying the arguments passed by the boot loader to the kernel.
Note:Be very careful when editing /etc/inittab. Simple typos can cause the system to become unbootable. If this happens, either use a boot diskette, enter single-user mode, or enter rescue mode to boot the computer and repair the file.
Runlevel Utilities:
One of the best ways to configure runlevels is to use an initscript utility. These tools are designed to simplify the task of maintaining files in the SysV init directory hierarchy and relieves system administrators from having to directly manipulate the numerous symbolic links in the subdirectories of /etc/rc.d/.
Red Hat Enterprise Linux provides three such utilities:
/sbin/chkconfig — The /sbin/chkconfig utility is a simple command line tool for maintaining the /etc/rc.d/init.d/ directory hierarchy.
/usr/sbin/ntsysv — The ncurses-based /sbin/ntsysv utility provides an interactive text-based interface, which some find easier to use than chkconfig.
Services Configuration Tool — The graphical Services Configuration Tool (system-config-services) program is a flexible utility for configuring runlevels.
Shutting Down:
To shut down Red Hat Enterprise Linux, the root user may issue the /sbin/shutdown command. The shutdown man page has a complete list of options, but the two most common uses are:
/sbin/shutdown -h now
and
/sbin/shutdown -r now
After shutting everything down, the -h option halts the machine, and the -r option reboots.
PAM(Pluggable Authentication Modules) - CentOS console users can use the reboot and halt commands to shut down the system while in runlevels 1 through 5.
If the computer does not power itself down, be careful not to turn off the computer until a message appears indicating that the system is halted.
Failure to wait for this message can mean that not all the hard drive partitions are unmounted, which can lead to file system corruption.
References:
https://access.redhat.com/site/documentation/en-US/
wikipedia
No comments:
Post a Comment