Linux Tips: Find rootfs during system bootation

As a Linux administrator, you may encounter rootfs errors such as cannot mount rootfs and kernel panic after trying to restart the server after adding external storage volumes or even after installing a new Linux operating system. This article provides an overview of the Linux boot process on the x86 platform, shows you why this problem occurs, and provides four tips for avoiding or fixing this problem.
Overview of the problem

The root file system (named rootfs in the sample error message) is the most basic component of Linux. The root file system contains everything you need to support a full Linux system. It contains all applications, configurations, devices, data, and more. Without a root file system, your Linux system will not work.

After rebooting the system, you may encounter a mount rootfs error (after the Linux host gets the kernel panic). This problem often occurs after adding some storage volumes from external storage, or it may occur when file copying is completed and a reboot is required to complete the installation.

If this happens, your system will not restart. Diagnosing and fixing this problem takes time. The 4 tips presented in this article should help you solve problems and save time.

Another problem is that the Linux kernel needs to load the root filesystem, but it can't find the target device. In other words, the root file system does not appear where it should be. For example, you install the Linux root file system on the /dev/sda disk, but your system cannot mount it when it restarts. There are two possible reasons for this problem:

1. Disk /dev/sda is not displayed when the system is restarted.

The possible reason for this is that your Linux host does not have a critical drive that mounts the root file system. This may not be the case. The Linux installer will build all the required drives into the initrd image so that the Linux system can easily load the device drivers at boot time. However, this error can occur if you have manually installed the disk.

2. The disk /dev/sda is shown, but it is not the root file system. After the reboot, your root file system has been changed to /dev/sdb.

This is the most likely situation.

So, how is /dev/sda renamed to /dev/sdb after the system restarts? In Linux, /dev/sd* represents a SCSI device. Linux will change the names of these devices from sda to sdz (and sdaa to sdzz, and so on). It will name the first SCSI device /dev/sda, the second SCSI device /dev/sdb, and so on.

If you install a device in the adapter using a drive that was mounted before the root file system device adapter drive (initially at /dev/sda), the root file system will move to the next letter of the command chain (/dev/sdb), and the root file system is not the first device encountered. Therefore, if it can't find rootfs at the beginning of the line, it won't load.

This is a brief description of what happened, but to add more context to this scenario, let's outline the Linux boot process.

How Linux Booting Works

The following steps will outline how the Linux boot process works:

1. When the computer starts up The first test is the initial test POST (Power On Self Test), which will test multiple devices, including the processor, memory, graphics card and keyboard. In addition, boot media (hard disks, floppy disks, and CD-ROMs) will be tested. After POST, the loader in ROM will load the boot sector, which will then load the operating system from the active partition. You can change the boot media order by editing the server BIOS.

2. The boot sector is always in the same location — the track 0, cylinder 0, head 0 of the boot device. This sector contains a program called loader (usually LILO or GRUB for Linux); this program actually boots the operating system. The loader is either installed in the MBR or installed in the first sector of the active primary partition.

3. If multiple operating systems are installed on the server, you will need to select the operating system you want to boot from the bootloader menu. If you have multiple cores installed, you can also select which kernel to load from this menu.

4. Then, the bootloader will unzip and load the kernel. The kernel will first load the kernel module, then detect the hardware (floppy drive, hard drive, network adapter, etc.), verify the hardware configuration, and then scan and load the device drivers.

5. At this stage, the kernel will load the root file system and system files. The location of the system files can be configured (or by other programs) during recompilation. If the load fails, the kernel panic will appear and the system will freeze. This is the type of load failure mentioned earlier.

6. Next, the kernel will start the system initialization process init, which will become the first process. It will then start the rest of the system. The init process is the first process in Linux and is the parent of all other processes. This process is the first run in any Linux/UNIX® system; its PID is always 1.

7. Then, init will check the /etc/inittab file to determine which processes must be started. This file will provide init information about the runlevel and the processes that should be started at each runlevel. The init will then look for the first line with the sysinit (system initialization) operation and then execute the specified command file, such as /etc/rc.d/rc.sysinit in Red Hat Linux. After executing the script in /etc/rc.d/rc.sysinit, init will start the process associated with the initial runlevel. Linux will allow you to log in when the runlevel initial script is executed.

Each solution discussed will handle step 5 in this list.