Linux Boot Process (Startup Sequence):Linux

Introduction

Learning however UNIX boots up is essential. after you have this data you'll use it to change the sort of login screen you get additionally as that programs start. scan on for the main points.

The fallowing are the 6 high level stages of Linux boot process



The UNIX Boot Sequence

You might keep in mind after you put in UNIX that the installation method prompted you for an inventory of partitions and also the sizes of every during which your filesystems would be placed.

When allocating space for the partitions, the primary sector, or knowledge unit, for every partition is usually reserved for programmable code utilized in booting. The terribly initial sector of the magnetic disc is reserved for identical purpose and is termed the master boot record (MBR).

When booting from a tough disk, the computer system BIOS starts by loading and death penalty bootloader code. In several cases the entire bootloader code is larger than the area obtainable within the MBR, therefore booting must be exhausted stages.

Fedora UNIX uses the Grub staged bootloader system wherever the primary stage bootloader code (boot.img) is run from the MBR, however counting on the version of Grub, the subsequent sequence of events is completely different.

Grub Version one
In Stage 1.5 of the Grub version one method, further code is loaded from the thirty kilobytes of magnetic disc instantly when the MBR. This 1.5 bootloader image file includes enough partition and filesystem drivers to permit the Stage a pair of to be loaded from a acknowledged location within the boot filesystem, typically /boot/grub. Stage a pair of then hundreds alternative needed drivers and kernel modules before reading the Grub configuration file and displaying the boot menu.

Grub Version a pair of
Like version one, version a pair of reads a picture file (core.img) within the thirty kilobytes when the MBR. to stay its size tiny, it contains just enough modules to access the boot partition and hundreds everything it wants, together with the boot menu, from there.
Grub when the Boot Menu

The acquainted GRUB startup menu is currently displayed, which can permit you to pick out AN OS as well or to look at and edit kernel startup parameters.

Assuming you choose a version of UNIX as well, the subsequent steps can happen:

    The kernel you chose is loaded into memory
 a picture file containing a basic root filing system with all the kernel modules and alternative files the kernel needs to continue the boot method is loaded into memory too. This file is usually referred to as initrd ("init ram disk") or initramfs ("init ram filesystem").
    Grub then starts the kernel and tells it the memory address of the image file. The kernel then mounts this image file as a "starter" memory based mostly root filesystem.
    The kernel then starts to find the systems' hardware by loading drivers it wants from this filesystem.
 the foundation filesystem on disk takes over from the one in memory
    The boot method then starts the package daemons in keeping with the system administrator's settings.
    A root filing system are created in memory employing a ramdisk file are loaded into memory
Let's discuss Grub in additional detail.

Grub Configuration Files

As you'd expect, {the completely different|the various} versions of Grub have different configuration file names and syntaxes. These are lined next.
Grub Version one Configuration

Grub v1 uses the /boot/grub/grub.conf configuration file to induce an inventory of all the obtainable operational systems and their booting parameters. This data is then wont to produce the acquainted GRUB startup menu.

Note: In some operational systems, like Debian / Ubuntu, the /boot/grub/grub.conf file may additionally be mentioned by the name /boot/grub/menu.lst.

Figure 7-1 shows a typical grub.conf file for a system that may boot each trilby UNIX and Windows 2000.
Figure 7-1 Sample grub.conf file

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title trilby Core (2.6.8-1.521)
        root (hd0,0)
        kernel /vmlinuz-2.6.8-1.521 artificial language root=LABEL=/
        initrd /initrd-2.6.8-1.521.img
title Windows 2000
      rootnoverify (hd0,1)
      chainloader +1


In this example, the default worth is ready to zero, which suggests the system boots the primary kernel entry (2.6.8-1.521) after you either:

    Hit the "enter" key once given with the startup splash screen and boot menu
    Let the startup boot menu method timeout at which era it car boots in AN unattended mode

In this configuration example, once default is ready to one, Windows boots.

You can conjointly see that the trilby kernel file is vmlinuz-2.6.8-1.521 and also the memory based mostly root filesystem image file is initrd-2.6.8-1.521.img. each these files are found in your /boot directory or partition.

