Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Linux Startup and Shutdown

News

Recommended Books

 Recommended Links Grub Runlevels /etc/inittab Xinetd
service chkconfig Booting into Rescue Mode Root password recovery Backup and recovery YaST Packages
SLES init.d scripts RHEL RC Scripts Fedora systemd Solaris SMF Solaris Run Levels Using virtual consoles Serial console

kernel boot parameter init=/bin/bash

Script is broken: incomplete LSB comment, missing `Required-Start:' entry

Linux Disk Management

 Admin Horror Stories

Linux Tips

 Humor Etc

Linux startup is a multistage process. Process of booting and initializing a UNIX system is challenging to understand in all details even for an experienced system administrator.  Most stages are pretty complex and in turn consist of several steps

  1. MBR loading. The first stage of startup is common to windows and Linux and consists of  loading and execution of  the boot loader code in the MBR.  This is done by using BIOS. The MBR contains also partition table which provides information about which partitions on the disk have boot loader code specific to their operating systems in their boot sectors. One such partition is designated as active and boot sector from this partition is loaded and executed. 
  2. Specialized loader stage. Most distributions now are using the Grub boot loader which is a sophisticated program much larger then 512 bytes (the size of MBR sector). The Grub MBR boot loader searches for a special boot partition and loads a second stage (chain-loading). This stage reads the data in the /boot/grub/menu.lst (in later versions /boot/grub/grub.conf) configuration file, which lists all the available operating systems and their booting parameters. When this is complete, the second stage boot loader then displays the splash screen that lists all the configured operating system kernels for the user to choose.  For Linux those are usually bootable images with different versions of kernal. You can select between different images with the Up/Down keys. Pressing Enter starts the booting of a particular image. 
  3. Kernel initialization. Kernel initialization generates output on the console. You can also examine this output by viewing /var/log/dmesg, which contain a log of all kernel messages during the boot sequence.  It end by starting an init process, the parent process for all Unix processes.
  4. init Initialization. Init in Unix is the parent of all processes. This is easily visible in pstree command where it serves as the root of the tree. The init process reads the file "/etc/inittab" and uses this file to determine which process to launch. Read the init man page for more information. Also note that init is always running and can dynamically do things and run processes based upon various signals. The administrator can also cause it to dynamically change system processes and runlevels by using the telinit program or editing the "/etc/inittab" file.
    • Execution of RC scripts up to designated  /etc/inittab runlevel. Red Hat and Suse uses run levels in a following way:
      • 0 - Halt, init 0 is similar to shutdown -h now
      • 1 - Single user, runs just rc.sysinit. 
      • 2 - Multiuser, without NFS (The same as 3, if you don't have networking)
      • 3 - Full multi-user, console logins only. 
      • 4 - Not used/undefined
      • 5 - Full multi-user, with X11 and display manager as well as console logins
      • 6 - Reboot

      Which services are started in which runlevels can be managed with the chkconfig tool, which modifies links to various runlevel from the script containing in /etc/init.d
       

    • Loading xinetd service and configuration of all controlled by this service daemons.

The kernel takes control of the system's hardware as soon as the message “Uncompressing Linux...” is printed on screen. The kernel checks and sets the console (the BIOS registers of graphics cards and the screen output format), reads BIOS settings, and initializes basic hardware interfaces. Next, the drivers, which are part of the kernel, probe existing hardware and initialize it accordingly. After checking the partitions and mounting the root file system, the kernel starts init, which boots the main system with all its programs and configurations. The kernel controls the entire system, managing hardware access and allocating CPU time and memory to programs.

 Booting with the Initial RAM Disk

As soon as the Linux kernel has been booted and the root file system (/) mounted, programs can be run and further kernel modules can be integrated to provide additional functions. To mount the root file system, certain conditions must be met. The kernel needs the corresponding drivers to access the device on which the root file system is located (especially SCSI drivers). The kernel must also contain the code needed to read the file system (ext2, reiserfs, romfs, etc.). If the root file system is already encrypted, a password is needed to mount the file system.

For the problem of SCSI drivers, a number of different solutions are possible. The kernel could contain all imaginable drivers, but this might be a problem because different drivers could conflict with each other. Also, the kernel would become very large because of this. Another possibility is to provide different kernels, each one containing just one or a few SCSI drivers. This method has the problem that a large number of different kernels are required, a problem then increased by the differently optimized kernels (Athlon optimization, SMP). The idea of loading the SCSI driver as a module leads to the general problem resolved by the concept of an initial RAM disk: running user space programs even before the root file system is mounted.

The initial RAM disk (initrd) solves precisely the problems described above. The Linux kernel provides an option of having a small file system loaded to a RAM disk and running programs there before the actual root file system is mounted. The loading of initrd is handled by the boot loader (GRUB).

Boot loaders only need BIOS routines to load data from the boot medium. If the boot loader is able to load the kernel, it can also load the initial RAM disk. Special drivers are not required.

The boot loader loads the kernel and the initrd to memory and starts the kernel. The boot loader informs the kernel that an initrd exists and where it is located in memory. The kernel decompresses the initrd and mounts it as a temporary root file system. A special program called linuxrc is then started from the root directory of initrd, load necessary drivers  that are necessary for mounting the proper root file system.

linuxrc may be dynamically linked. In this case, the shared libraries in /lib must be available in initrd. linuxrc can also be a shell script. For this to work, a shell must exist in /bin. In short, initrd must contain a minimal Linux system that allows the program linuxrc to be run. When SUSE LINUX is installed, a statically-linked linuxrc is used to keep initrd as small as possible. linuxrc is run with root permissions.

Mounting  Real Root File System

As soon as linuxrc terminates, initrd is unmounted and discarded, the boot process carries on as normal, and the kernel mounts the real file systems. What is mounted as the root file system is determined by linuxrc. It mounts the /proc file system and write the value of the real root file system in numerical form to /proc/sys/kernel/real-root-dev.

Using initrd in SUSE

The initrd is used both for the installation and actual boot of the system, In case of  installation linuxrc starts YaST, which carries out the installation. When YaST has finished, it tells linuxrc where the root file system of the newly installed system is located. linuxrc writes this value and reboots the system. Then YaST starts again and installs the remaining packages in the system.

The way an initrd used during normal bootup process is similar to the method for installation. The linuxrc used here, however, is simply a shell script with the task of loading a given module. Typically, this is just one single module — the SCSI driver needed to access the root file system.

An initrd is created by means of the script mkinitrd . In SUSE LINUX, the modules to load are specified by the variable INITRD_MODULES in /etc/sysconfig/kernel. After installation, this variable is automatically set to the correct value (the installation linuxrc saves which modules were loaded). The modules are loaded in exactly the order in which they appear in INITRD_MODULES. This is especially important if several SCSI drivers are used, because otherwise the names of the hard disks would change. Strictly speaking, it would be sufficient just to load those drivers needed to access the root file system. However, all SCSI drivers needed for installation are loaded by means of initrd because later loading could be problematic.

For more information, see /usr/src/linux/Documentation/ramdisk.txt, /usr/src/linux/Documentation/initrd.txt, and the man page for initrd.

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Dec 11, 2011] Systemd

The systemd is now used in Fedora 15 and 16. It is still under active development and support for it from daemons is limited. Integration into fedora looks premature and is one of the reasons to avoid Fedora 15 and 16. The main command used to control systemd is systemctl. Some of its subcommands are as follows.

For the complete list, see systemctl(1). the GUI equivalent to systemctl is systemadm.

[Aug 10, 2011] Managing Initscripts with Red Hat's chkconfig by Jimmy Ball

Linux Journal

When your Linux box boots, the first process that shows up is init. If you haven't seen init before, take a moment to type ps -ef | grep init to see the PID of init. In short, the init performs tasks that are outlined in /etc/inittab.

Some tasks outlined in /etc/inittab will be launched soon after init, while others are simply set up. For example, the default Red Hat /etc/inittab sets up a trap for the key sequence Ctrl-Alt-Delete. When these keys are simultaneously pressed at a console prompt (not xdm), the shutdown command is performed. At boot time, init sets up this feature based on configuration options in /etc/inittab, but execution is postponed until the key sequence occurs.

The format of inittab allows for comment lines beginning with a "#" symbol while normal entries are ":" delimited. They follow the pattern id:runlevel:action:process where id represents a user-defined and unique identifier, runlevel can be a combination of the numbers 0-6 or just left blank, action comes from a keyword that describes how init should treat the process, and process is the command to execute.

Descriptions of various keywords for the action field can typically be found in the man pages for inittab. Common keywords across most, if not all, UNIX platforms include:

The runlevel field designates system state. For example, a runlevel of 0 corresponds to a halted system while a runlevel of 6 corresponds to a system reboot. Unfortunately, all Linux distributions do not follow the same definition for runlevels. Under Red Hat, the following defaults are supported: 

   0.   System halt
   1.   Single-user mode
   2.   Multiuser, without NFS
   3.   Complete multiuser mode
   4.   User defined
   5.   X11 (XDM login)
   6.   Reboot

For each runlevel, there is a corresponding directory in /etc/rc.d. For a runlevel of 5, the directory /etc/rc.d/rc5.d exists and contains files related to tasks that need to be performed when booting into that runlevel. Under Red Hat, these files are typically symbolic links to shell scripts found in /etc/rc.d/init.d.

Let's put this all together with a simple example. Below are two sample lines from our inittab file:

id:3:initdefault:
l3:3:wait:/etc/rc.d/rc 3

Here is a typical scenario of what happens under Red Hat. Once init is started, it reads /etc/inittab (see above). From the first line, we know that init is going to end up at a runlevel of 3 after the system boots. Once we reach that runlevel, the second line tells init to run the script /etc/rc.d/rc three and waits for it to terminate before proceeding.

The script rc in /etc/rc.d receives 3 as an argument. This 3 corresponds to a runlevel of 3. As a result, the rc script executes all the scripts in the /etc/rc.d/rc3.d directory. It first executes all the scripts that begin with the letter K (meaning "kill" the process or service) with an argument of "stop". Next, it runs all the scripts that begin with the letter S with an argument of "start" to start the process or service. As one final note, the order of K and S script execution is based on sort order; the script named S90mysql would execute before the script named S95httpd.

It turns out the scripts in /etc/rc.d/rc3.d are actually symbolic links to scripts residing in /etc/rc.d/init.d. While the UNIX administrator can place scripts in rc3.d, the common practice under Red Hat is to first place all scripts in init.d, then create logical links to the rc*.d directories. It doesn't take long to figure out the creation and maintenance of these scripts and symbolic links could be quite the chore. That's precisely where chkconfig steps in! The Red Hat chkconfig utility is specifically designed to manage the symbolic links in /etc/rc.d/rc[0-6].d.

[Dec 1, 2007] developerWorks: Linux Initial RAM Disk (initrd) Overview

The initial RAM disk (initrd) is an initial root file system that is mounted prior to when the real root file system is available. The initrd is bound to the kernel and loaded as part of the kernel boot procedure. The kernel then mounts this initrd as part of the two-stage boot process to load the modules to make the real file systems available and get at the real root file system.

"The initrd contains a minimal set of directories and executables to achieve this, such as the insmod tool to install kernel modules into the kernel..."

[Dec 1, 2007] SUSE Linux Enterprise troubleshooting Fixing boot problems by repairing a broken initrd by Sander van Vugt

Troubleshooting is a near-science by itself on which I could spend many articles, but I'll try to keep it brief. During the system boot procedure, several phases occur, starting in GRUB, the Linux boot loader. Roughly, these are the following:

  1. GRUB loads the kernel
  2. GRUB loads the initrd
  3. The root file system is accessed by the kernel
  4. The /sbin/init process takes over.
  5. The initial boot stage happens
  6. The default runlevel is activated
  7. A login prompt occurs.

When a problem occurs, try to pin-point it to any of these seven phases. In some cases it is possible to tell exactly what happens, more often you will see that you can only give a rough indication of what is happening. In the case of a kernel panic, you can be sure about one thing: GRUB has loaded successfully and you are not yet at phase 4 of the boot procedure where the init process takes over. If a kernel panic occurs immediately after a driver installation, this is often caused by an error in the initrd.

How can we be sure? Sometimes it is quite obvious that the error is in initrd, as GRUB tells you that it failed to load the file /boot/initrd, in other cases some forensic work is needed as only a vague driver error message is generated. In the latter case, you have to check if the driver that fails is included in the initrd, as this helper file is used by the kernel to include drivers that are needed immediately. On SUSE Linux Enterprise, the file /etc/sysconfig/kernel contains a list of all drivers that should be included in the initrd. When you run the mkinitrd command, these drivers are written to your new initrd. When this happens automatically, something could go wrong.

Step 2: Fixing it
If an error occurs in the initrd, you will not be able to boot your server anymore. So, to fix it, you need the rescue system that is available from the installation dvd. This rescue system loads a complete Linux system off of the installation media. The next step is to mount all your Linux file systems off of that disk. Next, you need to run mkinitrd. You can only do this once the local file systems are all mounted, because the initrd has to be written to the local file systems. However, there is a caveat.

The problem with this approach is in the disk devices access in combination with the necessary use of a chroot environment. To start, you need to mount your server's file systems on a temporary mount point like /mnt. Let's say that you have the /boot directory on /dev/sda1 and your / directory on /dev/sda2. To mount them, you need the following two commands:

  1. mount /dev/sda2 /mnt
  2. mount /dev/sda1 /mnt/boot

Since the mkinitrd command wants to write the new initrd in /boot and the /boot on your hard drive is now in /mnt/boot, you need to change the root directory to be set to /mnt. You can use chroot to do that:

chroot /mnt

The contents of /mnt now becomes /, so all path references are OK. But we still have a problem. If you look in the /proc and /dev directory on your new root environment, you'll see that /proc is empty and /dev is as good as empty. Both are dynamically created file systems and they are created at the moment that your server boots. This means that they were created in / when the server booted from the rescue cd. Now, since the new root is in /mnt, you cannot access them anymore. We need to fix this.

  1. Type exit to exit from the chroot environment. You'll now get back to the original /mnt under which your servers local file systems where mounted.
  2. Use mount -t proc none /mnt/proc to make the proc file system available from the /mnt environment.
  3. Use mount -o bind /dev /mnt/dev which will make the original /dev which was filled by the udev process when booting available from /mnt/dev.

Now that you have the repair environment all in place, you need to check that the line in /etc/sysconfig/kernel that is used to generate a new initrd is as it should be. You are looking for the following line:

INITRD_MODULES="ata_piix processor thermal fan jbd ext3 dm_mod edd pciback"

This line will be different on every server, so check to make sure that all modules are included that are necessary to start your server (your server's documentation will help you with that.)

Now under /mnt you have the complete environment that is needed to repair your server, so take the following two steps to fix your server.

  1. Activate /mnt using cd /mnt and make it your new root environment using chroot .
  2. Issue the command mkinitrd to write the new initrd to /boot.

You have now fixed the initrd. Reboot your server and check that everything is working all right.

Recommended Links

From Power Up To Bash Prompt

Linux System Startup

Linux startup process - Wikipedia, the free encyclopedia

manage-linux-init-or-startup-scripts

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

 You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019