Sunday, 14 October 2007 19:09

Getting grubby: Demystifying the Linux start-up processes

Linux users can boast long times between reboots, but even so, the startup screens will grace your display at some time. Here’s just what your computer is doing during this process, the several important steps that occur and the order they take place, and how you can take control.
Linux users, almost by definition, like to get their hands dirty, and understand how their computer really works under the hood.  Although it may sound fairly obvious, the boot process actually contains some subtle intricate behaviours and it is helpful to get a handle on them.

The BIOS and the boot loader
No matter what operating system is installed, when a computer is powered up control is first given to the motherboard’s built-in BIOS. The BIOS performs a power-on self test (POST) which assesses if attached devices are functioning normally.

If all is well, the BIOS hands over control to the master boot record (MBR) of the boot device. Different media may be used for booting – like CD/DVD ROMs and USB drives – but most commonly a computer will boot from an internal hard drive.

Linux distros offer several different boot loaders; LILO was once popular, and others now exist which may vary by vendor; Red Hat have implemented GRUB as their only boot loader for example while others use syslinux. IBM offer a comparison between LILO and GRUB, but the significant thing to know is that each Linux variant requires, and offers, a boot loader whatever it may be.

Older PCs need the boot loader to be located within the first 1024 cylinders of the hard disk and necessitates the /boot partition to be in a primary partition. Modern BIOSs support logical block addressing (LBA) which avoids this restriction by letting the BIOS work with much more of the hard drive.

GRUB derives its name from its objective as “The Grand Unified Bootloader”, seeking to serve all your operating system booting needs. GRUB – and any boot loader – is partially stored within the MBR itself. It will list the different operating systems available for booting on your computer – of which there may be just one, or there may be many. Either way, the primary purpose of GRUB is to determine which OS to boot and to then, in daisy chain fashion, pass control on to it.

For Linux operating systems, GRUB will specify the disk partition that should become the root partition, the location of the kernel and the initial RAM disk. These may be listed in /boot/grub/grub.conf like so:

title Red Hat Enterprise Linux
  root (hd0,4)
  kernel /vmlinuz.EL ro root=LABEL=/ rhgb quiet
  initrd /initrd.EL.img

(Other boot loaders will have a similar config file.)

These settings specify this operating system should be displayed in GRUB’s list as “Red Hat Enterprise Linux.” Its /boot directory is located on the fifth partition on the first hard drive (these indexes are 0-based, hence the “4” actually means the fifth partition.)

The kernel is the file vmlinuz.EL which is located within the /boot directory. This is opened as read-only (mode “ro”) to protect from any accidental harm. The actual top-level root directory is associated with the / label, and finally rhgb quiet directs boot messages to be hidden by default. Other directives can be specified here; selinux=0 for instance will disable Security Enhance Linux (SELinux).

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.

A runlevel is not constrained by how it starts up; commands can be run to bring online any required service. You can execute any command or indeed, any of the scripts under /etc/rc.d at any time if so required. The only thing you must be aware of is that a “start” command must be passed in on the command line (e.g. /etc/rc.d/rc5.d/S55cups start to enable printing.)

Other settings in /etc/inittab kickstart virtual consoles, stipulate a command to execute in the event of power failure and other matters.

And, by now, your computer is up and running and waiting for you to tell it what to do. That, in a nutshell, is the complete Linux boot process and the steps which operate in turn and hand off to each other.

Service control
It’s worth spending a bit more time on the /etc/rc.d directories. These really are the key to understanding what Linux is doing when it begins. If you are short on resources, or want to lock down your computer, it’s definitely worth checking out what is starting up by default on boot.

You should look into these folders, but also become familiar with two important relevant Linux commands.

Firstly, chkconfig can be called from a terminal window. It allows services to be added or removed or modified within different runlevels. It will list startup information and also check the state of a particular service (allowing you to see if an expected service is in fact running or not.)

chkconfig works via command-line parameters; chkconfig --list cups will show whether cups is enabled or disabled for each runlevel. You can turn it on or off for any particular runlevel. For instance, to turn cups off for runlevel 4 execute chkconfig --level 4 cups off or chkconfig --level 4 cups on to turn it back on again. In a similar way, you may use the --add and --del switches to install or uninstall services.

Be careful to specify the runlevel; if you do not do so, chkconfig will perform your request over all runlevels. The command chkconfig cups off will disable cups in every runlevel, which may not be your intention. Note that the converse isn’t true; chkconfig cups on will enable cups but only in runlevels 2 through 5. Runlevel 1, single-user mode, isn’t automatically affected (nor are runlevels 0 and 6 which are the two special runlevels, that halt and reboot the system, respectively.)

chkconfig is extremely useful but although having a heritage dating back to certain versions of UNIX, it is largely restricted to Red Hat's Linux distro. A freshmeat project exists to make it available for all other distros.

You may achieve the same results using the ntsysv command. This is still a text-based command (not a GUI program) but it provides a series of prompts, rather than relying solely on command-line parameters.

By default, ntsysv will only work on the current runlevel. You can pass in different runlevels via the --level parameter, e.g. ntsysv --level 3 will let you work on runlevel 3.

Finally, for the more visually-inclined, use System/Administration/Server Settings/Services (or execute system-config-services) to invoke the graphical Service Configuration Tool. This also allows you to modify the services that run upon boot in different runlevels.

Check these tools out; understand just what your computer is doing, and pare down services you don’t require and minimise your potential attack surface at the same time.



Recently iTWire remodelled and relaunched how we approach "Sponsored Content" and this is now referred to as "Promotional News and Content”.

This repositioning of our promotional stories has come about due to customer focus groups and their feedback from PR firms, bloggers and advertising firms.

Your Promotional story will be prominently displayed on the Home Page.

We will also provide you with a second post that will be displayed on every page on the right hand side for at least 6 weeks and also it will appear for 4 weeks in the newsletter every day that goes to 75,000 readers twice daily.




Denodo, the leader in data virtualisation, has announced a debate-style three-part Experts Roundtable Series, with the first event to be hosted in the APAC region.

The round table will feature high-level executives and thought leaders from some of the region’s most influential organisations.

They will debate the latest trends in cloud adoption and technologies altering the data management industry.

The debate will centre on the recently-published Denodo 2020 Global Cloud Survey.

To discover more and register for the event, please click the button below.


David M Williams

David has been computing since 1984 where he instantly gravitated to the family Commodore 64. He completed a Bachelor of Computer Science degree from 1990 to 1992, commencing full-time employment as a systems analyst at the end of that year. David subsequently worked as a UNIX Systems Manager, Asia-Pacific technical specialist for an international software company, Business Analyst, IT Manager, and other roles. David has been the Chief Information Officer for national public companies since 2007, delivering IT knowledge and business acumen, seeking to transform the industries within which he works. David is also involved in the user group community, the Australian Computer Society technical advisory boards, and education.


Webinars & Events