Like any operating system, Linux comes with sets of utilities that are designed to automatically repair common problems when the system verifies its state as part of the boot process. Ignoring hardware failure, which usually has a simple solution, the most common types of problems that can prevent a Linux system from booting successfully are problems related to the boot process itself or self-test problems that either prevent the system from running the self-tests or from restoring itself to a consistent state.

Some classic examples of things that can induce boot problems are missing or damaged disk blocks (such as the master boot record--MBR), missing files required by the boot loader (LILO or GRUB), bad or incorrectly updated boot loader configuration information, or a bad or missing kernel.

Assuming that the kernel and boot loader files themselves are present and consistent, errors in the /boot or / filesystems can prevent the root or /boot filesystems from being correctly identified, located, or mounted. As part of the boot process for most Linux systems, the system startup scripts verify the state of a flag in the filesystem header that identifies whether the filesystem was unmounted cleanly the last time that the system booted. Most types of filesystem corruption can be handled during the boot process, but corruption that affects the system boot scripts or the fsck utility itself can leave you with a system that "almost" boots--which is a million virtual miles from one that boots successfully.

As mentioned in the introduction to this article, different types of rescue disks have different capabilities. At the low end of the rescue spectrum, some of these simply provide a boot block and kernel that lets you mount an existing and consistent root filesystem. At the high end of the spectrum are rescue disks that provide full-blown tool sets that provide replacement tools that enable you to repair almost every type of disk corruption.

Next: Common Rescue/Recovery Scenarios »