Should we change btrfs fsck in fstab?

Συνέχιση της συζήτησης από το Filesystem mounted at '/' is not responding , Plasma Workspace:

Archwiki suggests a fsck value of zero 0 for btrfs in fstab.

f the root file system is btrfs or XFS, the fsck order should be set to 0 instead of 1. See fsck.btrfs(8) and fsck.xfs(8).

From the fsck.btrfs man page:

Traditional filesystems need to run their respective fsck utility in case the filesystem was not unmounted cleanly and the log needs to be replayed before mount. This is not needed for BTRFS. You should set fs_passno to 0.

If you wish to check the consistency of a BTRFS filesystem or repair a damaged filesystem, see btrfs-check(8). By default filesystem consistency is checked, the repair mode is enabled via the --repair option (use with care!).

Any input on the subject is important, since this is a system critical modification (if we decide to apply it on Garuda systems and ISOs).

What are the effects we may have in other Garuda utilities/applications?


We don't have fsck enabled
You can check that
In mkinitcpio we don't have fsck in


There is also systemd that does fsck on boot.
As in the explanation:

Boot time checking


There are two players involved:

  1. mkinitcpio offers you the option to fsck your root file system before mounting it via the fsck hook. If you do this, you should mount root read-write via the appropriate rw kernel parameter.[1]
  2. systemd will fsck all file systems having a fsck pass number greater than 0 (either with #fstab options or a user-supplied unit file). For the root file system, it also has to be mounted read-only initially with the kernel parameter ro and only then remounted read-write from fstab (note that the defaults mount option implies rw).

The first option is the recommended default, and what you will end up with if you follow the Installation guide. If you want to go with option 2 instead, you should remove the fsck hook from mkinitcpio.conf and use ro on the kernel command-line. The kernel parameter fsck.mode=skip can be used to make sure fsck is disabled entirely for both options.


It should be 0 in fstab for btrfs filesystems.

That being said, unless it changed recently, fsck.btrfs does nothing useful and exits, returning success so it shouldn't be harmful, just pointless.

It is literally just this:

while getopts ":aApy" c
        case $c in
        a|A|p|y)        AUTO=true;;
shift $(($OPTIND - 1))
eval DEV=\${$#}
if [ ! -e $DEV ]; then
        echo "$0: $DEV does not exist"
        exit 8
if ! $AUTO; then
        echo "If you wish to check the consistency of a BTRFS filesystem or"
        echo "repair a damaged filesystem, see btrfs(8) subcommand 'check'."
exit 0

I understand, when using busybox init (not systemd) in mkinitcpio.conf, you add or exclude fsck from HOOKS to control disk checking. So when you don't add fsck (with busybox init), the rest of the file systems (not btrfs, added manually) will not be checked. This is something the (inexperienced) user will not know. This is something that the user should know, not left to believe Linux is safe as advertised :man_shrugging: .

Adding the proper fsck for btrfs in fstab, does no harm and lets us add fsck in mkinitcpio HOOKS, so all the rest fstab fsck directives are gone through.

1 Like

@librewish where do we we configure this? No sign of this in our Calamares configuration, which would be the preferred way to set this imo :thinking:

1 Like

If you are using stock Calamares, you need to customize the fstab module. It would be a pretty trivial change:

If you need help with that let me know.


Should be good like this? :eyes:

1 Like

I wouldn't hard set them to 0 in case a user adds a non-btrfs partition. You could do something like this:

        if mount_point == "/" and filesystem != "btrfs":
            check = 1
        elif mount_point and mount_point != "swap" and filesystem != "btrfs":
            check = 2
            check = 0

What type of coffee are you drinking @dalto?

You're sure pretty sharp for this early in the morning. It's only 7 am here and I'm still trying to get the sleep out of my eyes.

Nice revision.

:muscle: :wink: :coffee:



Sadly, I get up at 5am so by 7am I am mostly awake. :alarm_clock: :scream:

As someone who isn't a morning person, it is somewhat depressing but I have gotten used to it. :yawning_face:


Just pushed that to the repo, thanks for the help! :slight_smile:


Has this been tested prior to push?
Do we have such a feature :laughing:


I'm building a test iso right now :slight_smile:


Your a very good coder @petsam, does the code look problematic to you. My skills are rather basic, but the code looks fine to me. However, you are correct even the best of code can sometimes produce unexpected results. In @dalto 's case I have full confidence in his code as I have never seen him recommend something that wasn't 100% solid. However, I guess it' s possible there could always be a first time. :man_shrugging:

I trust @dalto 's code implicitly.


If I can help you test it let me know.


Because you know me better :grinning_face_with_smiling_eyes: , you should suspect that I don't do silly questions (such as wondering if a simple line of code, proposed from a known good coder is safe).
I just wanted to raise the real question :wink:

I could start a new topic though :grinning_face_with_smiling_eyes:


Here is the iso build with the changes if you want to run some tests yourself :wink:
I'm proceeding to test an installation with the default "erase disk" option in a VM.

What exactly do you mean by this?

1 Like

7 posts were split to a new topic: A standard procedure for testing ISOs