#773731 /usr/sbin/cache_check: execvp failed: No such file or directory

Package:
lvm2
Source:
lvm2
Description:
Linux Logical Volume Manager
Submitter:
Marc Lehmann
Date:
2022-01-11 10:00:02 UTC
Severity:
normal
#773731#5
Date:
2014-12-22 18:16:08 UTC
From:
To:
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

After creating a dmcache cache and rebooting, the device was inaccessible,
because vgchange couldn't activate it:

   # vgchange -a y
   /usr/sbin/cache_check: execvp failed: No such file or directory
   Check of pool vg_cerebro/wd_cache failed (status:2). Manual repair required!

Indeed, the file /usr/sbin/cache_check doesn't exist - should it be part of lvm2?
#773731#10
Date:
2015-01-17 05:59:48 UTC
From:
To:
Hello all,

I ran into this problem too. Installing thin-provisioning-tools fixed
the problem.

I would suggest adding a notice on the manual page "lvmcache(7)" that
this otherwise suggested package is required with LVM caching.

It would also be nice if lvconvert pointed this out as well.
#773731#15
Date:
2015-03-15 14:24:56 UTC
From:
To:
/usr/sbin/cache_check is still missing in Debian Jessie as of this morning.

It would be good to fix this before Jessie goes to Stable because this
bug prevented my machine from booting successfully. (System couldn't
mount my lvm-cache'd /home directory). That's a pretty serious issue
that took me about 30 minutes of googling to figure out.

Installing thin-provisioning-tools fixed the problem.

Thanks
Ben McCann
#773731#20
Date:
2015-03-17 20:14:33 UTC
From:
To:
It is part of thin-provisioning-tools.  Please provide a patch that
checks for the existance during lv creation.

Bastian
#773731#25
Date:
2015-03-17 20:14:33 UTC
From:
To:
It is part of thin-provisioning-tools.  Please provide a patch that
checks for the existance during lv creation.

Bastian
#773731#30
Date:
2015-03-19 10:43:50 UTC
From:
To:
 > fixed the problem.

That did not quite fix it for me: fsck still failed at boot because
cache_check was not on the initrd.
A similar story: [http://forums.debian.net/viewtopic.php?f=5&t=119644].
See also bug #774560.
#773731#35
Date:
2015-03-20 15:43:53 UTC
From:
To:
Looks like the problem on system was not cache_check missing from the
initrd, as I was not trying to cache root. The problem was cache_check
missing from the actual root fs. vgchange -aay, executed after mounting
root but before fsck, failed for the cached volumes. I suppose
cache_check should be moved to /sbin. Maybe also the thin provisioning
utilities if needed to fix #774560.
#773731#40
Date:
2015-03-21 11:28:14 UTC
From:
To:
The binaries from thin-provisioning-tools depends on libstdc++, so they
must reside in /usr.

Regards,
Bastian
#773731#45
Date:
2015-03-21 15:11:32 UTC
From:
To:
Ditto for cache_check.  This seems to be getting complicated.

In order to support cached root, cache_check and hence libstdc++ need to
be on initrd.  The boot scripts could be modified to activate all volume
groups before mounting root.  Then it should not matter if cache_check
is not on the actual root.

Another possibility would be to do fsck and mounting in three phases
instead of two: first fsck and mount root, then /usr and other
non-cached volumes and finally cached volumes.  Root and /usr could not
be cached then.

Or maybe just link statically to libstdc++.
#773731#50
Date:
2015-03-25 19:52:21 UTC
From:
To:
Not sure what the patch would do, it would still not work with such a
patch, even though it's documented to.

The problem is clearly the missing dependency.

It could be mitigated by documenting this dependency in the lvmcache
manpage, or moving that manpage to thin-provisioning-tools.

Correct dependencies would be best, of course.
#773731#55
Date:
2015-03-25 19:52:21 UTC
From:
To:
Not sure what the patch would do, it would still not work with such a
patch, even though it's documented to.

The problem is clearly the missing dependency.

It could be mitigated by documenting this dependency in the lvmcache
manpage, or moving that manpage to thin-provisioning-tools.

Correct dependencies would be best, of course.
#773731#60
Date:
2015-05-09 10:01:33 UTC
From:
To:
Upgrading to Jessie sneaked systemd into my machine, and now I am able
to boot with a cached volume.  Looks like /usr now gets mounted before
the other filesystems are checked.  As long as one does not try to cache
root or /usr it should work (I have root and /usr fully on SSD).  I
don't know if sysvinit boot scripts remain broken or anything about upstart.

Still need to make sure you have thin-provisioning-tools though.
#773731#65
Date:
2016-03-10 23:05:21 UTC
From:
To:

Upstream thinprovtools now DO support  static linkage for libstdc++.
Please fix packaging and close BZ.

Regards

Zdenek
#773731#70
Date:
2021-04-13 09:28:04 UTC
From:
To:
Dear Maintainer,

I encountered this bug when I upgraded my system from buster to
bullseye, causing my system to be unable to boot without manual
intervention.  I also reproduced the bug in a fresh bullseye install.

When I originally installed buster I used guided partitioning with LVM,
which resulted in the lvm2 package being installed but not its
recommended thin-provisioning-tools.  While on buster I configured a
volume (/home) to have a cache pool following the steps in lvmcache(7).
The system booted with the cached volume available without
/usr/sbin/cache_check from thin-provisioning-tools.

After upgrading my system to bullseye and rebooting, my cached volume
could not be mounted at home and I was asked to enter the root password
for the emergency mode maintenance shell.  "lvconvert --splitcache
vg/cached_lv" would allow me to reboot with the now uncached volume
once again activated on boot.  Alternatively I could "lvchange -ay
vg/cached_lv" at the emergency mode root shell, which would produce the
error:

  /usr/sbin/cache_check: execvp failed: No such file or directory
  WARNING: Check is skipped, please install recommended missing binary
/usr/sbin/cache_check!

After manually activating the volume "systemctl default" would continue
booting normally.

I also encountered this bug on a fresh install of bullseye in a virtual
machine.

Steps to reproduce (demonstrated using two virtio drives):


* Requires two drives
* Install bullseye from debian-testing-amd64-netinst.iso from 2021-04-
12
* Guided partitioning with LVM, separate /home
* SSH and standard tasks


root@lvmtest:~# fdisk /dev/vdb # Create GPT partition table and
/dev/vdb1 as type Linux LVM

root@lvmtest:~# pvcreate /dev/vdb1
  Physical volume "/dev/vdb1" successfully created.

root@lvmtest:~# vgextend lvmtest-vg /dev/vdb1
  Volume group "lvmtest-vg" successfully extended

root@lvmtest:~# lvcreate -n cachehome -L 32g lvmtest-vg
  Logical volume "cachehome" created.

root@lvmtest:~# lvconvert --type cache --cachepool cachehome lvmtest-
vg/home
  WARNING: Converting lvmtest-vg/cachehome to cache pool's data volume
with metadata wiping.
  THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.)
Do you really want to convert lvmtest-vg/cachehome? [y/n]: y
  Converted lvmtest-vg/cachehome to cache pool.
  Logical volume lvmtest-vg/home is now cached.

* Reboot will bring system into emergency mode because /home cannot be
mounted.

The lvm2 package was again installed by the bullseye debian-installer
because of the guided partitioning choice, but without its recommended
thin-provisioning-tools which contains /usr/sbin/cache_check.

I think that activating cached volumes on boot was working during
buster is related to this line from /usr/share/doc/lvm2/changelog.gz:
Version 2.02.178-rc1 - 24th May 2018
…
  Allow activation of pools when thin/cache_check tool is missing.

However this seems to be no longer the case on bullseye, at least
automatically at boot.

This may warrant a warning in the bullseye release notes as systems
using lvmcache on buster without thin-provisioning-tools installed will
not boot properly after upgrading to bullseye.


Thanks,

Jeremy McNaughton
#773731#75
Date:
2022-01-11 09:56:10 UTC
From:
To:
Still an issue in 2022...