How to fsck root file system before boot or on reboot

Question

Today I went through my desktop stations running Linux Mint 17.3 Cinnamon and did a file system check of root partitions with Ext4 file systems as follows:

# fsck.ext4 -fn /dev/sdb2

The problem is that on all of the computers I see something similar to this one:

e2fsck 1.42.9 (4-Feb-2014)
Warning!  /dev/sdb2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 524292 has zero dtime.  Fix? no

Inodes that were part of a corrupted orphan linked list found.  Fix? no

Inode 524293 was part of the orphaned inode list.  IGNORED.
Inode 524294 was part of the orphaned inode list.  IGNORED.
Inode 524299 was part of the orphaned inode list.  IGNORED.
Inode 524300 was part of the orphaned inode list.  IGNORED.
Inode 524301 was part of the orphaned inode list.  IGNORED.
Inode 524302 was part of the orphaned inode list.  IGNORED.
Inode 524310 was part of the orphaned inode list.  IGNORED.
Inode 524321 was part of the orphaned inode list.  IGNORED.
Inode 524322 was part of the orphaned inode list.  IGNORED.
Inode 524325 was part of the orphaned inode list.  IGNORED.
Inode 2492565 was part of the orphaned inode list.  IGNORED.
Inode 2622677 was part of the orphaned inode list.  IGNORED.
Inode 2622678 was part of the orphaned inode list.  IGNORED.
Inode 2883748 was part of the orphaned inode list.  IGNORED.
Inode 2884069 was part of the orphaned inode list.  IGNORED.
Inode 2885175 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Entry 'Default_keyring.keyring' in /home/vlastimil/.local/share/keyrings (2495478) has deleted/unused inode 2498649.  Clear? no

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 2491790
Connect to /lost+found? no

Pass 5: Checking group summary information
Block bitmap differences:  -(34281--34303) -11650577 -(11650579--11650580) -11650591 -(11650594--11650595) -(13270059--13270073) -(13272582--13272583) -(20542474--20542475) +(26022912--26023347) -(26029568--26030003)
Fix? no

Free blocks count wrong (14476802, counted=14476694).
Fix? no

Inode bitmap differences:  -(524292--524294) -(524299--524302) -524310 -(524321--524322) -524325 +2491790 -2492565 -2498649 -(2622677--2622678) -2883748 -2884069 -2885175
Fix? no

Free inodes count wrong (7371936, counted=7371916).
Fix? no


/dev/sdb2: ********** WARNING: Filesystem still has errors **********

/dev/sdb2: 443232/7815168 files (0.1% non-contiguous), 16757502/31234304 blocks

What I have tried:

# touch /forcefsck

This results in a 2-3 seconds lasting check on startup. Obviously not repairing anything.

That is most probably because my root file system is somehow clean.

# fsck.ext4 -n /dev/sdb2

e2fsck 1.42.9 (4-Feb-2014)
Warning!  /dev/sdb2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sdb2: clean, 443232/7815168 files, 16757502/31234304 blocks

As I can't find almost anything for file system check on boot other than sudo touch /forcefsck, I tried these steps:

1. echo u > /proc/sysrq-trigger
2. umount /dev/sdb2
3. fsck -fy /dev/sdb2

This did show up that it had it repaired, to make sure I ran the fsck again without errors. BUT, they are back once I reboot. I am confused right now. Please don't instruct like "create a flash drive and boot from it and ...". I want a solution on reboot or before reboot without booting from some flash drives. Thank you.

Answer 1

First off, fsck'ing a mounted filesystem is expected to produce errors. The filesystem isn't consistent because the journal hasn't been replayed (nor has it been cleanly unmounted), and you can't replay the journal because that (like any other change) would corrupt the filesystem. If you're using LVM, you could take a snapshot and fsck the snapshot.

If you're on an SSD, fsck can be pretty fast. You could also try using tune2fs -C to set the mount count higher than the maximum (which you can get from dumpe2fs -h).

touch /forcefsck should work.

Editor's notes:

1. touch /forcefsck does not work.

2. Please refer to this answer for crystal clear evidence and a solution.

Answer 2

Linux Mint 17.3 is based on Ubuntu 14.04.

I suggest you try the standard Recovery menu which allows you to fsck drives.

Step-by-step guide taken from Mint 18.3, so it may be a little different as this version is based on Ubuntu 16.04:

1. In GRUB menu choose Advanced options for Linux Mint ...

2. You are greeted with 3 options, one of which has (recovery mode) at the end, choose this one.

3. Now, you have the option titled fsck with description:

   Check all file systems