As a system administrator we should be very much cautions about data protection from unexpected events. These events include file system corruption as well. File system corruptions are caused due to many reasons, one reason is power interruptions. When you have critical systems, it is always advisable to check file system for errors and fix them regularly or at least at boot time. In this post we will see how to set those settings which will help us to fix file system errors at boot time without manual intervention. The settings for this file check is bit different in Redhat and Debian based machines though they use same fsck command to fix it.
Enable FSCK at boot time on Debian based machine
Give below entries in the file /etc/default/rcS and save the file. FSCKFIX=yes
Enable FSCK at boot time for Redhat based machines
To do this we have two options
1)Temporary do this for next boot
2)A permanent way to do fsck for every reboot
Temporary way: Just create a file in / as forcefsck.
This is just an empty file which make system to trigger file system check at next boot. This file helps the system to check for errors for the next boot and it will be removed once the file system is checked for errors. If you want to make sure file system check done for every reboot then we have to follow a permanent solution as given below.
A permanent way: Edit file /etc/sysconfig/autofsck with following content
Once this is done, just check if file system check is enabled in next boot or not using dumpe2fs or tune2fs commands as shown below.
tune2fs -l /dev/sda1
dumpe2fs -h /dev/sda1
root@linuxnix:/home/taggle# dumpe2fs -h /dev/sda1 dumpe2fs 1.41.11 (14-Mar-2010) Filesystem volume name: boot Last mounted on: / Filesystem UUID: 3a7c5863-e00c-49e2-a838-1742de53ebce Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: journal_data_writeback Filesystem state: not clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 122160 Block count: 487936 Reserved block count: 24396 Free blocks: 206546 Free inodes: 65869 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 119 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8144 Inode blocks per group: 509 Flex block group size: 16 Filesystem created: Wed Dec 29 09:36:59 2010 Last mount time: Fri Oct 16 16:37:51 2015 Last write time: Tue Feb 11:30:47 2015 Mount count: 3 Maximum mount count: 23 Last checked: Fri Oct 16 09:52:33 2015 Check interval: 15552000 (6 months) Next check after: Tue Feb 23 11:52:33 2016 Lifetime writes: 493 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Default directory hash: half_md4 Directory Hash Seed: ea221eae-0fc0-4154-b587-374e033882b1 Journal backup: inode blocks0
From the above output we can see “Next check after” is set to Tue Feb 23 11:52:33 2016 Which indicates there is a check schedule for next boot.
Latest posts by Surendra Anne (see all)
- Docker: How to copy files to/from docker container - June 30, 2020
- Anisble: ERROR! unexpected parameter type in action:
Fix- June 29, 2020
- FREE: JOIN OUR DEVOPS TELEGRAM GROUPS - August 2, 2019
- Review: Whizlabs Practice Tests for AWS Certified Solutions Architect Professional (CSAP) - August 27, 2018
- How to use ohai/chef-shell to get node attributes - July 19, 2018