The (hd0,0) and (hd0,1) disk definitions could appear strange, however /boot/grub/device.map file maps the Grub device language to it expected by UNIX.

#
# File: /boot/grub/device.map
#
(fd0)     /dev/fd0
(hd0)     /dev/hda

So (hd0,0) and (hd0,1) talk to the primary and second partitions of device /dev/hda severally.

Grub Version 2 Configuration

When trilby installs new kernel versions, updated versions of the vmlinuz and initramfs files square measure deposited within the /etc/grub directory. when doing this, the script grub2-mkconfig is run to form AN updated grub menu configuration file /boot/grub2/grub.cfg. this can be then wont to produce the Grub boot menu. a awfully cut version of this file is shown below.

#
# File: /boot/grub2/grub.cfg
#
...
...
...
menuentry 'Fedora (3.4.2-1.fc16.x86_64)' --class trilby --class wildebeest-linux --class gnu --class os {
        echo 'Loading trilby (3.4.2-1.fc16.x86_64)'
 UNIX   /vmlinuz-3.4.2-1.fc16.x86_64 ...
        echo 'Loading initial ramdisk ...'
        initrd /initramfs-3.4.2-1.fc16.x86_64.img
}
...
...

Note: The /boot/grub2/grub.cfg file has sections or stanzas referred to as "menuentry" that outline the entries to be shown within the boot menu and also the parameters every needs. you do not edit /boot/grub2/grub.cfg because it is auto-generated. Customizations square measure exhausted the /etc/default/grub file. A sample is below.

#
# File: /etc/default/grub
#
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Fedora"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 rd.lvm.lv=vg_web003/LogVol01 rd.lvm.lv=vg_web003/LogVol00 \
   KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8"

Here square measure what the keywords mean. If you wish a lot of data, the official Grub manual at http://www.gnu.org has a lot of details.

    GRUB_TIMEOUT: The timeout in seconds that the boot menu is displayed.
    GRUB_DISTRIBUTOR: The distribution of UNIX being employed
    GRUB_SAVEDEFAULT: once set to ‘true’, then the menu entry selected  are saved because the new default entry for all future reboots.
    GRUB_DEFAULT: The name of the menuentry to use within the /boot/grub2/grub.cfg because the version of UNIX as well. If set to variety N, then the ordinal entry is employed. If set to "saved" then the worth of GRUB_SAVEDEFAULT are used. If GRUB_SAVEDEFAULT is not outlined, then the terribly initial menuentry is employed.
    GRUB_CMDLINE_LINUX: an inventory of command-line arguments that may be added  to the kernel menuentry stanzas in /boot/grub2/grub.cfg.

Now we'll discuss booting runlevels and targets.

Boot Runlevels and Targets

The final post booting state of UNIX systems is organized by the systems administrator. With trilby / RedHat systems there square measure seven of those states as outlined in Table 7-1 "Runlevel and Target Descriptions".
Table 7-1 Runlevel and Target Descriptions

Runlevel	Target	Description
0	runlevel0.target , poweroff.target	Halt
1	runlevel1.target, rescue.target	Single-user mode
2	runlevel2.target	Not used (user-definable)
3	runlevel3.target , multi-user.target	Full multi-user mode (no GUI interface)
4	runlevel4.target	Not used (user-definable)
5	runlevel5.target, graphical.target	Full multiuser mode (with GUI interface)
6	runlevel6.target, reboot.target	Reboot

Depending on your version of UNIX there'll be one in every of 2 main kinds of runlevel management systems. These square measure systemd that uses the "target" nomenclature and init that uses the "runlevel" nomenclature.

For example, once the system is ready for runlevel zero, it halts, and once it's set to runlevel six, it reboots. The default level is sometimes three, for booting while not a GUI interface, or five for booting with one. Single user mode is employed for maintenance or emergency repair functions because it hundreds a awfully restricted set of drivers and sometimes has network services disabled.

Some variations between the init and systemd systems include:

