Home Menu

Booting

Contents

The Boot Process

  1. Load and initialize the kernal
  2. Detect and configure devices
  3. Create spontaneous processes
  4. Single user mode (if necessary)
  5. Execute startup scripts
  6. Enter multi-user mode
  7. Run xdm (if necessary)

The Mostly Hidden Part

Bootstrap

Of some interest is how GRUB (or some other boot loader) is involved in this process. GRUB uses a two or three stage process to get from an initial BIOS-loaded program to full Linux operation. This is trickier than it might seem because initially, the BIOS doesn't know anything about the file system and even for GRUB, there are different possible file systems. The stage 1 loader is what is stored in the Master Boot Record of the disk. It loads the stage 1.5 code from the unused sectors in the first cyclinder after the MBR. This code has to be designed to work with a specific file system so that it can find and load the stage 2 loader. The stage 2 loader is loaded into memory (at location 0x8000) and it can find and read the configuration file (menu.lst, grub.conf, or whatever). It does so and displays the boot menu. When a choice is made, it loads the appropriate kernel into memory and Linux is on the way. If you install Grub into the boot sector of a partition, it loads a stage 1 loader which has been patched to find stage 2.

Initialization

Startup Files

A major part of startup is running programs that perform some function and quit or continue running as daemons. These programs are configured and executed in the startup scripts.

Runlevels are simply different modes that the system can run in. A runlevel can be configured to be anything that you want it to be (with some limits) but they generally are defined as:

rc

The rc script has some housekeeping chores, but essentially it boils down to this when executed with rc N, where N is the desired runlevel.
  1. Get a list of all of the files in rcN.d.
  2. Execute all of the files that begin with "K" (for kill) with the command option "stop". This kills all processes that should not be running for that run level. Note that it checks in /var/lock/subsys to see if the process is running, so the process has to write a lock file there as a flag.
  3. Execute all of the files that begin with "S" (for start) with the command option "start". This starts all processes that should be running at this runlevel.
  4. An Example rc File.

For example, if you look at just the sendmail scripts in the various rc.d directories, you see:

rc0.d K30sendmail
rc1.d K30sendmail
rc2.d S80sendmail
rc3.d S80sendmail
rc4.d S80sendmail
rc5.d S80sendmail
rc6.d K30sendmail

So as init brings the system up, it will first initialize by executing rc.sysinit, then it will go through each level to the default runlevel executing rc N starting sendmail if the link name starts with an S.

A reboot will change the system runlevel to 6, which will execute rc 6, which will cause sendmail to be killed.

If you executed telinit 1 on your system, it would immediately go to runlevel 1, which would result in sendmail being killed.

If you look at some listings of rc.d directories, you can see what happens at each level.

Trying to Tie It All Together

System Shutdown

You have already been introduced to the system shutdown command. In more detail:

A shutdown can also be started by entering the ubiquitous CTRL-ALT-DELETE key stroke if configured in /etc/inittab. You probably want to disable this in inittab if your system is physically available to people who are untrustworthy or stupid.

/etc/sysconfig

Red Hat and other Linux companies have begun storing information regarding system configuration in the directory /etc/sysconfig. This directory contains files that give specific details of desired system configuration. This is an improvement over the old system where data was spread all across the system, but there has been no attempt to standardize the organization. Typically, the directory would have the following files and directories: 

   apmd          hwconf               named                samba
   apm-scripts/  i18n                 network              sendmail
   authconfig    init                 networking/          squid
   clock         installinfo          network-scripts/     syslog
   console/      installinfo.rpmsave  ntpd                 tux
   desktop       iptables             pcmcia               xinetd
   gpm           irda                 rawdevices           yppasswdd
   grub          keyboard             redhat-config-users
   grub.rpmsave  kudzu                redhat-logviewer
   harddisks     mouse                rhn/

The files here could have executable scripts, but most have data in them. For example, a typical network file is: 

   NETWORKING=yes
   HOSTNAME=cs25924.cs.montana.edu
   GATEWAY=153.90.199.254

and a typical network-scripts/ifcfg-eth0 file is: 

   DEVICE=eth0
   BOOTPROTO=static
   BROADCAST=153.90.199.255
   IPADDR=153.90.199.125
   NETMASK=255.255.248.0
   NETWORK=153.90.192.0
   ONBOOT=yes

One that is of interest to many users is desktop which consists of one line indicating the desired desktop for running X.

The various configuration tools in Red Hat modify these files so that the changes are included when the system is initialized. If you are manually configuring the system, you will need to modify these files as well. Problematically, Red Hat and others don't document the use of these files as well as they should. Fortunately, it isn't hard to figure out how they are used.

A word of caution. Do not change these files unless you know what you are doing. You could create major problems for you system. However, if you are keeping your log carefully, you should be able to restore things.

Service Management

After the system has booted, you will find via a ps ax command that there are quite a number of processes running on your system. There are several things you might want to do about this:

In order to stop a process from running at runlevels 3 and 5, you need to go to those directories and change some process from Snnxx to Kmmxx so that it is stopped rather than started. The nn and mm values are not the same. Normally, processes that start early should be stopped late and vice versa. If you compare the links in rc3.d with those in rc1.d, you will see that in rc1.d, the network link is K10network and in rc3.d it is S90network. While not uniformly done in this manner, you can generally figure that Snn should become Kmm, where mm is 100 - nn and conversely. If possible, check the other directories to see what Linux uses. Most user added services are S99's.

In order to stop a service temporarily, enter:

where servicename is the name that Linux uses for the service. You may have to list /etc/rc.d/init.d to get the name. If you need to start a service, use:

Some of the scripts support a restart, which is handy when if you change a configuration file and want the daemon to reread the file(s). Then you can use:

or

Recently, some distributions of linux are including a link at /etc/init.d which points to /etc/rc.d/init.d, I assume to make is easier to find the startup scripts. Hopefully that doesn't mean that they are going to then hide them in some obscure place.

Assignment

  1. Modify the initdefault entry in your /etc/inittab to stop at the S runlevel and reboot. You should stop at single user mode, which is pretty handy. Change it back to its orginal value. You can boot from single user mode to level 3 by entering exit or CTRL-D.
  2. While running, change to single user mode with "telinit S" and then change to runlevel 3 from single user mode with "telinit 3".
  3. Pick a process on your system that you are running but don't necssarily need - good choices are the advanced power management daemon (ampd) innd (news), nfs (network file system), smb (samba) or httpd (web server). Change it from running to not running by changing the name from S to K and reboot. Before doing this, run "ps aux" to see if it is running and then after rebooting. It should no longer be in the process table you get from running ps.

    You will probably want to reverse this process when you get done testing.

    If you are booting to XDM, you will have to change the process list in runlevel 5 or in both runlevels 3 and 5.

  4. Change the ca entry in inittab to do something other than a shutdown. For example, create a script named /tmp/block that contains the following:

    Change the permissions on /tmp/block to 755. You will need to run telinit q to get init to reread the inittab file. Finally, you will probably have to be running without X to get this to work as the X managers may modify the keyboard handling. If you're running XDM, you can always get there with telinit 3, right? Although, this means that you may not get to save your current desktop configuration.

Home Menu