Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Uppgrade from debian 10 to debian 11.0.
Or creating an complete new thinpool and using snaphosts on debian 11.0
* What exactly did you do (or not do) that was effective (or
ineffective)?
After an reboot and when thin_check has finnished so are the LVs inactive.
They can't be activated with vgchange -ya it shows the following error:
Activation of logical volume hemma/hemma-thinpool is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
* What was the outcome of this action?
vgchange -ya hemma
0 logical volume(s) in volume group "hemma" now active
Activation of logical volume hemma/hemma-thinpool is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/backup is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/home is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/stuff is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/Monday is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/Tuesday is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/Wednesday is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/Thursday is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/Friday is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/Saturday is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
Activation of logical volume hemma/Sunday is prohibited while logical volume hemma/hemma-thinpool_tmeta is active.
0 logical volume(s) in volume group "hemma" now active
lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
Friday hemma Vwi---tz-- <3.91t hemma-thinpool backup
Monday hemma Vwi---tz-- <3.91t hemma-thinpool backup
Saturday hemma Vwi---tz-- <3.91t hemma-thinpool backup
Sunday hemma Vwi---tz-- <3.91t hemma-thinpool backup
Thursday hemma Vwi---tz-- <3.91t hemma-thinpool backup
Tuesday hemma Vwi---tz-- <3.91t hemma-thinpool backup
Wednesday hemma Vwi---tz-- <3.91t hemma-thinpool backup
backup hemma Vwi---tz-- <3.91t hemma-thinpool
hemma-thinpool hemma twi---tz-- <7.25t
[hemma-thinpool_tdata] hemma Twi-a----- <7.25t
[hemma-thinpool_tmeta] hemma ewi-a----- 15.00g
home hemma Vwi---tz-- 1000.00g hemma-thinpool
[lvol0_pmspare] hemma ewi------- 15.00g
stuff hemma Vwi---tz-- 10.00g hemma-thinpool
* What outcome did you expect instead?
First they would be active after an reboot and when thin_check has finnished.
and second it should be possible to activate with vgchange -ya.
An work arround is to first run: lvchange -an hemma
Then thin_check starts and after that has finnished:
And then run: vgchange -ay hemma
And now the VG is active again.
lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
Friday hemma Vwi-a-tz-- <3.91t hemma-thinpool backup 45.19
Monday hemma Vwi-a-tz-- <3.91t hemma-thinpool backup 45.19
Saturday hemma Vwi-a-tz-- <3.91t hemma-thinpool backup 45.19
Sunday hemma Vwi-a-tz-- <3.91t hemma-thinpool backup 45.19
Thursday hemma Vwi-a-tz-- <3.91t hemma-thinpool backup 45.07
Tuesday hemma Vwi-a-tz-- <3.91t hemma-thinpool backup 44.95
Wednesday hemma Vwi-a-tz-- <3.91t hemma-thinpool backup 45.07
backup hemma Vwi-aotz-- <3.91t hemma-thinpool 44.95
hemma-thinpool hemma twi-aotz-- <7.25t 27.97 9.14
[hemma-thinpool_tdata] hemma Twi-ao---- <7.25t
[hemma-thinpool_tmeta] hemma ewi-ao---- 15.00g
home hemma Vwi-aotz-- 1000.00g hemma-thinpool 12.31
[lvol0_pmspare] hemma ewi------- 15.00g
stuff hemma Vwi-aotz-- 10.00g hemma-thinpool 2.42
*** End of the template - remove these template lines ***
Dear Maintainer, I am beeing bitten by that same bug after upgrading from buster to bullseye on a server with a thin pool volumegroup. I now have a VERY crude workaround in place by starting a systemd unit file with a 60s delay and then activating the volumegroup. But this seems very much not robust.
Package: lvm2
Version: 2.03.11-2.1
Followup-For: Bug #989374
Dear Maintainer,
some Proxmox VE users are also affected by this issue [0][1].
With the help of LVM2 developers, the root cause was found to be
the following during early init [2]:
1. pvscan is started by the udev 69-lvm-metad.rules.
2. pvscan activates XYZ_tmeta and XYZ_tdata.
3. pvscan starts thin_check for the pool and waits for it to complete.
4. The timeout enforced by udev is hit and pvscan is killed.
5. Some time later, thin_check completes, but the activation of the
thin pool never completes.
Users reported that the workaround with '--skip-mappings' suggested in
[2] indeed works around the issue[3].
It would also be enough to set this only for the relevant instance of
pvscan, so a candidate for fixing this is:
diff --git a/udev/69-dm-lvm-metad.rules.in b/udev/69-dm-lvm-metad.rules.in
index 237b714d7..ff849e3f7 100644
--- a/udev/69-dm-lvm-metad.rules.in
+++ b/udev/69-dm-lvm-metad.rules.in
@@ -124,6 +124,6 @@ LABEL="direct_pvscan"
# MD | | X | X* | |
# loop | | X | X* | |
# other | X | | X | | X
-RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major --minor $minor", ENV{LVM_SCANNED}="1"
+RUN+="(LVM_EXEC)/lvm pvscan --cache --activate ay --major $major --minor $minor --config 'global/thin_check_options = [ \"-q\", \"--skip-mappings\" ]'", ENV{LVM_SCANNED}="1"
LABEL="lvm_end"