1. Introduction
In the world of Linux system administration, ensuring the integrity of a file system is crucial to maintaining the reliability and stability of a server. Periodically running a file system check (fsck) helps us detect and repair file system errors, preventing data loss and system crashes.
While Linux systems typically run fsck during boot when necessary, there may be situations where we want to force fsck to run at every reboot, regardless of the detected issues.
In this tutorial, we’ll look into how to configure Linux systems to perform a file system check on boot automatically.
2. Configuring Boot Parameters
First, let’s edit the GRUB (GRand Unified Bootloader) configuration file and add fsck parameters:
$ cat /etc/default/grub
...
GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 fsck.mode=force fsck.repair=yes"
GRUB_CMDLINE_LINUX=""
...
There are two parameters we’ll add to GRUB_CMDLINE_LINUX_DEFAULT to achieve our goal:
- fsck.mode=force – instructs the system to force a file system check on every boot
- fsck.repair=yes – directs fsck to automatically repair any file system errors it detects
Next, to make our changes take effect, we need to regenerate the GRUB configuration file. For Debian-based distributions like Ubuntu and Linux Mint, we can use update-grub:
$ sudo update-grub
For RHEL, CentOS, RockyLinux, Almalinux, and Fedora, we can use grub2-mkconfig:
$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Next, let’s configure our /etc/fstab file to enable fsck for our file systems.
3. Configuring Mount Parameters
In the /etc/fstab file, each line represents a filesystem entry, and the fs_passno field is the last numeric value in each entry.
We need to ensure this value is not 0 for any of the file systems we would like to check on boot. Additionally, we can control the order by specifying incremental integers for non-root file systems.
Let’s do this — we’ll use 1 for the root file system, and 2 for the non-root file systems we have:
# cat /etc/fstab
...
/dev/sda1 / xfs defaults 0 1
/dev/sdb1 /media ext4 default 0 2
...
This will ensure that the root file system is checked first and the non-root file system is checked second.
4. Verifying the Configuration
Once we’re done with the configuration, let’s reboot and verify that the file system check was done for each of our designated file systems.
After a reboot, let’s examine the logs for the systemd service systemd-fsck-root for the root partition, using the journalctl command:
$ journalctl -u systemd-fsck-root
...
Nov 10 07:36:43 ubuntu-xenial systemd-fsck[392]: /dev/sda1: clean, 60946/1280000 files, 321493/2621179 blocks
...
As we can see above, a file system check was performed on the root file system. However, it detected no errors.
For the non-root filesystems, systemd* will create a service for each file system according to the mount name defined in */etc/fstab. For example, as a test case, we’ll have a service named [email protected] corresponding to the mount point /dev/sdb1:
$ journalctl -u systemd-fsck@dev-sdb1
...
Nov 10 07:36:45 ubuntu-xenial systemd[1]: Starting File System Check on /dev/sdb1...
Nov 10 07:36:45 ubuntu-xenial systemd-fsck[636]: /dev/sdb1: clean, 11/131072 files, 9001/524032 blocks
Nov 10 07:36:45 ubuntu-xenial systemd[1]: Started File System Check on /dev/sdb1.
...
Occasionally, file system errors may occur. Consequently, we can observe how the repair process is carried out in the service logs:
$ journalctl -u systemd-fsck@dev-sdb1
...
Nov 10 07:48:14 localhost.localdomain systemd[1]: Starting File System Check on /dev/sdb1...
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: e2fsck 1.42.9 (28-Dec-2013)
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Superblock has an invalid journal (inode 8).
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Clear? yes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: *** ext3 journal has been deleted - filesystem is now ext2 only ***
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Resize inode not valid. Recreate? yes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Pass 1: Checking inodes, blocks, and sizes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Root inode is not a directory. Clear? yes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Pass 2: Checking directory structure
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Pass 3: Checking directory connectivity
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Root inode not allocated. Allocate? yes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: /lost+found not found. Create? yes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Pass 4: Checking reference counts
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Pass 5: Checking group summary information
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Block bitmap differences: +(0--8481) +(32768--33024) +(98304--98560) +(163840--164096) +(229376--229632) +(29
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Fix? yes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Recreate journal? yes
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: Creating journal (8192 blocks): Done.
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: *** journal has been re-created - filesystem is now ext3 again ***
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****
Nov 10 07:48:14 localhost.localdomain systemd-fsck[292]: /dev/sdb1: 11/131072 files (0.0% non-contiguous), 17961/524032 blocks
...
It’s important to note that while the fsck utility is a valuable tool for repairing common file system issues, it’s not able to rectify all types of file system errors. *Complex or severe problems, such as hardware failures or extensive data corruption, may be beyond the scope of fsck‘s capabilities*.
Consequently, it’s crucial that we maintain up-to-date backups of all critical data. Backups are an essential safeguard against the potential loss of data. Luckily, there are many tools available for Linux systems backup, both commercial and open-source.
5. Conclusion
In this article, we learned how to force a file system check upon every boot. Ensuring the integrity of our file system is paramount for maintaining the health and stability of a Linux server. By configuring our system to run fsck at every boot, we can proactively detect and rectify file system errors. This reduces the risk of data loss and system crashes.