fs_passno is written as 0, 0 by default.

[Scott Moser]

In investigating cloud-init bug 1717477 and wondering why our vmtest didn't have this problem, Ryan found that we set 'fs_freq' and 'fs_pass' entries to '0 0' in our /etc/fstab lines.

0 means "do not fsck" which can't really be good for long lived systems.

Per fstab(5):

The fifth field (fs_freq).
 This field is used by dump(8) to determine which filesystems need
 to be dumped. Defaults to zero (don't dump) if not present.

The sixth field (fs_passno).
 This field is used by fsck(8) to determine the order in which
 filesystem checks are done at boot time. The root filesystem
 should be specified with a fs_passno of 1. Other filesystems
 should have a fs_passno of 2. Filesystems within a drive will be
 checked sequentially, but filesystems on different drives will be
 checked at the same time to utilize parallelism available in the
 hardware. Defaults to zero (don't fsck) if not present.

[James Troup (elmo)]

For the benefit of future travellers this can very easily break kernel-crash-dump, as the environment that you kexec into on crash respects fs_pass, even for / and so if the crash caused any FS inconsistency, the crash dump fails.

[Dan Bungert (dbungert)]

This bug is believed to be fixed in curtin in version 21.3. If this is still a problem for you, please make a comment and set the state back to New

Thank you.