• init: The daemon startup scripts within the /etc/rc.X directory square measure dead, wherever "X" is that the run level. Daemons square measure started consecutive. Daemons square measure tracked  by method IDs (PIDs) while not constraints on resource usage.
• systemd: you'll produce your own target directories for your daemons in /etc/systemd/system to form your terribly own custom post boot states. Daemons will be started in parallel. Daemons square measure tracked  by management teams or cgroups that limit system resources by category of daemon. 

Both systems are mentioned next.

Systemd

Symbolic links to the systemd startup configuration files square measure settled within the /etc/systemd/system directory. every target can have its own directory as shown in Table 7-2.
Table 7-2 Systemd Target File Locations

Target	Directory
Default	/etc/systemd/system/default.target.wants
Multiuser	/etc/systemd/system/multi-user.target.wants
Network	/etc/systemd/system/network.target.wants
Sockets	/etc/systemd/system/sockets.target.wants
Sysinit	/etc/systemd/system/sysinit.target.wants

Fortunately you do not ought to be a scripting/symbolic linking guru to create certain everything works right as a result of trilby rate daemon packages install their files within the correct locations so they work properly at every target level.

When the system boots underneath systemd, it follows these basic steps.

1. First, systemd reads all the .target files within the /lib/systemd/system/ directory. every target file contains an inventory of services that require to be run throughout the target activation; an inventory of pre-requisite targets that ought to be completed and also the target that should be completed instantly beforehand. In some cases the file can embody targets that has got to be completed instantly later. during this sample target file we tend to see that the target expects the steps in sysinit.target and sockets.target to be completed as pre-requisites which the target also will run instantly when they're completed

#
# File: /lib/systemd/system/basic.target
#
[Unit]
Description=Basic System
Requires=sysinit.target sockets.target
After=sysinit.target sockets.target
RefuseManualStart=yes

2. victimisation this data, systemd creates a master list of services and also the order during which they must be started. The system can boot and systemd can stop beginning daemons within the list when it executes the services within the default.target file found within the /etc/systemd/system directory. 3. once all this can be completed while not errors, the system has shodden with success.

Table 7-3 provides a outline of some necessary systemd commands that may be useful to you with systemd. These square measure then lined in additional detail.
Table 7-3 necessary Systemd Boot connected Commands

