#966524 lvm2: lvconvert --merge does not remove the snapshot after restarting and completing job

Package:
lvm2
Source:
lvm2
Description:
Linux Logical Volume Manager
Submitter:
Antonio
Date:
2023-02-11 15:51:03 UTC
Severity:
important
#966524#5
Date:
2020-07-30 05:55:24 UTC
From:
To:
Dear Maintainer,

* What led up to the situation?

I created a snapshot to safely test my application and then run lvconvert
--merge to undo the changes made to the system

* What exactly did you do (or not do) that was effective (or
     ineffective)?

lvcreate --size 10G -s -n revert system/debian
... test my application ...
lvconvert --merge system/revert
reboot

* What was the outcome of this action?

After the restart, the restore was successful but the snapshot was not
removed after the job was completed:

debian   system Owi-aos--- 100,00g             0,00

[revert] system Swi-aos---   1,00g      debian 0,00

* What outcome did you expect instead?

remove the snapshot at the end of the lvconvert process

debian   system -wi-ao---- 100,00g
#966524#10
Date:
2020-07-31 07:01:06 UTC
From:
To:
I can confirm that this bug also occurs in lvm2/2.03.07-1. Essentially,
the merge operation appears to complete successfully, but the snapshot
LV isn't automatically removed. Additionally, the snapshot LV cannot be
manually removed via "lvremove". The workaround I used was to modify the
VG metadata backup (located at /etc/lvm/backup) by removing the snapshot
LV from within the "logical_volumes" section, restoring it via
"vgcfgrestore", and then rebooting.
#966524#15
Date:
2020-09-04 20:31:34 UTC
From:
To:
I tried version 2.03.10 by downloading it from the repository
https://sourceware.org/git/?p=lvm2.git;a=summary, but the problem remains.
I think you should report this type of problem to the developers ...
#966524#20
Date:
2021-01-16 19:38:30 UTC
From:
To:
Dear maintenance,
to remember that this problem still exists (and is necessary restart the
system, after the snapshot revert process has completed)

Thanks
Antonio
#966524#25
Date:
2021-01-18 10:14:00 UTC
From:
To:
Comparing the working lvm package (2.03.07-1+b1) with the next package
that has the problem (2.03.09-1), after some tests I was able to solve
the problem quite simply:
- copy the file: "69-lvm-metad.rules" of the working version in
"/lib/udev/rules.d/69-lvm-metad.rules"
- and regenerate initram: "update-initramfs -u"
repeating the test, the problem was solved (for me)

Thanks
Antonio

----------------------------------------------------------------------------------------------------------------------------
--- /lib/udev/rules.d/69-lvm-metad.rules    2021-01-18 
10:42:53.673808888 +0100
+++ /lib/udev/rules.d/69-lvm-metad.rules    2021-01-18
11:07:17.154831718 +0100
@@ -68,15 +68,17 @@
  # For "systemd_background" mode, systemd takes care of this by activating
  # the lvm2-pvscan@.service only once.
  LABEL="next"
-TEST!="/run/systemd/system", ACTION!="add", GOTO="lvm_end"
-TEST=="/run/systemd/system", ACTION!="add|change", GOTO="lvm_end"
+ACTION!="add|change", GOTO="lvm_end"

  LABEL="lvm_scan"

  ENV{SYSTEMD_READY}="1"



----------------------------------------------------------------------------------------------------------------------------
#966524#30
Date:
2021-05-21 19:42:08 UTC
From:
To:
The problem, which I had reported in January, still exists.
It would be useful to apply the patch indicated above or similar (so as
not to have to apply it to each update of the LVM2 package).

Thanks
Antonio
#966524#35
Date:
2021-08-26 21:49:34 UTC
From:
To:
#966524#40
Date:
2022-08-02 14:43:01 UTC
From:
To:
Dear Maintainer,
I would like to remember that this problem is still present.

Thanks,
Antonio
#966524#45
Date:
2022-08-02 20:09:50 UTC
From:
To:
Hi Alexander,

For now I understand that, unlike the previous time, I can eliminate the
stall condition with:
     vgchange -ay

Perhaps an unavailable condition occurs, but not knowing how Lvconvert
works can only hypothesize...

I would like this bug to be closed, since it has been going on for a
long time.
#966524#50
Date:
2023-02-11 15:46:24 UTC
From:
To:
When the machine is rebooted and old thick snapshot merging is started, it may
take some time.

So there need to be something 'monitoring' progress of the merge and react
when merge is finished.

For this purpose the 'default' logic in lvm2 is  'lvmpolld' service - that
should be present in the system, so lvchange activation command can connect
lvmpolld service that would monitor progress of the merge.  Once finished, 
lvmpolld will basically --refresh   VG and update metadata and drop
'empty/merged' snapshot.

There is also option to avoid using 'lvmpolld'  and use the implicit 
monitoring with  'lvchange --background' that would need to be used with
activation.

As such there is most likely no bug on lvm2 here - but likely some
configuration troubles.

Also note  lvmetad is 'gone'  for  2.03 version of lvm2 - so there should be
no connection with lvmetad udev rules.