Forcing an ext4 Filesystem Check on the Next Reboot with tune2fs

Sometimes you need to verify an ext4 filesystem, but the filesystem is mounted and cannot safely be repaired online. This is especially common when the filesystem is the root filesystem, such as /dev/md0 mounted as /.

Running fsck directly on a mounted filesystem is not a safe way to repair it:

1

sudo fsck -n -f /dev/md0

The -n option makes it read-only, so it will not fix anything. Also, because the filesystem is mounted, the result may be noisy or misleading. For a real repair check, fsck must run before the filesystem is mounted, usually during boot.

In practice, this can look like a false positive: a full check during early boot or single-user/rescue mode may report the filesystem as clean, while fsck -n on the same filesystem after it is mounted may still show apparent errors. That does not necessarily mean the boot-time check failed. It usually means the mounted filesystem is changing while fsck is looking at it, and read-only fsck -n also skips journal recovery.

Force fsck on the Next Boot

For ext2/ext3/ext4 filesystems, you can use tune2fs to change the mount counters:

1

sudo tune2fs -c 30 -C 31 /dev/md0

This sets two ext4 metadata values:

• -c 30 sets the maximum mount count to 30
• -C 31 sets the current mount count to 31

Since 31 is greater than 30, the system should consider the filesystem due for checking on the next mount.

After running the command, reboot:

1

sudo reboot

Check the Current ext4 fsck Counters

You can inspect the relevant ext4 metadata with:

1

sudo tune2fs -l /dev/md0 | egrep 'Mount count|Maximum mount count|Last checked|Check interval|Filesystem state'

Example output after a successful boot-time check:

1
2
3
4
5

Filesystem state:         clean
Mount count:              1
Maximum mount count:      30
Last checked:             Mon Jun  1 21:36:30 2026
Check interval:           0 (<none>)

The important lines are:

1
2
3
4

Filesystem state: clean
Last checked:     Mon Jun  1 21:36:30 2026
Mount count:      1
Maximum mount count: 30

This means the filesystem was checked, is currently clean, and the mount counter was reset.

What Do 30 and 31 Mean?

The numbers are not magic.

ext4 stores a mount counter inside the filesystem metadata:

1
2

Mount count
Maximum mount count

Mount count is the number of times the filesystem has been mounted since the last successful check.

Maximum mount count is the threshold after which the filesystem should be checked again.

So this command:

1

sudo tune2fs -c 30 -C 31 /dev/md0

means:

1
2

Maximum mount count = 30
Current mount count = 31

Because the current count is already above the maximum, the next boot should trigger fsck.

After a successful check, the mount count is normally reset. Then, after about 30 future mounts, the filesystem will be checked again.

Forcing fsck with Kernel Parameters

On systemd-based systems, especially for the root filesystem, you may also see boot parameters like this:

1

fsck.mode=force fsck.repair=yes

You can confirm the active kernel command line with:

1

cat /proc/cmdline

Example:

1

BOOT_IMAGE=/boot/vmlinuz-5.15.158-2-pve root=UUID=41ea7c87-7a35-4c0a-8aa9-288fe56a10a1 ro quiet fsck.mode=force fsck.repair=yes

These options tell systemd/initramfs to force filesystem checks and automatically repair safe issues.

Checking the Boot Logs

For non-root filesystems, this may show useful output:

1

journalctl -b -u systemd-fsck-root.service --no-pager

However, for the root filesystem, the check often happens inside the initramfs before the normal system journal is fully available. In that case, this command may show:

1

-- No entries --

That does not necessarily mean fsck did not run.

A broader journal search may still show related boot activity:

1

journalctl -b | grep -Ei 'fsck|e2fsck|systemd-fsck|recover|orphan|md0'

Example output:

1
2
3
4
5
6

Jun 01 21:18:59 robi kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.158-2-pve root=UUID=41ea7c87-7a35-4c0a-8aa9-288fe56a10a1 ro quiet fsck.mode=force fsck.repair=yes
Jun 01 21:18:59 robi kernel: md/raid1:md0: active with 2 out of 2 mirrors
Jun 01 21:18:59 robi kernel: EXT4-fs (md0): mounted filesystem with ordered data mode
Jun 01 21:18:59 robi systemd[1]: Created slice system-systemd\x2dfsck.slice.
Jun 01 21:18:59 robi systemd[1]: Listening on fsck to fsckd communication Socket.
Jun 01 21:19:31 robi systemd[1]: systemd-fsckd.service: Succeeded.

For root filesystem checks, the most useful log is often:

1

sudo cat /run/initramfs/fsck.log

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Log of fsck -C -f -y -T -t ext4 /dev/md0
Mon Jun  1 18:18:54 2026

e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md0: 118313/6103040 files (0.5% non-contiguous), 12418499/24397312 blocks

This confirms that fsck actually ran on /dev/md0 during early boot.

Do Not Trust fsck -n on a Mounted Root Filesystem Too Much

If you run:

1

sudo fsck -n -f /dev/md0

while /dev/md0 is mounted as /, you may see warnings like:

1
2

Warning! /dev/md0 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.

That mode is useful for a rough diagnostic, but it is not a reliable final verdict. The real check should happen before the filesystem is mounted.

The better confirmation is:

1

sudo tune2fs -l /dev/md0 | egrep 'Mount count|Maximum mount count|Last checked|Check interval|Filesystem state'

And optionally:

1

sudo cat /run/initramfs/fsck.log

Disabling Periodic Mount-Count Checks Again

If you only wanted a one-time check and do not want ext4 to keep checking every 30 mounts, you can disable the mount-count and interval-based checks again:

1

sudo tune2fs -c -1 -i 0 /dev/md0

This restores behavior like:

1
2

Maximum mount count:      -1
Check interval:           0 (<none>)

Notes and Caution

Only use this method for ext2/ext3/ext4 filesystems. It does not apply to filesystems like XFS, Btrfs, ZFS, or FAT.

If the filesystem is the root filesystem and the server is remote, make sure you have some kind of recovery access before forcing repairs. If fsck encounters a problem that cannot be fixed automatically, the system may stop in rescue or emergency mode, and SSH may not come up.

For a clean result, the target state should look like this:

1
2
3

Filesystem state: clean
Last checked:     recent boot time
Mount count:      low number, usually 0 or 1 after reboot