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 in /dev, as devices are now dymanically created by the udev daemon which is only started during the middle of the boot sequence. /dev will be an empty mount point, missing the needed stdin, stdout, stderr, null, random, 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 dmesg.
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: cat /proc/cmdline
The initrd is unmounted and the real root filesystem is mounted in read-only mode as "/". More hardware may be discovered as this happens.
The init process reads its configuration files for several pieces of information. With the classic init program, /etc/inittab contains this information.
Your /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 init. 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 /etc/inittab, the init program is configured by a collection of files in the directory /etc/event.d/. Basically, each Upstart file in /etc/event.d/ plays the role of one line from the traditional file /etc/inittab.
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:
Since 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:
Given the above, your init would:
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/"