webpointmorpheus Linux Info
The Linux Kernel
and the Boot Process

     Intro      Boot Process      Boot Loaders      Kernel Parameters      Boot Log      Runlevels      Shutdown
     Kernel Management      Kernel Modules      Kernel Utilities      lsmod      modinfo      rmmod      insmod
     depmod      USB Modules      Kernel Source      Kernel Config      Boot Loader Repair      Lost Root Password      Documents in this Series

Introduction Top of Page

The Linux kernel is the heart of the operating system. The kernel sits between the software that is accessible to the user, and the hardware that is strictly physical. The kernel is the one single entity upon which all distributions of Linux uniformly depend. Current kernel architecture makes possible multi-processors, processor modules that can be loaded upon demand, and other features. Typically, a small kernel is lighter, faster, and easier to maintain, so compiling in only those kernel features necessary is of merit. This page attempts to explain the computer boot process, and some of the workings and configurations of the kernel.

Kernel Identification Top of Page

Linux kernels are numbered in a specific fashion such that the version and its status are able to be determined in a single glance. The latest stable version of the Linux kernel at the time of this writing is 2.6.19. In this series of numbers, there is the major number - the 2, the minor number - the 6, and the revision number - the 19. Major numbers don't progress very rapidly. Minor numbers are important, in that they don't increment unless there is a pretty large change in the kernel. Minor numbers are also important in the fact of whether they are even or odd. An odd minor number indicates an experimental release of the kernel, typically for testing purposes. An even minor number indicates a stable production release of the kernel that has been proven for use. See www.kernel.org for more information about the Linux kernel than you can absorb in one sitting.

Overview of the Boot Process Top of Page

Listed below is a summary of the boot process for PCs:

When a PC is turned on, the BIOS (Basic Input Output Service) performs a self test. This process is called POST (Power On Self Test.)
When the machine passes its self test, the BIOS loads the Master Boot Record (or MBR, usually from the first track of the first 512-byte sector of the boot drive). This is usually the first hard drive on the system, but may also be a diskette, CD, or USB key, depending on the settings in BIOS.
For a hard drive, the MBR loads a stage 1 boot loader, which is typically either the LILO or GRUB stage1 boot loader on a Linux system. This is another 512-byte, single-sector record.
The stage 1 boot loader usually loads a sequence of records called the stage 2 boot loader (or sometimes the stage 1.5 loader).
The stage 2 loader loads the operating system. For Linux, this is the kernel, and possibly an initial RAM disk (initrd).
Subsequently, the init daemon is loaded, which proceeds to load all other daemons.

Boot Loaders: LILO & GRUB Top of Page

A boot loader is a small piece of code that acts as an intermediate agent during to boot process to tell the computer hardware where the operating system is located. It's also possible to configure a system to dual boot, which will then offer a choice of operating systems. The boot loader will offer the choice, and proceed to load that specific system into action. Boot loaders can also pass specific parameters to the kernel as it boots, thereby giving options as the system powers up.

LILO (LInux LOader) Top of Page

LILO is the oldest boot loader that has been used with Linux. The LILO configuration file defaults to /etc/lilo.conf. If changes are made to /etc/lilo.conf, or if a new kernel is installed or compiled, lilo must be run. The lilo utility rewrites the MBR or the partition boot record to reflect the changes. The message parameter in the LILO configuration file may refer to a text file that is external to the lilo utility. It is also possible to customize graphical LILO messages, but this process is not very well documented. Check out the Linux Bootsplash project for more info.

GRUB (GRand Unified Boot loader) Top of Page

GRUB is a newer boot loader, and offers more customization options than LILO. GRUB provides a menu interface that can also use a password encrypted with the MD5 algorithm, see command below. The GRUB configuration file defaults to /boot/grub/grub.conf or /boot/grub/menu.lst, and if both are present, one will usually be a symbolic link to the other. Typically, changes made to the GRUB configuration file do not require GRUB to be reinstalled in the MBR. An alternative background image can be specified for GRUB, but may be limited to 14 colors.

To install the GRUB boot loader, issue the grub-install command. The GRUB device map is located at /boot/grub/device.map.
To secure the GRUB boot loader, it can be password encrypted with the command grub-md5-crypt.

