1

Every time I boot/reboot my computer, it runs fsck, and I don't know why.

If I boot to a Ubuntu USB stick, and manually run fsck on my Linux partitions, it comes clean.

Below is my super-block. I've tried changing the "Maximum mount count" and the "Check interval" with no change in behaviour.

Any idea why this happens?

$ sudo tune2fs -l /dev/nvme0n1p6

tune2fs 1.47.0 (5-Feb-2023)
Filesystem volume name:   Ubuntu
Last mounted on:          /
Filesystem UUID:          f0db2226-e28d-46dd-9b5a-457c87987ed2
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              40845312
Block count:              163380224
Reserved block count:     8169011
Overhead clusters:        2844802
Free blocks:              57597994
Free inodes:              40012689
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              4
RAID stripe width:        32
Flex block group size:    16
Filesystem created:       Fri Sep 24 20:06:49 2021
Last mount time:          Sun Oct  6 17:47:34 2024
Last write time:          Sun Oct  6 18:01:39 2024
Mount count:              5
Maximum mount count:      23
Last checked:             Sun Oct  6 10:00:35 2024
Check interval:           0 (<none>)
Lifetime writes:          10 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
First orphan inode:       17714152
Default directory hash:   half_md4
Directory Hash Seed:      7e1d3c28-3106-4408-8132-4b574d84a675
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0xce551aef
heynnema
  • 73,649

1 Answers1

1

Turns out...

I have two disks. /dev/nvme0n1p6 is my boot partition. /dev/sda1 is my SSD backup disk. I assumed that the fsck at boot time was against my boot partition. I was wrong. It was against my SSD backup disk!

When performing a sudo tune2fs -l /dev/nvme0n1p6 or a sudo tune2fs -l /dev/sda1 the critical values to review are:

Mount count:              5
Maximum mount count:      23
Last checked:             Sun Oct  6 10:00:35 2024
Check interval:           0 (<none>)

  • when "Mount count" is greater than "Maximum mount count" then fsck will be run. The default value of "Maximum mount count" is equal to -1, so a fsck will not occur at each boot. To change the "Maximum mount count" use sudo tune2fs -c [random|some hard value] /dev/sda1.

    -c max-mount-counts
        Adjust the number of mounts after which the file system will  be
        checked  by  e2fsck(8).  If max-mount-counts is the string "ran‐
        dom", tune2fs will use a random value between  20  and  40.   If
        max-mount-counts is 0 or -1, the number of times the file system
        is mounted will be disregarded by e2fsck(8) and the kernel.

  • when "Check interval" is a non-zero value, then fsck will be run. The command to set interval is sudo tune2fs -i n[d|m|w] /dev/sda1.

    -i  interval-between-checks[d|m|w]
        Adjust the maximal time between two file system checks.  No suf‐
        fix or d will interpret the  number  interval-between-checks  as
        days, m as months, and w as weeks.  A value of zero will disable
        the time-dependent checking.

To fix my problem, I edited /etc/fstab such that the fsck (fs_passno) field for my SSD backup disk was changed from two to zero, so no boot time fsck will run.

Update:

Turns out... that the external USB-C SSD fsck's itself every boot time when it's connected to a native USB-C port, however, when it's connected to a USB-A port, using a USB-A to USB-C adapter, it doesn't fsck every boot. I changed /etc/fstab fs_passno back to 2.

Update #2:

Turns out... the Crucial external USB-C SSD needed a firmware update. After updating, I returned it to the original native USB-C port, and it all works fine now.

heynnema
  • 73,649