Desired Result	Command
Determine the current default target group	# ll /etc/systemd/system/default.target
Determine the current active target group (Alternative method	# runlevel
Set the default target group (multi-user)	# systemctl enable multi-user.target
Change the current target group (multi-user)	# systemctl isolate multi-user.target # systemctl isolate runlevel3.target
List all active targets in the active target group	# systemctl list-units --type=target

confirm this default target cluster

As expressed before the target management files square measure settled within the /etc/systemd directory tree. The file that sets the default target is /etc/systemd/system/default.target. during this case doing a directory listing of this file shows that once the system boots next, it'll be in target three.

[root@bigboy tmp]# ll /etc/systemd/system/default.target
lrwxrwxrwx. one root root thirty six Gregorian calendar month one  2012               /etc/systemd/system/default.target -> /lib/systemd/system/runlevel3.target
[root@bigboy tmp]#

The presently running target will be determined victimisation the runlevel command. Here we tend to see that it's set to three conjointly.

[root@bigboy tmp]# runlevel
N 3
[root@bigboy tmp]#

If you wish to envision all the varied targets that square measure active then use the systemctl list-units --type=target command as shown here.

[root@bigboy tmp]# systemctl list-units --type=target 
UNIT                LOAD   ACTIVE SUB verbal description
basic.target        loaded active active     Basic System
cryptsetup.target   loaded active active     Encrypted Volumes
getty.target        loaded active active     Login Prompts
local-fs-pre.target loaded active active native File Systems (Pre)
local-fs.target     loaded active active native File Systems
multi-user.target   loaded active active     Multi-User
network.target      loaded active active     Network
remote-fs.target    loaded active active     Remote File Systems
sockets.target      loaded active active     Sockets
sound.target        loaded active active     Sound Card
swap.target         loaded active active     Swap
sysinit.target      loaded active active     System low-level formatting
syslog.target       loaded active active     Syslog

LOAD   = Reflects whether or not the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend upon unit kind.
JOB    = unfinished job for the unit.

13 units listed. Pass --all to envision inactive units, too.
[root@bigboy tmp]#

Set the default target cluster

To set the default target use either the systemctl change x.target command or the ln -sf command to link the /lib/systemd/system/*.target file to /etc/systemd/system/default.target. In these cases we tend to set the default target to three and five.

[root@bigboy tmp]# systemctl change multi-user.target

[root@bigboy tmp]# systemctl change graphical.target

[root@bigboy tmp]# ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target

[root@bigboy tmp]# ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

Next we'll discuss systems that use init.

SysV Init
When a UNIX system running SysV Init begins as well with its kernel, it initial runs the /sbin/init program, that will some system checks, like corroborative the integrity of the file systems, and starts very important programs required for the OS to perform properly. It then inspects the /etc/inittab file to see Linux's overall mode of operation or runlevel. an inventory of valid runlevels will be seen in Table 7-4. Table 7-4 "Init Runlevel File Locations"
7-4 Init Runlevel File Locations 

Runlevel	Directory
0	/etc/rc.d/rc0.d
1	/etc/rc.d/rc1.d
2	/etc/rc.d/rc2.d
3	/etc/rc.d/rc3.d
4	/etc/rc.d/rc4.d
5	/etc/rc.d/rc5.d
6	/etc/rc.d/rc6.d

Based on the chosen runlevel, the init method then executes startup scripts settled in subdirectories of the /etc/rc.d directory. Scripts used for runlevels zero to six square measure settled in subdirectories /etc/rc.d/rc0.d through /etc/rc.d/rc6.d, severally.

Here could be a directory listing of the scripts within the /etc/rc.d/rc3.d directory:


[root@bigboy tmp]# ls /etc/rc.d/rc3.d
...    ...    K75netfs      K96pcmcia    ...    ...
...    ...    K86nfslock    S05kudzu     ...    ...
...    ...    K87portmap    S09wlan      ...    ...
...    ...    K91isdn       S10network   ...    ...
...    ...    K92iptables   S12syslog    ...    ...
...    ...    K95firstboot  S17keytable  ...    ...
[root@bigboy tmp]#

As you'll see, every computer filename in these directories either starts with AN "S" that signifies the script ought to be run at startup, or a K, which suggests the script ought to be run once the system is closing down. If a script is not there, it will not be run.

Most UNIX packages place their startup script within the /etc/init.d directory and place symbolic links (pointers) to the present script within the acceptable directory of /etc/rc.d. This makes file management lots easier. The deletion of a link does not delete the file, which might then be used for one more day.

The number that follows the K or S specifies the position during which the scripts ought to be run in ascending order. In our example, Pueraria lobata with a price 05 are started before LAN with a price of 09. luckily you do not ought to be a scripting/symbolic linking guru to create certain everything works right as a result of trilby comes with a peachy utility referred to as chkconfig whereas Debian / Ubuntu uses the update-rc.d command to try and do it all for you. this can be explained later.

Determining and Setting the Default Boot runlevel
The default boot runlevel is ready within the file /etc/inittab with the initdefault variable. once set to three, the system boots up with the text interface on the VGA console; once set to five, you get the GUI. Here could be a piece of the file (delete the initdefault line you do not need):

# Default runlevel. The runlevels utilized by RHS are:
# zero - halt (Do NOT set initdefault to this)
# one - Single user mode
# a pair of - Multiuser, while not NFS (The same as three, if you are doing not have networking)
# three - Full multiuser mode
# four - unused
# 5 - X11
# half dozen - boot (Do NOT set initdefault to this)
# 
id:3:initdefault:                         # Console Text Mode
id:5:initdefault:                         # Console GUI Mode

Note the following:

    Most home users boot up with a Windows like GUI (runlevel 5)
    Most techies can tend as well up with an evident text-based command-line-type interface (runlevel 3)
 dynamic  initdefault from three to five, or vice-versa, has a bearing upon your next boot. See the subsequent section on a way to get a GUI login all the time till successive boot.
    Of course, do not set the initdefault worth to six or your system can perpetually boot. Setting it to zero can ne'er permit it to start!

System closure and Rebooting
It is typically not a decent plan to instantly power off your system after you square measure finished victimisation it. this may cause files that square measure being updated to become corrupted, or worse, you'll corrupt the filesystem directory structure. UNIX includes a variety of how to graciously stop working and boot your system which can be made public during this section.

Halt/Shut Down The System
The init command can permit you to vary this runlevel, and for a closure, that worth is zero. Here is AN example:

[root@bigboy tmp]# init zero

Fedora conjointly includes a closure command which might even be wont to identical result. It typically prompts you on whether or not you're certain you would like to execute the command, which might be avoided with the -y switch. The -h switch forces the system to halt, and also the initial argument tells it however long to attend before beginning the procedure, during this case zero minutes. you'll conjointly specify closing down at a selected time of the day; please talk to the person pages for details. Another advantage of the closure command is that it warns those that the closure goes to occur.

[root@bigboy tmp]# closure -hy zero

Broadcast message from root (pts/0) (Sat Nov half dozen 13:15:27 2004):

The system goes down for system halt NOW!
[root@bigboy tmp]#

Reboot The System
You can conjointly use the init command to boot the system instantly by coming into runlevel half dozen.

[root@bigboy tmp]# init half dozen

The "reboot" command has identical result, however it conjointly sends a warning message to any or all users.

[root@bigboy tmp]# boot

Broadcast message from root (pts/0) (Sat Nov half dozen 12:39:31 2004):

The system goes down for boot NOW!
[root@bigboy tmp]#

More swish reboots will be finished the closure command victimisation the -r switch and specifying a delay, that during this case is ten minutes.

[root@bigboy root]# closure -ry ten

Broadcast message from root (pts/0) (Sat Nov half dozen 13:26:39 2004):

The system goes DOWN for boot in ten minutes!

Broadcast message from root (pts/0) (Sat Nov half dozen 13:27:39 2004):

The system goes DOWN for boot in nine minutes!
...
...
...
Broadcast message from root (pts/0) (Sat Nov half dozen 13:36:39 2004):

The system goes down for boot NOW!

Entering Single-user Mode

Some activities need you to force the system to log out all users, third-party applications and networking so solely the systems administrator has access to the system from the VGA console. A typical situation is that the addition of a brand new magnetic disc, as mentioned in Chapter twenty seven, "Expanding Disk Capacity", or the troubleshooting of a failing boot method.

Another reason is that the recovery of your root arcanum.
Switching to Single-user Mode

When the system is running usually, this may be done by victimisation the init command to enter runlevel one. it's best to try and do this from the console, as a result of if you are doing it from a foreign terminal session you will be logged out.

[root@bigboy root]# init 1
...
...
bash-2.05b#
Unfortunately, this provides no previous warning to users, and also the closure command does not have a single-user mode possibility. this may be overcome by running the closure command with a delay in minutes because the solely argument.
[root@bigboy tmp]# closure one
Broadcast message from root (pts/0) (Sat Nov half dozen 13:44:59 2004):
The system goes all the way down to maintenance mode in one minute!
Broadcast message from root (pts/0) (Sat Nov half dozen 13:45:59 2004):
The system goes all the way down to maintenance mode NOW!
...
...
bash-2.05b#
Entering Single-user Mode At The Grub Splash Screen
You can enter single user mode directly when turning on the facility to your system. The steps to try and do this square measure listed below.

1. Power on your system. look ahead to the "Grub loading" message to seem and, counting on your UNIX distribution, make preparations to hit either any key or the ESC key to enter the grub boot menu.

Grub loading, please wait ...
Press ESC to enter the menu
or
Grub loading, please wait ...
Press any key to enter the menu

2. you'll then get grub's main menu which can show an inventory of obtainable kernels. Use the arrow keys to scroll to your required version of the kernel so press e for "edit".

Fedora Core (2.6.18-1.2239.fc5smp)
Fedora Core (2.6.18-1.2200.fc5smp)

3. The kernel's boot menu can seem. Use the arrow keys to scroll to the "kernel" line so press e for "edit".

root (hd0,0)
kernel /vmlinuz-2.6.18-1.2239.fc5smp artificial language root=LABEL=/
initrd /initrd-2.6.18-1.2239.fc5smp.img

4. A grub edit prompt can seem. Use the arrow keys to maneuver to the tip of the road and add the word "single" to the tip, separated by an area. Change

grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp artificial language root=LABEL=/

to

grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp artificial language root=LABEL=/ single

5. Press enter to avoid wasting your changes, so b for "boot". 6. The system can still boot, however can go straight to the foundation # prompt while not initial inquiring for a username and arcanum.
Reverting To Your Default runlevel From Single User Mode

The exit command forces the system to exit runlevel one and revert to the default runlevel for the system. you'll conjointly use the init command (for example init three and init 5) to change this default behavior:

bash-2.05b# exit
INIT: coming into runlevel: three
...
...
...
Fedora Core unleash a pair of (Tettnang)
Kernel 2.6.8-1.521 on AN i686
bigboy login:

Root arcanum Recovery

Sometimes you may forget the foundation arcanum, or the previous systems administrator could travel to a brand new job while not giving it to you. To do this, follow these steps:

 visit the VGA console and press Ctrl-Alt-Del. The system can then stop working in AN orderly fashion.
 boot the system and enter single-user mode.
    Once at the prompt, modification your arcanum. Single user mode assumes the person at the console is that the systems administrator root, therefore you do not ought to specify a root username.
 come back to your default runlevel by victimisation the exit command.


The UNIX Console

A good data of some basic UNIX console commands is usually useful instantly when booting. Here square measure some examples.
Getting a GUI Console

Manual Method: you'll begin the X terminal GUI application every time you wish it by running the startx command at the VGA console. keep in mind that after you exit you'll get the regular text-based console once more.

[root@bigboy tmp]# startx

Automatic Method: you'll have UNIX mechanically begin the X terminal GUI console for each login try till your next boot by victimisation the init command. you'll have to be compelled to edit your initdefault variable in your /etc/inittab file, as mentioned within the preceding section to stay this practicality even when you boot.

[root@bigboy tmp]# init 5

When the electronic equipment capability or obtainable memory on your server is low otherwise you wish to maximise all system resources, you may wish to work in text mode runlevel three most of the time, victimisation the GUI solely as necessary with the startx command.

Servers that double as personal workstations, or servers which may ought to be operated for AN extended amount of your time by comparatively nontechnical  employees, might have to be run at runlevel five all the time through the init five command. keep in mind you'll build runlevel five permanent even when a boot by written material the /etc/inittab file.
Get a Basic Text Terminal while not Exiting the GUI

There square measure variety of how for you to induce a prompt once running a UNIX GUI. this may be necessary if you wish fast access to commands otherwise you aren't at home with the GUI menu possibility layout.
Using a GUI Terminal Window

You can open a GUI-based window with a prompt within by doing the following:

    Click on the trilby emblem button within the bottom manus corner of the screen.
    Click on Systems Tools so Terminal

Using Virtual Consoles

By default, UNIX runs six virtual console or TTY sessions running on the VGA console. These square measure outlined by the mingetty statements within the /etc/inittab file. The X terminal GUI console creates its own virtual console victimisation the primary obtainable TTY that's not controlled by mingetty. This makes the GUI run as variety 7:

 you'll step through every virtual console session by victimisation the Ctl-Alt-F1 through F6 key sequence. you will get a brand new login prompt for every try.
 you'll get the GUI login with the sequence Ctl-Alt-F7 solely in run level five, or if the GUI is running when launching startx.

Conclusion
The topics mentioned during this chapter might sound straightforward, however like syslog, that was lined in Chapter five, "Troubleshooting UNIX with syslog", they're a necessary a part of UNIX administration that gets often unnoticed particularly once new package is put in.

Whenever attainable, perpetually attempt to boot your system to create certain all the freshly put in applications start properly. typically they begin however offer errors listed solely within the /var/log directory. Taking the time to tack together and take a look at your startup scripts may stop you from being woke up within the middle of the night whereas you're on vacation! it's very necessary.


More Details click here