Using the GRUB shell Top of Page

The GRUB utility behaves as a small shell. There are several commands that allow editing the commands before they are executed, find and load a configuration file, display files using the cat command, and other tasks. When in the GRUB shell utility, type help for assistance. GRUB can display files on the filesystem, and typically runs as root user. Caution is advised while using the GRUB utility, as well as password protecting the bootloader. Consider that if a user can boot from removable media, that user can provide their own GRUB configuration. Consider password protecting the system BIOS. The security section in the GRUB manual page has more info, and can be viewed with the info grub command.

Kernel Parameters Top of Page

Kernel (or boot) parameters can be used to supply the kernel with information about hardware parameters that it might not determine by itself. When the kernel finishes loading, it usually starts /sbin/init, the main system daemon. This daemon runs continuously until the system is shut down, and is always assigned process ID 1. The init program boots the rest of the system by running a series of scripts which typically live in /etc/rc.d/init.d or /etc/init.d. These scripts perform the following at a minimum:

setting the system's hostname
checking the filesystem for errors
mounting additional filesystems
enabling networking
starting print services
starting the web server
starting the FTP service
starting the system log service

When the init finishes with its scripts, it starts getty, which displays the login prompt on consoles.

A system that can load the kernel successfully, but cannot run init successfully, may be recovered by specifying an alternate initialization program. Try init=/bin/sh to boot the system into a shell prompt with root authority, from which repair might be possible.

There is more info about the boot parameters in the man pages for bootparam. If the same set of parameters are manually applied every time the system boots, consider adding them to the configuration file.

Boot Log of Events Top of Page

During the boot process, there are large number of messages are emitted to the console. These usually go by fast, and aren't always detailed. The boot process and messages are logged to a file called /var/log/dmesg, where it is possible to go back and review the kernel messages that were generated during the boot process.

Since standard output is related to a process, and the kernel does not have a process identifier, it keeps kernel (and module) output messages in an entity known as the kernel ring buffer. The kernel ring buffer is also used for some events after the system is booted, which include certain program failures and hot-plug events. The kernel ring buffer can be displayed by using the dmesg command.

/var/log/messages

Once the system has booted and is running /sbin/init, kernel events continue to be logged to the ring buffer, but processes commence to use the syslog daemon to log messages in /var/log/messages. Unlike the ring buffer, each syslog line has a timestamp, and the file is written to disk such that it persists between system restarts. This file is the main source for errors that occurred during the init script's stage of booting. Additional logs for many other system programs reside in /var/log. Most daemons have names that end in 'd'.

Runlevels, shutdown, and reboot Top of Page

Runlevels define a collection of daemons or tasks that are running in the current system state (or runlevel) of a Linux system. Every Linux system supports three basic runlevels, plus one or more runlevels for normal operation. The Slackware distribution uses runlevel 4 instead of 5 for a full system running the X Window system. Debian uses a single runlevel for any multi-user mode, typically runlevel 2. Beyond the basics, runlevel usage differs among distributions. See the table below for typical runlevel definitions.

Level	Purpose
Linux runlevels
0	Shut down (or halt) the system
1	Single-user mode; usually aliased as s or S
2	Multi-user mode without networking
3	Multi-user mode with networking
5	Multi-user mode with networking and the X Window System
6	Reboot the system

The Default System Runlevel Top of Page

When a Linux system starts, the default runlevel is determined from the id: entry in /etc/inittab. This default runlevel can be changed by editing that file manually. To make a permanent change, edit /etc/inittab and change the default level as listed above.

It is possible to bring the system up in a different runlevel at boot time, perhaps runlevel 3 instead of runlevel 5. This is often the preferred method of performing certain kinds of upgrades or maintenance, without the overhead of the X system. The change in runlevel can be done at boot time by editing the kernel line (GRUB) or adding a parameter after the selected system name (LILO). Use a single digit to specify the desired runlevel.

