==> WARNING: Possibly missing '/bin/sh' for script: /usr/bin/fsck.btrfs

Regenerating the initrds for my kernels, I always see this warning:

==> WARNING: Possibly missing ‘/bin/sh’ for script: /usr/bin/fsck.btrfs

I know it is only a warning and everything seems to work fine but it is a bit annoying.

Shouldn’t fsck.btrfs run for Btrfs partitions at boot?

pacman -Qo /usr/bin/fsck.btrfs 
/usr/bin/fsck.btrfs is owned by btrfs-progs 6.13-1
$ 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
[neotux@archlinux ~]$ 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

Are you using dracut or mkinitcpio?

I use mkinicpio.
This is an Arch install so I never switched to dracut.

I think that is expected behavior in that case.

You might be able to get rid of the message by switching to the systemd hook.

I did switch to systemd hook some time ago yet I get this warning:

HOOKS=(systemd autodetect microcode modconf keyboard keymap block filesystems resume fsck)

I think you need to add btrfs to the BINARIES section like this:

BINARIES=(btrfs)

Then regenerate the initramfs again.

https://wiki.archlinux.org/title/Btrfs#Corruption_recovery

Thank you @BluishHumility! I had already tried this and also adding the systemd hook instead of the base.

Now I have another installation that is pretty much configured similarly except the DE where I don’t get this warning when the initrds are rebuilt. It contained no BINARIES=(btrfs) (or rather only #BINARIES=() ) and had the base hook instead of systemd.

I made the change here as well and lo and behold the warning is gone. That is quite strange because of what I have found in the way solution to this, some suggested to switch to systemd hook.

My question is will the system benefit from systemd hook? If it does I can live with the warning.

This is what I get now. The warnings are for the usual suspects:

==> Starting build: '6.14.0-arch1-1'
  -> Running build hook: [base]
  -> Running build hook: [microcode]
  -> Running build hook: [modconf]
  -> Running build hook: [keyboard]
==> WARNING: Possibly missing firmware for module: 'xhci_pci_renesas'
  -> Running build hook: [keymap]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: 'aic94xx'
==> WARNING: Possibly missing firmware for module: 'bfa'
==> WARNING: Possibly missing firmware for module: 'qed'
==> WARNING: Possibly missing firmware for module: 'qla1280'
==> WARNING: Possibly missing firmware for module: 'qla2xxx'
==> WARNING: Possibly missing firmware for module: 'wd719x'
  -> Running build hook: [filesystems]
  -> Running build hook: [resume]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Decompressing zstd-compressed firmware files
  -> Fixing firmware file symlinks
==> Creating uncompressed initcpio image: '/boot/initramfs-linux-fallback.img'
  -> Early uncompressed CPIO image generation successful
==> Initcpio image generation successful

I think I misinterpreted the warning on the first read through.

It is not missing the fsck.btrfs script, but rather bin/sh appears to be not available in the initramfs.

I’m not sure about this, but one possible explanation is the fsck hook will not actually run when using Btrfs if your pass values are set to 0 in /etc/fstab as recommended:

When you are using the systemd hook, systemd is supposed to “figure out” what modules will be needed by examining the running system when building the initramfs. It is possible systemd does not include /bin/sh in the initramfs unless it is explicitly required by something.

So I guess a few things you could try come to mind:

  • Try explicitly adding /bin/sh to BINARIES (instead of btrfs), so it is explicitly included in the initramfs.
  • Re-add the base hook, which should also add /bin/sh to the initramfs (busybox provides its own /bin/sh1, 2).
  • Remove the fsck hook altogether (since it will not be used if your root filesystem has pass set to 0 in /etc/fstab)

Personally I would be inclined to the latter, unless you have a compelling reason for keeping the hook.

The systemd hook will theoretically create a leaner initramfs, with potentially :pinching_hand: slightly faster boot times. In both cases (size of the initramfs, speed of boot) probably too small to notice. If you care about those kinds of metrics, probably dracut is the way to go anyway.

With the systemd hook, you also get the sd-encrypt hook which has some extra features compared to the regular encrypt hook. For example, you can unlock the LUKS volume with a FIDO2 key or the TPM chip with systemd. But that obviously only applies to encrypted setups.

That is kind of weird you got a different result on your second installation. Does that one also have a Btrfs root partition? Does it have the same hooks, in the same order?

1 Like