How Linux Boots
The hardware is powered up, a POST (Power-On Self-Test) occurs, and the initial boot loader takes over:
The system MBR should contain the Linux boot loader:
That boot loader is loaded into RAM and started, and it takes control of the system. Both GRUB and aboot are able to understand the Linux file systems; LILO must do everything in terms of physical addresses.
The boot loader may present the user with a choice of bootable operating systems, and it may time out and boot a default one.
On a PC, something called Xen may be loaded by the boot loader.
Xen is a hypervisor, it is a relatively lightweight piece of software that arbitrates access to the hardware for operating systems running on that platform.
If Xen is booted via GRUB on a PC (and that's the only situation in which you're likely to find it), it will be passed the Linux kernel and other parameters for booting what's called the Domain0 or Dom0 operating system on that platform.
The boot loader uncompresses and loads the kernel image into RAM:
The kernel is started and it takes over.
The kernel almost certainly will have been passed an
initial RAM disk image (usually called "initrd") by
the boot loader.
This is needed to provide needed device-special files
/dev, as devices are now dymanically created
udev daemon which is only started during
the middle of the boot sequence.
/dev will be an empty mount point, missing the needed
and other devices.
The initrd may also contain some needed device drivers (e.g., for SCSI controller or SATA chipsets)
The initrd is uncompressed into RAM and mounted temporarily
as the root of the filesystem (/).
Then the file
/linuxrc is run, possibly loading
those device drivers.
The monolithic kernel (possibly plus some loadable modules loaded from the initrd) discovers the hardware.
Hardware discovery is a fairly black art. The individual components of the kernel (meaning the kernel image in RAM, which is monolithic kernel plus all currently loaded modules) try to detect their specific hardware (if any).
This might be done by trying to read from a specific hardware address, and interpreting any data read. It might include actively probing — writing some patterns into specific hardware addresses, and seeing what happens.
Of course, some kernel components (a.k.a. "drivers") are software-only, like the ability to run TCP/IP, or interpret specific file system formats.
When a kernel component successfully loads (for a module) and/or finds its hardware, it prints something that you will hope might be of use. This output is captured in the "kernel ring buffer" and simultaneously printed onto the console.
The kernel ring buffer contents can be viewed
after the system is up and running
with the command
The kernel was passed information by the boot loader about
which partition to mount as "/".
If you are very curious about details,
this is passed as "major, minor" device numbers.
For traces of this, try this command after your system
is up and running:
The initrd is unmounted and the real root filesystem is mounted in read-only mode as "/". More hardware may be discovered as this happens.
init process reads its configuration files
for several pieces of information.
With the classic
/etc/inittab contains this information.
sysinitprocess? The answer is probably
/etc/inittab file probably resembles:
# The default run level id:3:initdefault # System initialization si::sysinit:/etc/rc.d/rc.sysinit # Do the SYSV stuff [....] l3:3:/etc/rc.d/rc 3 [....] # Run gettys 1:12345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 [....]
However, things work a little differently
if your Linux system uses the
"Upstart" version of
This will be the case if your Linux is based on a
Debian or Ubuntu distribution, or RHEL/CentOS 6 and later.
Instead of a single file
init program is configured by a collection
of files in the directory
Basically, each Upstart file in
plays the role of one line from the traditional file
The kernel starts
/sbin/init because that is
what it is programmed to do — at least by default.
This is why you can break into a Linux system by
passing the following argument from the boot loader:
init doesn't run,
/etc/rc.d/rc.sysinit doesn't run,
and the system will be in a somewhat odd state.
You would need to do the following to do what you want
and not cause far worse problems,
but at least you are in:
# mount /proc
/etc/mtabfrom before the previous shutdown.
# mount -o remount,rw /
Given the above, your
fsckon "/" if it wasn't cleanly unmounted the last time, and so it might be corrupted.
fsckon the other file systems as needed, then mount them as per
dmesg > /var/log/dmesg
modprobeto support oddities like filesystems on USB devices, or exotic (meaning non-ext2/ext3) filesystems.
/etc/rc.d/rc 3. The script
/etc/rc.d/rcN.d, where "N" is replaced with its argument ("3" in this case).
/etc/rc.d/rc?.d/*are symbolic links pointing to the real boot scripts in
/etc/rc.d/init.d/*(In Solaris, these are hard links).
rcdoes the main work, at least the work specific to different run states. But our
initwill continue to run some instances of
/sbin/mgettyto start the login processes on the virtual consoles.
At this point, the system is up and running!
The Bootchart project has a tool that gathers information and creates charts of process and timing information. It seems like it's mainly being used by people trying to speed the boot process, but it might help you answer your questions or otherwise investigate the booting process: http://www.bootchart.org/"