Once finished in runlevel 3, it is not necessary to reboot the system to switch to runlevel 5. Use the telinit command to tell the init process what runlevel it should switch to. The current runlevel can be determined by using the runlevel command, which shows the previous runlevel as well as the current one. If the first output character is 'N', the runlevel has not been changed since the system was booted.

The telinit command is actually a symbolic link to the init command. The init executable knows which way it was called and behaves accordingly. Since init normally runs as PID 1, it is also smart enough to know if it was invoked using init rather than telinit. If so, it will assume that it should behave as if as if called by telinit.

Single-user mode Top of Page

Linux is inherently a multiuser system. This can be a problem, such as when performing maintenance, or when there is a need to recover a major filesystem or database, or install and test some new hardware. Runlevel 1, or single-user mode, is the best way to perform these tasks. Typically, the shell will start in runlevel 1 with only a minimal system. Also, there will be no networking and no (or very few) daemons running. On some systems, the user logging in must authenticate, but on others the shell launches directly as root. Single-user mode can be a lifesaver, but it is also possible to destroy the system. It is also possible to switch to single-user mode using telinit 1.

System Shutdown Top of Page

While you can use telinit or init to stop multiuser activity and switch to single-user mode, you may also use the shutdown command. The shutdown command sends a warning message to all logged on users and blocks further logins. It then signals init to switch runlevels. The init process then sends all running processes a SIGTERM signal, which gives them a chance to save data or otherwise properly terminate. After 5 seconds, or another delay if specified, init sends a SIGKILL signal to forcibly end each remaining process.

By default, shutdown switches to runlevel 1 (single-user mode). The -h option can be specified to halt the system, or the -r option to reboot. A standard message is issued in addition to any message you specify. The time may be specified as an absolute time in hh:mm format, or as a relative time, n, where n is the number of minutes until shutdown. For immediate shutdown, use now, which is equivalent to +0.

A delayed shutdown can be stopped while in progress by pressing Ctrl-c if the command is running in the foreground, or by issuing shutdown -c to cancel a pending shutdown. It is also possible to use telinit (or init) to shut down or reboot the system. As with other uses of telinit, no warning is sent to users, and the command takes effect immediately. There is a delay between SIGTERM and SIGKILL signals. For more information on init, telinit, and shutdown consult the man pages.

Shutdown Commands Top of Page

Listed below are a few more commands related to shutdown and reboot.

halt simply halts the system.
poweroff is a symbolic link to the halt command, which halts the system and then attempts to power it off.
reboot is a another symbolic link to the halt command.
If any of these are called when the system is not in runlevel 0 or 6, then the corresponding shutdown command will be invoked instead.

Configuring Runlevels Top of Page

The id field in /etc/inittab, as well as several other fields, permit other configuration parameters to be loaded at boot time. The CTRL+ALT+DELETE key combination can be trapped by the line listed below in /etc/inittab. There are a set of init scripts in directories such as rc1.d or rc5.d, such that the digit identifies the runlevel that applies.

The scripts used by init when starting the system, changing runlevels, or shutting the system down are typically stored in the /etc/init.d or /etc/rc.d/init.d directory. There is a series of symbolic links in the rcn.d directories (where n represents the number of the runlevel) that control whether a script is started when entering a runlevel, or stopped when leaving it. These links start with either a K or an S, followed by a two-digit number, then the name of the service. For more info, type man inittab or man init.

Listing Services per Runlevel Top of Page

To view a table of daemons and their state per runlevel, enter the command chkconfig. This command will list all 7 runlevels, as well as which services are set to run on each.

Trapping CTRL+ALT+DELETE

[root@basement root]# grep -i ctrl /etc/inittab
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

Kernel Management Top of Page

The kernel is the core and frame upon which applications run and use hardware devices. It is the base low-level code that deals with hardware interfaces, scheduling, and memory allocation and management, etc. Situations which require a kernel update or upgrade, or the addition of kernel modules are listed below:

The release of a more stable version of the kernel
Need for additional hardware support
Hardware platform and architecture advances and development such as processors and/or memory
Software package installation or compatibility
General or overall system updates or upgrades, security concerns performance considerations
Security concerns
Performance considerations, such as lightening the kernel

Kernel Modules Top of Page

