Getting grubby: Demystifying the Linux start-up processes

by David M Williams

Monday, 15 October 2007

Page 2 of 3 The initial RAM disk creates a temporary filesystem in computer memory and pre-populates its contents with the data in file initrd.EL.img, also located within /boot. The point of the RAM disk is to load important kernel modules and and programs so they can be used to mount actual disk-based filesystems and run the first initialisation programs. The boot loader hands over responsibility to the selected kernel. Unless quiet was directed as a configuration item like above, arcane messages will fly past on the screen. This is what will be the first introduction to Linux that many people see. These messages contain a load of useful information and can be reviewed after logging in by viewing /var/log/dmesg or running the dmesg command. They explain precisely what the Linux kernel is up to and give significant clues to troubleshooting any hardware or service problems. Important messages include the kernel version, the amount of RAM and the number of CPUs detected, hard drives and partitions which have been found, network cards that have been found, and the active and swap filesystems loaded. If you are having hardware compatibility problems, one very important first step is to consult these boot-time messages to check if any errors were displayed and if your hardware item was actually detected and a driver loaded. While it is possible to compile drivers into the kernel, most all contemporary kernels are modular so that only required drivers are loaded into memory. Not all drivers are hardware-related; the ext3 filesystem is a software-based module. You can inspect the modules loaded via the command lsmod. Processing begins; runlevels run Finally, with all this loading complete, Linux is now able to kick off process number one. This is always a process known as init (or upstart in Ubuntu and experimental versions of Debian), which varies its behaviour based on parameters specified in /etc/inittab. init does two major things. Firstly, it fires off /etc/rc.d/rc.sysinit which configures the network, sets the system clock, mounts partitions and performs many other things. Secondly, though, init determines which runlevel it should be in. A runlevel is merely a group of activities, bound together by a numbered runlevel. For each runlevel, there are a series of scripts to start specific processes which may be more or less than other runlevels. This allows the system to have a set of very distinct operating environments – in contrast to Microsoft Windows’ mere pair of safe and normal modes. A directive initdefault in /etc/inittab indicates the default runlevel, which is either runlevel 3 or 5, and which are the two most functional. Runlevel 3 provides multiuser services with full networking. Runlevel 5 is similar but with GUI services instead of a purely text console mode. (Runlevel 0 halts the system; runlevel 1 provides a single-user environment that is mostly used for maintenance tasks; runlevel 2 offers a multi-user environment with some basic networking functionality; and runlevel 4 is unused. Runlevel 6 also exists, which reboots the system.) The scripts which make runlevels work are stored under /etc/rc.d, in their own numbered subdirectory. Each script whose name begins with a K is executed, to stop (or kill) existing processes, and each script whose name begins with S is executed, to start new processes. << First page <   1 2 3 Next page > Last page - Post your comment >>

 

< Next story in category		Previous story in the category >

Visitors last 30 days Suscribers

904,266 13,751