You are not logged in.

#1 2022-04-20 01:40:30

dawnofman
Member
Registered: 2019-07-26
Posts: 140

[solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

I just upgraded to 5.17.3 on my first BTRFS setup with the following /etc/fstab:

PARTUUID=eca82c38-b61e-4800-a15b-3eadc552d8b3 /boot vfat fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,rw,noatime 0 2

PARTUUID=c195aefd-3769-4fc7-8fec-86a935552eb0 / btrfs commit=30,ssd,space_cache=v2,compress=zstd,rw,noatime,subvolid=256,subvol=/ 0 0
PARTUUID=c195aefd-3769-4fc7-8fec-86a935552eb0 /var btrfs commit=30,ssd,space_cache=v2,compress=zstd,rw,noatime,subvolid=257,subvol=/sub-volume-data 0 0
PARTUUID=c195aefd-3769-4fc7-8fec-86a935552eb0 /tmp btrfs commit=30,ssd,space_cache=v2,compress=zstd,rw,noatime,subvolid=258,subvol=/sub-volume-temp 0 0
PARTUUID=c195aefd-3769-4fc7-8fec-86a935552eb0 /root btrfs commit=30,ssd,space_cache=v2,compress=zstd,rw,noatime,subvolid=259,subvol=/sub-volume-homeroot 0 0
PARTUUID=c195aefd-3769-4fc7-8fec-86a935552eb0 /home btrfs commit=30,ssd,space_cache=v2,compress=zstd,rw,noatime,subvolid=260,subvol=/sub-volume-home 0 0

PARTUUID=e588a3c0-7664-41c3-b8f1-44ecafb76051 /data ext4 rw,noatime 0 2

tmpfs /tmp-workspace tmpfs nodev,nosuid,uid=root,gid=root,mode=1777,size=8G,rw,relatime 0 0

As you can see above my system partition (...86a935552eb0) is a BTRFS one with many sub-volumes: all have fsck disabled; ie: 0

Upon rebooting I can see in journalctl --boot output that systemd ignores the fsck=0 entry in my /etc/fstab and triggers systemd-fsck -> /usr/local/bin/fsck.btrfs:

2022-04-19T22:05:24.519871-0300 archlinux systemd-fsck[442]: fsck: /usr/local/bin/fsck.btrfs: execute failed: No such file or directory
2022-04-19T22:05:24.520221-0300 archlinux systemd-fsck[440]: fsck failed with exit status 8.
2022-04-19T22:05:24.520231-0300 archlinux systemd-fsck[440]: Ignoring error.
2022-04-19T22:05:24.515000-0300 archlinux audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck-root comm="systemd" exe="/init" hostname=? addr=? terminal=? res=success'
2022-04-19T22:05:24.522443-0300 archlinux kernel: audit: type=1130 audit(1650416724.515:5): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck-root comm="systemd" exe="/init" hostname=? addr=? terminal=? res=success'
2022-04-19T22:05:25.139826-0300 noname systemd[1]: Created slice Slice /system/systemd-fsck.
2022-04-19T22:05:25.140568-0300 noname systemd[1]: systemd-fsck-root.service: Deactivated successfully.
2022-04-19T22:05:25.109000-0300 noname audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck-root comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
2022-04-19T22:05:25.215000-0300 noname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2dpartuuid-b0d30f73\x2db2c2\x2d4973\x2da454\x2dcdc42e2fda83 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
2022-04-19T22:05:25.219000-0300 noname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2dpartuuid-e588a3c0\x2d7664\x2d41c3\x2db8f1\x2d44ecafb76051 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
2022-04-19T22:05:25.242000-0300 noname audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-fsck@dev-disk-by\x2dpartuuid-eca82c38\x2db61e\x2d4800\x2da15b\x2d3eadc552d8b3 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
2022-04-19T22:05:25.323587-0300 noname systemd-fsck[553]: /dev/sdc1: clean, 27475/9773056 files, 28014063/39072209 blocks
2022-04-19T22:05:25.323782-0300 noname systemd-fsck[555]: fsck.fat 4.2 (2021-01-31)
2022-04-19T22:05:25.323782-0300 noname systemd-fsck[555]: /dev/sdd1: 34 files, 15131/261599 clusters
2022-04-19T22:05:25.324085-0300 noname systemd-fsck[551]: /dev/sdb1: clean, 14968/9773056 files, 12533075/39072209 blocks

The fstab entry on our wiki is clear about the value of fsck (bold text mine):

<fsck> sets the order for file system checks at boot time; see fsck(8). For the root device it should be 1. For other partitions it should be 2, or 0 to disable checking.

Tip:

    The auto type lets the mount command guess what type of file system is used. This is useful for optical media (CD/DVD/Blu-ray).
    If 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).