The kernel manages low-level hardware and file systems. Since there are many possible hardware and file system types and configurations, a kernel that attempted to support all possibilities would be large and unwieldy. Dynamically loaded kernel modules are the method used to support software that is to be used for hardware drivers, file systems, etc. In this way, the system can begin with a small kernel, then load other modules dynamically when they are needed. An all-inclusive kernel needs to be rebuilt completely every time additional functionality is added to the system. Loading of modules is typically set to be automatic, such as when USB devices are connected, etc. Listed below are several utilites which are made to facilitate module query, access, configuration, installation, and removal.

Since the initial system kernel cannot contain everything that is needed by the kernel processes, the kernel image that is loaded at boot must be able to mount the root file system at a minimum. The boot loader can also load an initial RAM disk - initrd - which may contain the modules necessary to mount the root file system. There is more on initrd in the Linux installation section. The kernel image must at least contain support for the RAM file system used in the initial RAM disk, without which the system will not boot. Once the system has booted itself and loaded the initrd, the next step is to mount the root file system, then proceed to the other initialization processes. Typically, after a few seconds, the system is up and ready for use. The kernel, however, remains silently in control. It is a faithful watchdog that awaits requests to perform assigned tasks for user processes, and scheduling the system resources among the tasks that require them. autocleaning can voluntarily disassociate unused modules from the rest of the kernel and unload them from memory if the modules have not been used for several minutes.

Most modern systems with plenty of RAM and disk space are perfect for modular kernels. There are some instances of new hardware (video card, RAID array, hard disk, etc.) that are not supported by the stock kernel that came with the installed distribution. Some drivers contain proprietary code that is said to 'taint' a pure Linux kernel. These drivers are not included with many distributions of Linux, even if the vendor license permits distribution. In these circumstances the system administrator is expected to build the new modules, or perhaps rebuild the kernel itself. At times and under certain circumstances, specific workarounds or custom drivers will need to be applied.

The Linux kernel has been adapted for use in many environments which include embedded systems such as mobile phones, web servers, DNS servers, networking devices, routers, traditional computing environments, and more. Some of these devices require a limited kernel that is customized to support only those functions that the custom system is intended to support. A diskless firewall would not need support for a file system other than the read-only file system from which it loaded. In such custom environments, a custom kernel will be required.

Kernel Utilities Top of Page

Listed below are the core kernel utilities that assist the system administrator.

Querying the Kernel with the uname Command

Getting information about the kernel is the first and most important step in determining what is going on with the kernel, as well as how to best deal with the kernel. The uname command returns pertinent information about the kernel. See the options listed below.

Option	Description
Options for `uname`
-s	Prints the kernel name. This is the default option.
-n	Prints the nodename or hostname.
-r	Prints the release of the kernel. This option is often used in scripts, or with commands that handle modules.
-v	Prints the version of the kernel.
-m	Prints the machine's hardware (CPU) name.
-o	Prints the operating system name.
-a	The all option, prints all of the above information.

lsmod Top of Page

The lsmod command will display the modules that are currently loaded on the system. lsmod also shows the module size and the number of users of the module. If the module is used by any other modules, these are listed.Modular support extends to video devices, SATA and SCSI hard drives, floppy disks, sound cards, networking features such as IPV6, file system support such as ext3, and Sun remote procedure call (RPC).

The kernel supplies most of the necessary modules as it comes 'out of the box'. Some modules will include proprietary code, and are not part of the standard kernel. The modular approach allows proprietary code to be plugged in to an open source kernel. There may be limitations per the vendor license, but those limitations permitting, a Linux distributor may add proprietary modules to the distribution. This practice will save the administrator the effort of having to acquire them individually from the vendor. Additionally, if included with the distribution, the modules have been considered and are relatively assured to be the appropriate level.

modinfo Top of Page

The modinfo command displays information about modules per flags that are passed to the command. The information will include the full path to the file, the author, license, any parameters that the module might accept, version, dependencies, etc. Note that there are module differences in kernel versions of 2.6. Module filenames that end in a .ko suffix distinguish modules for 2.6 kernels from other object files, as well as from modules for 2.4 and earlier kernels, which used the same .o suffix as object files.

