Bug#773731: Debian 11 stable - still this bug after caching a raid1 VG

[remi . marchal]

Dear Maintainer,
after updating debian stable 10 to 11, reimported my raid1 lvm VG
(data) and caching it with a raid1 SSD pool, I got the same problem of
missing binary /usr/sbin/cache_check during booting process (that fail
by being enable to mount the caching VG). Installing the thin-
provisioning-tools package has solved the problem. As far as I know,
nothing in the manual of lvmcache(7) mentions this problem and
dependency!
Best regards and thanks again for the great job on Debian!

Bug#773731:

[Neil Stone]

Still an issue in 2022...

Bug#773731: LVM cached volumes fail to activate at boot without cache_check on bullseye

[Jeremy McNaughton]

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

Bug#773731: cache_check should be on root

[Zdenek Kabelac]

On Sat, 21 Mar 2015 17:11:32 +0200 Timo Korvola  wrote:

On 21.03.2015 13:28, Bastian Blank wrote:
> The binaries from thin-provisioning-tools depends on libstdc++, so they
> must reside in /usr.

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




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

Regards

Zdenek

Bug#773731: Seems improved in Jessie or systemd

[Timo Korvola]

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.

--
Timo KorvolaURL:http://www.iki.fi/tkorvola


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Marc Lehmann]

On Tue, Mar 17, 2015 at 09:14:33PM +0100, Bastian Blank wa...@debian.org 
wrote:
 On Mon, Dec 22, 2014 at 07:16:08PM +0100, Marc Lehmann wrote:
  Indeed, the file /usr/sbin/cache_check doesn't exist - should it be part of 
  lvm2?
 
 It is part of thin-provisioning-tools.  Please provide a patch that
 checks for the existance during lv creation.

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.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773731: cache_check should be on root

[Timo Korvola]

On 21.03.2015 13:28, Bastian Blank wrote:

The binaries from thin-provisioning-tools depends on libstdc++, so they
must reside in /usr.


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

--
Timo KorvolaURL:http://www.iki.fi/tkorvola


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773731: cache_check should be on root

[Bastian Blank]

On Fri, Mar 20, 2015 at 05:43:53PM +0200, Timo Korvola wrote:
 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.

The binaries from thin-provisioning-tools depends on libstdc++, so they
must reside in /usr.

Regards,
Bastian

-- 
It is more rational to sacrifice one life than six.
-- Spock, The Galileo Seven, stardate 2822.3


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773731: cache_check should be on root

[Timo Korvola]

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.


--
Timo KorvolaURL:http://www.iki.fi/tkorvola


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773731: thin-provision-tools

[Timo Korvola]

On Sat, 17 Jan 2015 07:59:48 +0200 Aleksi Suhonen 
debian-reportbug-2...@ssd.axu.tm wrote:

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

 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=5t=119644].
See also bug #774560.

--
Timo KorvolaURL:http://www.iki.fi/tkorvola


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Bastian Blank]

On Mon, Dec 22, 2014 at 07:16:08PM +0100, Marc Lehmann wrote:
 Indeed, the file /usr/sbin/cache_check doesn't exist - should it be part of 
 lvm2?

It is part of thin-provisioning-tools.  Please provide a patch that
checks for the existance during lv creation.

Bastian

-- 
Schshschshchsch.
-- The Gorn, Arena, stardate 3046.2


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773731: lvmcache issues with missing thin-provisioning-tools

[Ben McCann]

/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


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#773731: thin-provision-tools

[Aleksi Suhonen]

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.

--
Aleksi Suhonen

() ascii ribbon campaign
/\ support plain text e-mail


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Marc Lehmann]

Package: lvm2
Version: 2.02.111-2
Severity: normal

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?

-- System Information:
Debian Release: 7.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.18.1-031801-generic (SMP w/12 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.90-2
ii  dmsetup   2:1.02.90-2
ii  init-system-helpers   1.19
ii  initscripts   2.88dsf-41+deb7u1
ii  libc6 2.19-1
ii  libdevmapper-event1.02.1  2:1.02.74-8
ii  libdevmapper1.02.12:1.02.90-2
ii  libreadline5  5.2+dfsg-2~deb7u1
ii  libudev1  215-4
ii  lsb-base  4.1+Debian12

lvm2 recommends no packages.

Versions of packages lvm2 suggests:
pn  thin-provisioning-tools  none

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org