Last edited by dawnofman (2022-04-26 18:27:40)

Offline

#2 2022-04-20 08:55:10

Raynman
Member
Registered: 2011-10-22
Posts: 1,539

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

That seems to come from the initramfs; fsck based on fstab values comes later (apparently when your hostname has changed to "noname").

If it exists, fsck.btrfs should just exit successfully without doing anything. You could also remove the (mkinitcpio) fsck hook; I tried that and then systemd-fsck says something like "fsck.btrfs doesn't exists, not checking file system". You seem to have something in between.

If you just want this to go away and are not determined to get to the bottom of the (possibly one-time) issue, I would regenerate the initramfs (mkinitcpio -P) and reboot to see if it goes away. Otherwise, start by checking/posting /etc/mkinitcpio.conf and maybe also the contents of the initramfs using lsinitcpio.

Last edited by Raynman (2022-04-20 08:55:59)

Offline

#3 2022-04-20 15:53:26

loqs
Member
Registered: 2014-03-06
Posts: 18,969

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

2022-04-19T22:05:24.520221-0300 archlinux systemd-fsck[440]: fsck failed with exit status 8.

Exit code 8 from:

cat /usr/bin/fsck.btrfs 
#!/bin/sh -f
#
# Copyright (c) 2013 SUSE
#
# copied from fsck.xfs
# Copyright (c) 2006 Silicon Graphics, Inc.  All Rights Reserved.
#

# fsck.btrfs is a type of utility that should exist for any filesystem and is
# called during system setup when the corresponding /etc/fstab entries contain
# non-zero value for fs_passno. (See fstab(5) for more.)
#
# 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(8) subcommand 'check'. By default the
# filesystem consistency is checked, the repair mode is enabled via --repair
# option (use with care!).

AUTO=false
while getopts ":aApy" c
do
	case $c in
	a|A|p|y)	AUTO=true;;
	esac
done
shift $(($OPTIND - 1))
eval DEV=\${$#}
if [ ! -e $DEV ]; then
	echo "$0: $DEV does not exist"
	exit 8
fi
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'."
fi
exit 0

The script could not find the root device node.

Offline

#4 2022-04-20 15:55:22

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

Raynman wrote:

That seems to come from the initramfs; fsck based on fstab values comes later (apparently when your hostname has changed to "noname").

If it exists, fsck.btrfs should just exit successfully without doing anything. You could also remove the (mkinitcpio) fsck hook; I tried that and then systemd-fsck says something like "fsck.btrfs doesn't exists, not checking file system". You seem to have something in between.

... from my related EFI entry in the boot partition (no fsck option here):

options root=PARTUUID=c195aefd-3769-4fc7-8fec-86a935552eb0 ro ipv6.disable_ipv6=1

... from my /etc/mkinitcpio.conf (fsck option here):

HOOKS=(systemd autodetect modconf block filesystems keyboard numlock fsck)

Honestly, I completely forgot about this one being pre-FSTAB. So systemd-fsck starts because I specifically told so and then I forgot about it and then I complained about it, so it all ends in me being a bit stupid.

Questions:

- Is there anyway to configure systemd-fsck to not check BTRFS volumes (like FSTAB) ?

- Or by the way to check/not-check the ones we want to ?

PS: Although systemd-fsck -> btrfs is exiting without doing nothing (ie: not harmful at all) I would like it not being started at all so I do not have to see the associated red lines in journalctl; the less red lines there the more I can concentrate on real issues being colored red.

Offline

#5 2022-04-20 15:59:08

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

loqs wrote:
2022-04-19T22:05:24.520221-0300 archlinux systemd-fsck[440]: fsck failed with exit status 8.

Exit code 8 from:

cat /usr/bin/fsck.btrfs 
#!/bin/sh -f
#
# Copyright (c) 2013 SUSE
#
# copied from fsck.xfs
# Copyright (c) 2006 Silicon Graphics, Inc.  All Rights Reserved.
#

# fsck.btrfs is a type of utility that should exist for any filesystem and is
# called during system setup when the corresponding /etc/fstab entries contain
# non-zero value for fs_passno. (See fstab(5) for more.)
#
# 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(8) subcommand 'check'. By default the
# filesystem consistency is checked, the repair mode is enabled via --repair
# option (use with care!).

AUTO=false
while getopts ":aApy" c
do
	case $c in
	a|A|p|y)	AUTO=true;;
	esac