The module path must include the kernel version, which is often done by command substitution. For example, /lib/modules/2.6.12-1.1456_FC4/kernel/drivers/block/floppy.ko includes 2.6.12-1.1456_FC4 as a path element. This is the same value emitted by uname -r. The path with command sutstitution would appear thus: /lib/modules/`uname -r`/kernel/drivers/block/floppy.ko. Kernel modules are specific to a given kernel, therefore this structure is the means to manage that relationship.

2.6 kernels can also use modinfo to limit requests for module information. The -F option will extract a single information type: parm, description, license, filename, alias. The command can be used repetitiously with different options to return different types of information. For use on 2.4 kernels, -p will extract kernel parameter information. The current modinfo command supports older parameters. See the man page for more details.

rmmod Top of Page

Loaded modules do not always get used. A module that has a use count of 0 may safely be removed. This might be typically done in preparation for loading an updated version of the kernel. This feature of a modular kernel facilitates not having to reboot just to update support for a device. Use the rmmod command with the module name. Consult the man pages for other options available with rmmod.

insmod and modprobe Top of Page

You can reload a module using the insmod command. insmod takes the full path name of the module to be reloaded, as well as any required module options. It's best to use command substitution for generating the filename.

modprobe provides a higher-level interface that operates with the module name instead of file path. Command differences are as indicated: insmod /lib/modules/`uname -r`/kernel/drivers/block/floppy.ko becomes insmod $(modinfo -F filename floppy). It handles loading additional modules upon which a module depends, and can remove modules as well as load them. Note that the -v option can be specified to obtain verbose output. Without this flag, modprobe (and the underlying insmod command) will display only error messages from the module itself. The output of lsmod can be piped through grep to show whether the module is loaded or not. modprobe can handle automatic loading of multiple modules including dependencies. The dependencies are stored in the modules.dep file in the /lib/modules subdirectory. Use uname -r substitution to the command to get info for the current kernel. This file (and map files) is generated by the depmod command. The -a (all) flag is optional.

depmod Top of Page

The depmod command scans the modules in the subdirectories of /lib/modules for the appropriate kernel and updates the dependency information. The behavior of modprobe and depmod can be customized using the configuration file /etc/modules.conf. This is commonly used to create an alias for module names, or to specify commands that should be run after loading a module, or before it is unloaded. A wide range of other configuration can be done. Consult the man page for modules.conf for more information. Some systems use a different configuration file called modprobe.conf, and others store module configuration information in the /etc/modules.d directory. Further, a file called /etc/modules may be present on some systems that contains the names of kernel modules that should be loaded at boot time.

USB Modules Top of Page

Plugging or conecting a USB device into the Linux system forces the kernel to determine which modules to dynamically load for the device. The detection is typically done automatically by a hot plug script that uses the usbmodules command which looks for and finds the appropriate module. Enter the lsusb command to see which USB ports and devices are connected to the system. Enter the command usbmodules to see which kernel modules are available. usbmodules currently requires usbdevfs to operate. Sourceforge has more info on Linux Hotplugging.

Source Packages Top of Page

The initial steps for upgrading or building the kernel or kernel modules are outlined below. Follow the list as indicated immediately below FIRST to avoid a system disaster. IBM developerWorks offers an excellent tutorial on building a kernel for Fedora.

Create or somehow secure a workable boot disk to prevent mistakes from becoming disaster. To create a boot disk, use mkbootdisk --device /dev/fd0 2.x.x (where the 2.x.x is the full version of the kernel.)
Test the boot disk to verify it's functionality. This makes restoration of the old kernel possible.
In some instances, a floppy rescue disk may not be possible - such as for the 2.6.x kernel. In this instance, be prepared to create the disk on a flash USB drive, CD, or have the original installation CD available.
Clear/clean all previous config files from the source tree from previous kernels with the make mrproper command.
After these items are finished, there are several methods for upgrading the kernel. See the listing below.

The ultimate source for the Linux kernel is the Linux Kernel Archives. Without previous kernel experience, it's best to use a kernel package from the current Linux distribution - the distributor may have added custom patches. When undertaking any task that may change the system, make backups first to facilitate recovery of the system in case things go wrong.

