FS#77416 - [thin-provisioning-tools] version 1.0.0-1 breaks the mkinitcpio lvm2 hook

Attached to Project: Arch Linux
Opened by Eric Toombs (ewtoombs) - Tuesday, 07 February 2023, 04:09 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:14 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
My root volume is in a thinpool and this new version of thin-provisioning-tools has broken my boot. It should be reverted until this problem is fixed.

Additional info:
* package version(s): 0.9.0 works, 1.0.0 doesn't.
* link to upstream bug report: https://github.com/jthornber/thin-provisioning-tools/issues/244
* lvm2 is running on top of luks, so I run the cryptsetup hook before the lvm2 hook.

Steps to reproduce:
0. Set up a system with your root volume in a thinpool using thin-provisioning-tools 0.9.0. Use the lvm2 mkinitcpio hook.
2. Upgrade to 1.0.0.
3. Reboot

The boot sequence will fail, unable to find the root volume. In the recovery shell, if you attempt a `lvm vgchange -ay`, this is what you get:
```
Check of pool myvgnamehere/mythinpoolnamehere failed (status:64). Manual repair required!
```

After a cursory examination of the package contents of the different versions, I've found that 1.0.0 has two extra symlinks: `thin_metadata_pack` and `thin_metadata_unpack`. `/usr/lib/initcpio/install/lvm2` does not provide these symlinks. I am adding these symlinks manually and rebooting to see if this fixes the problem.
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:14 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/thin-provisioning-tool s/issues/1
Comment by Eric Toombs (ewtoombs) - Tuesday, 07 February 2023, 04:15 GMT
This is the diff between directory listings of the two versions:
```
--- /tmp/2 2023-02-06 23:02:16.766646562 -0500
+++ /tmp/1 2023-02-06 23:02:22.180109642 -0500
@@ -15,7 +15,9 @@
usr/bin/thin_delta
usr/bin/thin_dump
usr/bin/thin_ls
+usr/bin/thin_metadata_pack
usr/bin/thin_metadata_size
+usr/bin/thin_metadata_unpack
usr/bin/thin_repair
usr/bin/thin_restore
usr/bin/thin_rmap
@@ -37,7 +39,9 @@
usr/share/man/man8/thin_delta.8.gz
usr/share/man/man8/thin_dump.8.gz
usr/share/man/man8/thin_ls.8.gz
+usr/share/man/man8/thin_metadata_pack.8.gz
usr/share/man/man8/thin_metadata_size.8.gz
+usr/share/man/man8/thin_metadata_unpack.8.gz
usr/share/man/man8/thin_repair.8.gz
usr/share/man/man8/thin_restore.8.gz
usr/share/man/man8/thin_rmap.8.gz
```
Comment by Eric Toombs (ewtoombs) - Tuesday, 07 February 2023, 04:46 GMT
I just got back from my reboot. The error persists. Adding the symlinks did nothing.
Comment by Oleksandr Natalenko (post-factum) - Tuesday, 07 February 2023, 14:15 GMT
Affects my system with a similar setup as well.
Comment by Eric Toombs (ewtoombs) - Wednesday, 08 February 2023, 04:13 GMT
Adding the following to /etc/lvm/lvm.conf fixes the issue:

thin_check_options = [ "-q", "--auto-repair" ]

mkinitcpio must be rerun.
Comment by Paul Gideon Dann (giddie) - Monday, 27 February 2023, 12:32 GMT
Could the --auto-repair option be added by the hook automatically for read-write volumes? Upstream suggests this: https://github.com/jthornber/thin-provisioning-tools/issues/244#issuecomment-1426302679
Comment by loqs (loqs) - Monday, 27 February 2023, 13:54 GMT
@giddie the defaults in /etc/lvm/lvm.conf come from upstream lvm2. Have they been contacted about the issue?
Comment by Oleksandr Natalenko (post-factum) - Monday, 27 February 2023, 14:01 GMT
Literally, the previous comment has the link to the upstream issue and the response by the upstream dev.
Comment by loqs (loqs) - Monday, 27 February 2023, 14:08 GMT
@post-factum thin-provisioning-tools and lvm2 are different projects are they not? I was asking if the lvm2 project which provides the default config file is aware of the change introduced by think-producing-tools?
Comment by loqs (loqs) - Tuesday, 07 March 2023, 20:57 GMT
@post-factum if upstream lvm2 did something such as in the attached diff would it not solve the issue?
As conf/example.conf.in is generated by lvm dumpconfig the binaries have to first be generated with updated defaults then generate an update config that is then packaged.
I did not update lib/config/config_settings.h to match the new default due to a lack of requisite knowledge. So the comments do not cover --auto-repair.
   PKGBUILD.diff (6.6 KiB)
Comment by Paul Gideon Dann (giddie) - Wednesday, 08 March 2023, 08:18 GMT
As I understand it, the issue is that this can't be enabled as a default, because auto-repair is not appropriate for read-only block devices. This feels like something that needs to be handled by init scripts rather than by adjusting default config.
Comment by Christian Hesse (eworm) - Monday, 28 August 2023, 07:02 GMT
https://bugzilla.redhat.com/show_bug.cgi?id=2233177
Comment by Toolybird (Toolybird) - Thursday, 21 September 2023, 00:26 GMT
The cause and workaround are now well understood. Lowering severity level accordingly.

Loading...