# Forcing an ext4 filesystem check on the next reboot


# 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:

```bash
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:

```bash
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:

```bash
sudo reboot
```

## Check the Current ext4 fsck Counters

You can inspect the relevant ext4 metadata with:

```bash
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:

```text
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:

```text
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:

```text
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:

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

means:

```text
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:

```text
fsck.mode=force fsck.repair=yes
```

You can confirm the active kernel command line with:

```bash
cat /proc/cmdline
```

Example:

```text
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:

```bash
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:

```text
-- No entries --
```

That does not necessarily mean fsck did not run.

A broader journal search may still show related boot activity:

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

Example output:

```text
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:

```bash
sudo cat /run/initramfs/fsck.log
```

Example:

```text
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:

```bash
sudo fsck -n -f /dev/md0
```

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

```text
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:

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

And optionally:

```bash
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:

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

This restores behavior like:

```text
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:

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