Source code from the public kernel archives will be a compressed file. After the download completes, decompress it with gzip or bzip2. The pub/linux/kernel/ directory on the download server has a directory for each kernel version. Look for the ChangeLog-2.x.x file that describes the latest changes. There may also be a patch file that allows patching of the prior version of source code to bring it up to the desired level. Also look for signature files that verify the integrity of the downloaded file, as accidental or malicious corruption may occur.

Typically, the compressed source is uncommpressed and placed in /usr/src. It should create a new subdirectory for the kernel version which will contain the tree of files needed for the new kernel build. If that directory already exists, back it up or rename it before uncompressing the new kernel. This is a safeguard in case of mistakes or failure. It also clears debris files that should not be in the kernel source tree. Typically, the compressed file is about 40MB, and the expanded source code will be about 350MB.

It's possible to download the kernel headers and source necessary for building kernel modules in a development mode. It's also possible that the documentation will be in a separate kernel package. These are designed for and sufficient for building dynamic modules (proprietary drivers, etc.) but they are not sufficient for building a custom kernel. Check the uncompressed distribution for information about how to rebuild the kernel, HOWTO's, how the source can be obtained, or for other documentation and release notes.

The individual steps to building and upgrading a kernel are beyond the scope of this paper. For an excellent source of information, refer to the tutorial listed above. The options and methods listed below are typical of the process of building and upgrading a kernel.

Kernel Configuration Top of Page

There are five methods of kernel upgrade, as listed below. Typically, one will choose one of these, and proceed.

Method	Description
Five methods of kernel upgrade
`make config`	An interactive command line approach that prompts for Y(es), N(o), or M(odule).
`make menuconfig`	A menu driven interface that permits selection of components. Prompts for Y(es), N(o), or M(odule).
`make xconfig`	A graphical interface based on a QT front-end. Prompts for Y(es), N(o), or M(odule).
`make gconfig`	`gconfig` uses a graphical menu system based on a GTK environment.
`make oldconfig`	A non-interactive command line method that sets up the installation per default configuration. Unnecessary features can be turned off later.
Notes: `mrproper` and `make config` can be eliminated with a pre-configured installation file on identical systems. In this scenario, use `make dep` and `make clean` to prepare the system for the upgrade.

make menuconfig will bring up a graphical interface for choosing kernel build options. The dialog box will be different among kernel minor versions. Note the options listed below for building options into the kernel as modules or compiled-in:

Option	Description
Options for menuconfig
[*]	The feature will be built into the kernel.
[ ]	The feature will not be included in the kernel.
<M>	The feature will be built as a kernel module.
< >	The feature will not be included in the kernel but is capable of being built as a module.

It's best to run make gconfig for a 2.6 series kernels. Help is available, and can be displayed in a lower pane. The major configuration steps for a 2.6 kernel are described below. These man not be avialable for 2.4 and earlier kernels.

