Understanding the Boot Procedure and Updating Kernel

Understanding the Boot Procedure and Updating Kernel Part IV Upgrading the Kernel:  On occasion, Red Hat releases a newer version of the kernel  To make sure you will benefit from all its new features, it's a good idea to install the newer version of the kernel using " # yum install kernel " OR " # yum -y update kernel " o this will install the newer version without removing the older version of the kernel o this is useful feature because, if something doesn't work well once you install the new kernel on your system, you can still select the old kernel from the GRUB boot menu  To check version of running kernel: o # uname -r

Configuring Service Startup with Upstart:  Much work has been done recently on the way that Linux boots init program:  this is the first process that spawns in the userland at system boot  serves as the root process for all the processes that start on the system thereafter  it's a daemon process assigned PID 1  init process debuted as a single main shell script in BSD UNIX that would call additional shell scripts one after the other in a pre- determined sequence to initialize the system  if a script had to wait for something during the execution, init had no other choice but to pause until what was required either became available to the script or the script timed out  the init process then continued to the next script in the sequence  this unexpected wait resulted in delays in the overall boot process  init was enhanced in UNIX System V(SysVinit) SysVinit:  introduced numbered run levels  this enhance approach modularlized the entire initialization process by permitting the system to boot and run into one of several pre- configured operating states, such as system maintenance, and multi- user states  each operating state defined a set of services and numbered them to be started serially to get to that state of system operation  there were still issue of slower processing of shell scripts  in SysVinit, the initab file was referenced to determine the default run level to boot the system to  after using "systemv-init"(SysVinit) to start services for many years, Upstart appeared to be a worthy successor Upstart:  introduced as a replacement for the SysVinit model  offered 3 major benefits over its predecessors: asynchronous service startup; automatic restart of crashed services; and event-based service start and stop triggered by a process on the system, a change in hardware, or by the start or stop of another service  this enhanced boot model was presented in RHEL6  Upstart is the default method for starting services on Red Hat Enterprise Linux 6 o Upstart uses an event-driven approach. . .In this approach, the Upstart process(implemented by the /sbin/init daemon) is the first thing started when the Linux kernel is booted o After starting, it executes a few scripts that take care of starting all the processes that your server needs o These scripts are in the /etc/init directory o check /etc/inittab if you want to know which Upstart configuration file is used for a given purpose  The only thing still relevant in "/etc/inittab" is that it defines the default runlevel  this happens on the last line, as shown in the example... you can see that id:5:initdefault: is used to set runlevel 5 as the default  If ever you want your server to start in a different runlevel, like the nongraphical runlevel 3, you can change it here o you can also add it for one-time use as a kernel argument from the GRUB prompt  The main part of the Upstart configuration is handled by different scripts in the /etc/init directory  of these, two are particularly important in the boot procedure o the /etc/init/rcS.conf file is used for system initialization o the /etc/init/rc.conf file is used to start the runlevel services  examining these scripts reveals that Red Hat hasn't changed that much since it used systemv in the old days  The most important line in /etc/init/rcS.conf is the one that starts rc.sysinit, a script that takes care of starting everything your server needs to do its job, such as mounting file systems and initializing proc and swap  The other script is /etc/init/rc.conf, which takes care of starting services in the run-levels.  Upstart on RHEL 6 is still fully compliant with runlevels as they were used in system-init  The scripts that start the services themselves are in the directory /etc/init.d  These are the scripts that you can start with a command like service nameofthescript start  To automate the start of these scripts during the boot procedure, Upstart executes symbolic links that start with S in the directory /etc/rcX.d, where "X" is the current runlevel to be started o Thus, if your server is configured to start runlevel 3 from the /etc/init/rc.conf file, the rc script is started, and it executes all symbolic links in order  As an administrator, you can use the "chkconfig" command to put the services in the runlevels where they are typically needed  While switching runlevels, all symbolic links that have a name that starts with "K" are also executed--called kill scripts o this is because you could be switching to another runlevel where services that were needed previously are no longer needed  After processing the runlevels, a few minor scripts are executed o these are, for example, the /etc/init/start-ttys.conf script, which prepares all TTYs on your server, or prefdm.conf, which run the graphical interface in case you use it  For your daily work as an administrator of a Red Hat Enterprise Linux server, you don't need to go into the Upstart scripts very often o If after installing a service your server refuses to boot, it can be useful, though, to know how Upstart works o Having knowledge of its workings allows you to correct errors that are related to misconfiguring the Upstart scripts  Due to some shortcomings in the Upstart design, Red Hat decided not to continue with this init system in RHEL7. . .switched to an even better solution called systemd systemd (RHEL7): Covered in Linux 7

Basic Red Hat Enterprise Linux, Troubleshooting:  Things don't go wrong too often on your Red Hat Enterprise Linux server  If things go wrong, it is frequently related to the boot procedure  You've already learned how to enter the GRUB shell to perform some basic troubleshooting tasks from there, such as manually loading the kernel and initial RAM file system files  In this section, you'll learn about some other techniques that can be useful in fixing boot-related problems on your server

Booting in Minimal Mode:  If your server refuses to boot properly, it may very well be because a service has been installed that cannot start  to fix such problems, it is helpful to start your server in a minimal mode. There are two minimal modes that you can use under specific circumstances: o Runlevel 1 is the mode entered for troubleshooting problems when you're sure they are located in the runlevels and not in the initial phase of the boot procedure . In runlevel 1, all of the essential services are started, and only minimal number of services are started in the runlevels . You can see which services these are by examining all symbolic links that start with S in the /etc/rc1.d directory o If your server still doesn't boot after entering runlevel 1, the problem might be in the initial boot phase . if that's the case, you can skip the entire Upstart-related part of the boot procedure by using the init=/bin/bash command as a kernel argument on the GRUB prompt . this brings you into a minimal mode where only the root file system is mounted and not much else has been started . from this mode, you can start all of the essential services yourself, which allows you to analyze where things go wrong and to fix them o Another useful troubleshooting mode is the interactive mode, which you can activate by pressing "I" once the service start loading . In interactive mode you can start every script one by one so that you can see exactly where it goes wrong if problems do occur . to use interactive mode, your system needs to have loaded the init process successfully o In general, it's a good idea to use runlevel 1 before trying to fix your problems from an init=/bin/bash shell . the reason is simple: many parts of your system have been started in runlevel 1, whereas not very much is started when you use init=/bin/bash . this makes troubleshooting from runlevel 1 a lot easier. Exercise: Starting Your Server in Minimal Mode

Resetting the Root Password:  As an administrator of a Linux system, it can sometimes happen that you need to change settings on a server where you don't know the root password  it's not difficult to reset the root password as long as you have physical access and you can enter GRUB boot options o to do this, you have to enter runlevel 1 for maintenance mode. o after that, you'll need to disable SELinux and then reset the root password Exercise: Resetting the Root Password

Summary:

In this session, you learned about the parts of your computer that are involved in the boot procedure. You learned how GRUB is configured and what you can do to specify specific boot options. You also learned how to Upstart is used to start essential services on your computer. At the end of this chapter, you read about some common scenarios that can help you troubleshoot your server if it fails to start normally