fs_passno is written as 0, 0 by default.

Bug #1717584 reported by Scott Moser on 2017-09-15
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
curtin
Medium
Dan Bungert

Bug Description

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.

Scott Moser (smoser) on 2017-10-02
Changed in curtin:
status: New → Confirmed
importance: Undecided → Medium
tags: added: fr-1170
James Troup (elmo) wrote :

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) on 2021-03-16
Changed in curtin:
assignee: nobody → Dan Bungert (dbungert)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers