File System Check on Root Device was skipped because of an unmet condition check ConditionPathIsReadWrite

dmesg shows

[    2.236438] systemd[1]: File System Check on Root Device was 
skipped because of an unmet condition check 
(ConditionPathIsReadWrite=!/).

So, I booted from usb, run fsck -f and it said use btrfs check, so I did btrfs --repair check /dev/sdb1 But it showed no errors.

dmesg still shows the same message. Should I care?

It looks to me as if I had wrong permissions in my root filesystem. Am I correct?

I have never read something like this.

Yes
I think you should investigate why (ConditionPathIsReadWrite=!/). fails

If your btrfs filesystem is readonly there is something wrong.
My dmesg says:

sudo dmesg|grep 'condition'    

[    4.401811] systemd[1]: TPM2 PCR Barrier (initrd) was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
[   12.071440] systemd[1]: TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/StubPcrKernelImage-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f).
[   12.334567] systemd[1]: Repartition Root Disk was skipped because no trigger condition checks were met.
[   13.641033] systemd[1]: First Boot Wizard was skipped because of an unmet condition check (ConditionFirstBoot=yes).
[   13.641670] systemd[1]: Rebuild Hardware Database was skipped because of an unmet condition check (ConditionNeedsUpdate=/etc).
[   13.667130] systemd[1]: Create System Users was skipped because no trigger condition checks were met.
[   13.707119] systemd[1]: First Boot Complete was skipped because of an unmet condition check (ConditionFirstBoot=yes).
[   13.777198] systemd[1]: Virtual Machine and Container Storage (Compatibility) was skipped because of an unmet condition check (ConditionPathExists=/var/lib/machines.raw).
[   13.777218] systemd[1]: Entropy Daemon based on the HAVEGE algorithm was skipped because of an unmet condition check (ConditionKernelVersion=<5.6).

This seems to be a trivial message from systemd
I would not worry :wink:

Can you try to check the filesystem with the Manjaro USB stick ?

Looks like this is very complex issue described here

But I don’t know what should be the proper solution for btrfs.

My /etc/grub.d/10_linux looks a bit diffrent so I don’t know how to apply the solution proposed in post 21

I have:

  if [ "x${GRUB_ROOT_FS_RO}" = "xtrue" ]; then
    grub_root_fs_mode=ro
  else
    grub_root_fs_mode=rw
  fi
journalctl -t systemd-fsck
-- No entries --

systemctl status systemd-fsck-root.service
â—‹ systemd-fsck-root.service - File System Check on Root Device
     Loaded: loaded (/usr/lib/systemd/system/systemd-fsck-root.service; enabled-runtime; preset: disabled)
     Active: inactive (dead)
  Condition: start condition failed at Tue 2023-06-20 08:26:04 CEST; 1h 4min ago
             └─ ConditionPathIsReadWrite=!/ was not met
       Docs: man:systemd-fsck-root.service(8)

@Yochanan @Ste74
As you participated in that discussion could you please tell me what to do?

Set in /etc/default/grub → GRUB_ROOT_FS_RO=true so that systemd-fsck can run. Otherwise, it will be checked on a fsck hook → see /etc/mkinitcpio.conf and the systemd message can be ignored.

Anyway… btrfs is a self-healing file system and if you want to check the data and correct them, then use btrfs scrub. Actually scrubbing means just verify the checksums, since BTRFS is a COW file systems, there are usually more than one copy of the file. It doesn’t delete old files, but releases them for overwriting. When the scrub works, it will verify the data and when it opens a file, it verifies and correct the file by itself. Sure, on BTRFS built-in RAID Setup, it works safer, but even if you only have one disk, it also works with “dead files”, which are still known. Therefore, scrub is usually enough in most cases.

btrfs check is only needed in very rare cases and can produce more problems than needed.

The best way to deal with btrfs is disabling fsck check. That can be done in /etc/fstab and replace the number at the end of each line with 0 0. Just scrub the file system once a month, that’s enough for causal users.

2 Likes