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
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.