done
shift $(($OPTIND - 1))
eval DEV=\${$#}
if [ ! -e $DEV ]; then
	echo "$0: $DEV does not exist"
	exit 8
fi
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'."
fi
exit 0

The script could not find the root device node.

From previous post (bold text mine):

Raynman wrote:

That seems to come from the initramfs; fsck based on fstab values comes later (apparently when your hostname has changed to "noname").

Offline

#6 2022-04-20 16:14:21

loqs
Member
Registered: 2014-03-06
Posts: 18,969

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

dawnofman wrote:
Raynman wrote:

That seems to come from the initramfs; fsck based on fstab values comes later (apparently when your hostname has changed to "noname").

I do not understand why you are emphasizing that the fstab is not used.  I did not indicate it was,  the script is in the initrd,  it receives the device node from systemd-fsck which will have obtained it from kernel parameters or possibly GPT parser.

Offline

#7 2022-04-20 16:24:34

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

loqs wrote:
dawnofman wrote:
Raynman wrote:

That seems to come from the initramfs; fsck based on fstab values comes later (apparently when your hostname has changed to "noname").

I do not understand why you are emphasizing that the fstab is not used.  I did not indicate it was,  the script is in the initrd,  it receives the device node from systemd-fsck which will have obtained it from kernel parameters or possibly GPT parser.

I am telling you just what I've been told by Raynman, you both are almost-sure more knowledgeable than me on the matter. I am in no position to tell anybody.

Offline

#8 2022-04-20 16:56:53

Raynman
Member
Registered: 2011-10-22
Posts: 1,539

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

I also don't understand why you are quoting my post like that.

dawnofman wrote:

Questions:

- Is there anyway to configure systemd-fsck to not check BTRFS volumes (like FSTAB) ?

- Or by the way to check/not-check the ones we want to ?

PS: Although systemd-fsck -> btrfs is exiting without doing nothing (ie: not harmful at all) I would like it not being started at all so I do not have to see the associated red lines in journalctl; the less red lines there the more I can concentrate on real issues being colored red.

The only documented purpose of the fsck hook in mkinitcpio is to check the root device. If the root device is btrfs and thus doesn't need to be checked, you can disable/remove the fsck hook (or use fsck.mode=skip). But normally, the script (shown by loqs) should go to the last line with 'exit 0' -- not doing anything and also not causing any red lines in the journal.

loqs seems to think the script was executed and returned 8. We don't see the result of the echo in that if branch, but I suppose that could've been swallowed by systemd-fsck or you left it out when copying the journal. However,  that IMHO doesn't really explain the "execute failed: No such file or directory" and, checking the source for systemd-fsck, it only calls the fsck(8) frontend, so I think fsck fails to find fsck.btrfs and reports this by returning 8, which according to the man page indicates an operational error. Hence my suggestion to inspect the initramfs with lsinitcpio, to see if fsck.btrfs is there or not.

Last edited by Raynman (2022-04-20 17:02:21)

Offline

#9 2022-04-20 18:22:51

loqs
Member
Registered: 2014-03-06
Posts: 18,969

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

Can you post the full system journal for a boot along with the lsinitcpio results.

Offline

#10 2022-04-21 01:15:04

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

Raynman wrote:

I also don't understand why you are quoting my post like that.

First and foremost sorry if I did anything wrong. ALthough I am replying here to you this goes for both of you. Maybe I understood something wrong and so I quoted the wrong way. Sorry again.

Raynman wrote:

The only documented purpose of the fsck hook in mkinitcpio is to check the root device. If the root device is btrfs and thus doesn't need to be checked, you can disable/remove the fsck hook (or use fsck.mode=skip).

ACK. I didn't know it was only for the root device. It was there from my previous EXT4 root device so it is going away (or maybe fsck.mode=skip just to remember if I ended going back to EXT4 or anything else).

Raynman wrote:

But normally, the script (shown by loqs) should go to the last line with 'exit 0' -- not doing anything and also not causing any red lines in the journal. loqs seems to think the script was executed and returned 8. We don't see the result of the echo in that if branch, but I suppose that could've been swallowed by systemd-fsck or you left it out when copying the journal.

It seems loqs is right: "fsck failed with exit status 8" (this line is a red-one):

2022-04-19T22:05:23.822083-0300 archlinux kernel: Linux version 5.17.3-arch1-1 (linux@archlinux) (gcc (GCC) 11.2.0, GNU ld (GNU Binutils) 2.38) #1 SMP PREEMPT Thu, 14 Apr 2022 01:18:36 +0000
2022-04-19T22:05:23.822130-0300 archlinux kernel: Command line: initrd=\EFI\boot-OS-arch-linux\ucode-intel.img initrd=\EFI\boot-OS-arch-linux\initramfs-linux.img root=PARTUUID=c195aefd-3769-4fc7-8fec
...
2022-04-19T22:05:24.504589-0300 archlinux systemd[1]: Found device HUSSL4010BSS600 system-NIX.
2022-04-19T22:05:24.504839-0300 archlinux systemd[1]: Reached target Initrd Root Device.
2022-04-19T22:05:24.506441-0300 archlinux systemd[1]: Starting File System Check on /dev/disk/by-partuuid/c195aefd-3769-4fc7-8fec-86a935552eb0...
2022-04-19T22:05:24.519871-0300 archlinux systemd-fsck[442]: fsck: /usr/local/bin/fsck.btrfs: execute failed: No such file or directory
2022-04-19T22:05:24.520221-0300 archlinux systemd-fsck[440]: fsck failed with exit status 8.
2022-04-19T22:05:24.520231-0300 archlinux systemd-fsck[440]: Ignoring error.
2022-04-19T22:05:24.521063-0300 archlinux systemd[1]: Finished File System Check on /dev/disk/by-partuuid/c195aefd-3769-4fc7-8fec-86a935552eb0.
...
Raynman wrote:

However,  that IMHO doesn't really explain the "execute failed: No such file or directory" and, checking the source for systemd-fsck, it only calls the fsck(8) frontend, so I think fsck fails to find fsck.btrfs and reports this by returning 8, which according to the man page indicates an operational error. Hence my suggestion to inspect the initramfs with lsinitcpio, to see if fsck.btrfs is there or not.

It is there: usr/bin/fsck.btrfs

lsinitcpio /boot/EFI/boot-OS-arch-linux/initramrs-linux.img;

bin
buildconfig
config
dev/
etc/
etc/fstab
etc/group
etc/initrd-release
etc/ld.so.cache
etc/ld.so.conf
etc/modprobe.d/
etc/modules-load.d/
etc/modules-load.d/MODULES.conf
etc/mtab
etc/nsswitch.conf
etc/passwd
etc/shadow
hooks/
hooks/numlock
init
lib
lib64
new_root/
proc/
run/
sbin
sys/
tmp/
usr/
usr/bin/
usr/bin/fsck
usr/bin/fsck.btrfs
usr/bin/journalctl
usr/bin/kmod
usr/bin/modprobe
usr/bin/mount
usr/bin/setleds
usr/bin/sulogin
usr/bin/systemctl
usr/bin/systemd-tmpfiles
usr/bin/udevadm
usr/bin/umount
usr/lib/
usr/lib64
usr/lib/ld-linux-x86-64.so.2
usr/lib/libacl.so.1
usr/lib/libaudit.so.1
usr/lib/libblkid.so.1
usr/lib/libcap-ng.so.0
usr/lib/libcap.so.2
usr/lib/libcrypto.so.1.1
usr/lib/libcrypt.so.2
usr/lib/libc.so.6
usr/lib/libdl.so.2
usr/lib/libffi.so.8
usr/lib/libgcc_s.so.1
usr/lib/libgcrypt.so.20
usr/lib/libgpg-error.so.0
usr/lib/libip4tc.so.2
usr/lib/libkmod.so.2
usr/lib/liblz4.so.1
usr/lib/liblzma.so.5
usr/lib/libmount.so.1
usr/lib/libm.so.6
usr/lib/libp11-kit.so.0
usr/lib/libpam.so.0
usr/lib/libpthread.so.0
usr/lib/libseccomp.so.2
usr/lib/libz.so.1
usr/lib/libzstd.so.1
usr/lib/modprobe.d/
usr/lib/modprobe.d/systemd.conf
usr/lib/modules/
usr/lib/modules/5.17.3-arch1-1/
usr/lib/modules/5.17.3-arch1-1/kernel/
usr/lib/modules/5.17.3-arch1-1/kernel/blake2b_generic.ko
usr/lib/modules/5.17.3-arch1-1/kernel/btrfs.ko
usr/lib/modules/5.17.3-arch1-1/kernel/cdrom.ko
usr/lib/modules/5.17.3-arch1-1/kernel/crc32c_generic.ko
usr/lib/modules/5.17.3-arch1-1/kernel/crc32c-intel.ko
usr/lib/modules/5.17.3-arch1-1/kernel/crc-itu-t.ko
usr/lib/modules/5.17.3-arch1-1/kernel/enclosure.ko
usr/lib/modules/5.17.3-arch1-1/kernel/firewire-core.ko
usr/lib/modules/5.17.3-arch1-1/kernel/firewire-sbp2.ko
usr/lib/modules/5.17.3-arch1-1/kernel/libcrc32c.ko
usr/lib/modules/5.17.3-arch1-1/kernel/megaraid_sas.ko
usr/lib/modules/5.17.3-arch1-1/kernel/mmc_block.ko
usr/lib/modules/5.17.3-arch1-1/kernel/mmc_core.ko
usr/lib/modules/5.17.3-arch1-1/kernel/nvme-core.ko
usr/lib/modules/5.17.3-arch1-1/kernel/nvme.ko
usr/lib/modules/5.17.3-arch1-1/kernel/raid6_pq.ko
usr/lib/modules/5.17.3-arch1-1/kernel/scsi_transport_sas.ko
usr/lib/modules/5.17.3-arch1-1/kernel/ses.ko
usr/lib/modules/5.17.3-arch1-1/kernel/sha256-ssse3.ko
usr/lib/modules/5.17.3-arch1-1/kernel/sr_mod.ko
usr/lib/modules/5.17.3-arch1-1/kernel/usbhid.ko
usr/lib/modules/5.17.3-arch1-1/kernel/usb-storage.ko
usr/lib/modules/5.17.3-arch1-1/kernel/virtio_blk.ko
usr/lib/modules/5.17.3-arch1-1/kernel/xhci-pci.ko
usr/lib/modules/5.17.3-arch1-1/kernel/xhci-pci-renesas.ko
usr/lib/modules/5.17.3-arch1-1/kernel/xor.ko
usr/lib/modules/5.17.3-arch1-1/kernel/xxhash_generic.ko
usr/lib/modules/5.17.3-arch1-1/modules.alias.bin
usr/lib/modules/5.17.3-arch1-1/modules.builtin.alias.bin
usr/lib/modules/5.17.3-arch1-1/modules.builtin.bin
usr/lib/modules/5.17.3-arch1-1/modules.dep.bin
usr/lib/modules/5.17.3-arch1-1/modules.devname
usr/lib/modules/5.17.3-arch1-1/modules.softdep
usr/lib/modules/5.17.3-arch1-1/modules.symbols.bin
usr/lib/systemd/
usr/lib/systemd/libsystemd-shared-250.so
usr/lib/systemd/system/
usr/lib/systemd/system/basic.target
usr/lib/systemd/system/ctrl-alt-del.target
usr/lib/systemd/system/default.target
usr/lib/systemd/systemd-fsck
usr/lib/systemd/systemd-hibernate-resume
usr/lib/systemd/systemd-journald
usr/lib/systemd/systemd-modules-load
usr/lib/systemd/systemd-shutdown
usr/lib/systemd/systemd-sulogin-shell
usr/lib/systemd/systemd-sysctl
usr/lib/systemd/systemd-udevd
usr/lib/systemd/system/emergency.service
usr/lib/systemd/system/emergency.target
usr/lib/systemd/system/final.target
usr/lib/systemd/system-generators/
usr/lib/systemd/system-generators/systemd-fstab-generator
usr/lib/systemd/system-generators/systemd-gpt-auto-generator
usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
usr/lib/systemd/system/initrd-cleanup.service
usr/lib/systemd/system/initrd-fs.target
usr/lib/systemd/system/initrd-parse-etc.service
usr/lib/systemd/system/initrd-root-device.target
usr/lib/systemd/system/initrd-root-fs.target
usr/lib/systemd/system/initrd-switch-root.service
usr/lib/systemd/system/initrd-switch-root.target
usr/lib/systemd/system/initrd.target
usr/lib/systemd/system/initrd-udevadm-cleanup-db.service
usr/lib/systemd/system/kmod-static-nodes.service
usr/lib/systemd/system/local-fs-pre.target
usr/lib/systemd/system/local-fs.target
usr/lib/systemd/system/paths.target
usr/lib/systemd/system/reboot.target
usr/lib/systemd/system/rescue.service
usr/lib/systemd/system/rescue.target
usr/lib/systemd/system/shutdown.target
usr/lib/systemd/system/slices.target
usr/lib/systemd/system/sockets.target
usr/lib/systemd/system/sockets.target.wants/
usr/lib/systemd/system/sockets.target.wants/systemd-journald-audit.socket
usr/lib/systemd/system/sockets.target.wants/systemd-journald-dev-log.socket
usr/lib/systemd/system/sockets.target.wants/systemd-journald.socket
usr/lib/systemd/system/sockets.target.wants/systemd-udevd-control.socket
usr/lib/systemd/system/sockets.target.wants/systemd-udevd-kernel.socket
usr/lib/systemd/system/swap.target
usr/lib/systemd/system/sysinit.target
usr/lib/systemd/system/sysinit.target.wants/
usr/lib/systemd/system/sysinit.target.wants/kmod-static-nodes.service
usr/lib/systemd/system/sysinit.target.wants/systemd-journald.service
usr/lib/systemd/system/sysinit.target.wants/systemd-modules-load.service
usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup-dev.service
usr/lib/systemd/system/sysinit.target.wants/systemd-udevd.service
usr/lib/systemd/system/sysinit.target.wants/systemd-udev-trigger.service
usr/lib/systemd/system/systemd-fsck@.service
usr/lib/systemd/system/systemd-hibernate-resume@.service
usr/lib/systemd/system/systemd-journald-audit.socket
usr/lib/systemd/system/systemd-journald-dev-log.socket
usr/lib/systemd/system/systemd-journald.service
usr/lib/systemd/system/systemd-journald.socket
usr/lib/systemd/system/systemd-modules-load.service
usr/lib/systemd/system/systemd-reboot.service
usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service
usr/lib/systemd/system/systemd-udevd-control.socket
usr/lib/systemd/system/systemd-udevd-kernel.socket
usr/lib/systemd/system/systemd-udevd.service
usr/lib/systemd/system/systemd-udev-trigger.service
usr/lib/systemd/system/timers.target
usr/lib/systemd/system/umount.target
usr/lib/udev/
usr/lib/udev/ata_id
usr/lib/udev/rules.d/
usr/lib/udev/rules.d/50-udev-default.rules
usr/lib/udev/rules.d/60-persistent-storage.rules
usr/lib/udev/rules.d/64-btrfs.rules
usr/lib/udev/rules.d/80-drivers.rules
usr/lib/udev/rules.d/99-systemd.rules
usr/lib/udev/scsi_id
usr/local/
usr/local/bin
usr/local/lib
usr/local/sbin
usr/sbin
var/
var/run
VERSION

Offline

#11 2022-04-21 01:40:08

dawnofman
Member
Registered: 2019-07-26
Posts: 140

Re: [solved]systemd.fsck started on BTRFS root partition (fsck=0 in fstab)

Raynman wrote:

If the root device is btrfs and thus doesn't need to be checked, you can disable/remove the fsck hook.

- Removed the hook.
- Rebuilt the images.
- Rebooted.
- No more fsck.btrfs warnings ... everything perfectly fine now.

Offline

Board footer

Powered by FluxBB