Option	Description
Main Configuration Options
Code maturity level options	An option that determines whether the following options give offer a choice for code that is considered experimental.
General setup	Include an identification string with your new kernel. There are options for several kernel attributes that do not belong elsewhere.
Loadable module support	An option that determines whether the kernel will support dynamic modules and whether they may be automatically loaded. It is a good choice to enable module support.
Block layer	Support for disks larger than 2TB as well as a choice of the type of disk scheduling preferred.
Processor type and features	CPU-specific configuration options. Enable symmetric multi-processing support if you have more than one CPU or a hyperthreaded CPU. Enable the MTRR option to allow better graphic performance with AGP or PCI video cards.
Power management options	Power management options. These are particularly useful on laptops. Offers options to control and monitor such things as temperatures or fan states.
Bus options (PCI etc.)	Options for buses supported by the system. Enable the `/proc/pci` file system here - although it's better to use `lspci` instead.
Executable file formats & Emulations	Options for supporting various binary file formats. Enable ELF binary support. Enable support for DOS binaries to run under DOSEMU. Enable wrapper-driven binaries such as JavaT, Python, Emacs-Lisp. For a 64-bit system that supports 32-bit emulation, enable 32-bit binary support.
Networking	Enable basic sockets and TCP/IP networking, as well as packet filtering, bridging, routing, and support for a variety of protocols such as IPV6, IPX, Appletalk, and X.25. It's also optional to enable wireless, infrared, and amateur radio support here.
Device drivers	Enable support for most hardware devices, such as IDE/ATAPI or SCSI hard drives and flash memory devices, etc. It's best to enable DMA for the IDE devices, else they will work in the slower PIO mode. Enable support for multiple devices - RAID or LVM. Configure parallel port support, as well as parallel printer support. Configure a vast range networking devices to support the networking protocols that were configured above. Find support here for audio and video capture devices, USB and IEEE 1384 (Firewire) devices, and other hardware monitoring devices. Enable parallel print support and direct rendering support, located under character devices.
Firmware drivers	A few options related to BIOS setting and updating.
File systems	Configure the file systems that the kernel is to support - be they compiled in or modular. There are also file systems for removable media such as diskettes and CD or DVD devices. There is also support for networked file systems such as NFS, SMB, or CIFS, a variety of partitions and Native Language Support.
Instrumentation support	Enable experimental profiling support for profiling your system's activity.
Kernel hacking	Enable kernel debugging and choose which features will be enabled.
Security options	Configure several security options, enable and configure SELinux (Security Enhanced Linux).
Cryptographic options	Configure several cryptographic algorithms, such as MD4, DES, and SHA256.
Library routines	Decide whether certain CRC algorithms should be compiled in or built as modules.

Boot Loader Repair Top of Page

Listed below is the process used to repair the boot loaders in our dual-boot systems. The MBR is configured with Xfdisk - which is a boot loader configured to boot Windows or Linux, and the Linux boot partition is configured with the GRUB boot loader.

boot to rescue cd, or boot to install cd & go into rescue mode
if prompt provides the option, type 'linux rescue'
choose to skip media test when provided (if not needed)
language: english - leave at default
keyboard: us - leave at default
start network: not necessary
system will ask if the existing installation should be mounted? yes...continue - do not mount read only if changes are anticipated
the install will find & mount the filesystem... ok
chroot /mnt/sysimage
cd /boot/grub
enter the command 'fdisk -l' to get a listing of the current hard drive partitions - note that the partition listing scheme will be different in the 'fdisk' command (hda1, hda2, etc.) than it is in the 'grub' command ((hd0,0), (hd0,1), etc.) - make a note of the partitions as needed
enter the 'grub' command
at 'grub>' prompt, issue the following:
1. root (hd0,1) - or whichever partition the linux system is on
2. setup (hd0,1) - or whichever partition the linux bootloader is on
3. quit - gets out of the grub command sequence
4. for help while in the 'grub' command, type 'help', or 'help --all'
vi grub.conf - update changes as listed below
replace any instances that referred to the previous partition location with the new partition location (e.g. (hd0,0) to (hd0,1))
cd to the /etc/ directory
vi /etc/fstab - update changes as needed for mounted filesystems

There are instructions for creating and Linux boot disks in the Linux Installation document.

How to Change a Lost or Forgotten Root Password Top of Page

Yes, it happens. It happened to me, and it NEVER happens to ME! I lost or forgot the root password to my machine. All is not lost. If you're using the GRUB bootloader, perform the following steps:

Reboot the machine.
When the machine reboots, grab the boot sequence at the GRUB splash screen, and exercise the following iption.
Press 'e'. Select the line containing 'kernel', press 'e' again. You can then edit that line.
Append 'single' to the end of the line, press enter. GRUB will return you to the previous screen.
Press 'b' to boot the system into single user mode. The system will come up into a root shell.
Type 'passwd' and press enter. Go through the typical steps for changing the password.
Type "exit" and press enter, and the system will finish booting. That should do it.

Other Documents in this Series Top of Page

webpointmorpheus Home Technical Pages Site Map This page was last modified: Thursday June 07, 2007 10:23 AM

webpointmorpheus Linux Info The Linux Kerneland the Boot Process

webpointmorpheus Linux Info
The Linux Kernel
and the Boot Process