local-LVM not available after Kernel update on PVE 7

[fiona]

@ShEV even though your setup is a bit different, the place where pvscan supposedly crashes is the same (right after executing the metadata check) and there also is a second LVM command running at the same time. I suggest reporting the issue to Debian or Red Hat.

Here is a preliminary patch that would serve as a workaround in Proxmox VE (not reviewed yet!), but of course the underlying issue with autoactivation failing is not solved by that.

 

[Mohave County Library]

I don't think I mentioned this in my first post as it had only happened once then but is every time now. When I go to run the "lvchange -ay pve/data" command I'll get "Activation of logical volume pve/data is prohibited while logical volume pve/data_tmeta is active” and/or “Activation of logical volume pve/data is prohibited while logical volume pve/data_tdata is active”

I have to deactivate the pve/data_tmeta and/or pve/data_tdata before I can activate the pve/data (lvchange -an pve/data_tmeta and lvchange -an pve/data_tdata before running lvchange -ay pve/data)

Don't know if this information will help solve this problem.

 

[ShEV]

I suggest reporting the issue to Debian or Red Hat.

I don’t know how to do it, I don’t know how to describe it, I don’t know how to arrange it. If possible, You can do it.

 

[Fidor]

A quick workaround:

Create a new systemd service:

root@c30:~# cat /etc/systemd/system/lvm-fix.service
[Unit]
Description=Activate all VG volumes (fix)
Before=local-fs.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/vgchange -ay

[Install]
WantedBy=multi-user.target

Enable it:

systemctl daemon-reload
systemctl enable lvm-fix.service

Reboot the server

 

[fiona]

I created an upstream bug report for the issue. As I wasn't able to reproduce the issue myself, it would be great if you could subscribe to the issue and provide requested information to the LVM developers.

 

[fiona]

It's not an LVM bug, but should rather be considered a bug in Proxmox VE's (and likely Debian's) init configuration/handling. What (likely) happens is that the thin_check during activation takes too long and pvscan is killed (see here for more information).

Another workaround besides the one suggested by @Fidor should be setting

thin_check_options = [ "-q", "--skip-mappings" ]

in your /etc/lvm/lvm.conf and running update-initramfs -u afterwards.

EDIT3: Yet another alternative is to increase the udev timeout: https://forum.proxmox.com/threads/l...fter-kernel-update-on-pve-7.97406/post-558890

EDIT2: Upstream bug report in Debian

EDIT: The workaround from @Fidor doesn't seem to work when the partial LVs are active:

Activation of logical volume pve/data is prohibited while logical volume pve/data_tmeta is active.

It would require deactivating XYZ_tmeta and XYZ_tdata first.

 

[ShEV]

It's not an LVM bug, but should rather be considered a bug in Proxmox VE's (and likely Debian's) init configuration/handling. What (likely) happens is that the thin_check during activation takes too long and pvscan is killed (see here for more information).

Yes, I am following this discussion.

Another workaround besides the one suggested by @Fidor should be setting...

I will try to check soon

 

[ShEV]

Another workaround besides the one suggested by @Fidor should be setting

Yes! This fixes my problem. Thank You!

 

[Mohave County Library]

Thank you
I should be able to test this tomorrow morning here.

 

[Mohave County Library]

Yes! This fixes our problem as well. Thank you!

 

[L1243]

It's not an LVM bug, but should rather be considered a bug in Proxmox VE's (and likely Debian's) init configuration/handling. What (likely) happens is that the thin_check during activation takes too long and pvscan is killed (see here for more information).

Another workaround besides the one suggested by @Fidor should be setting

thin_check_options = [ "-q", "--skip-mappings" ]

in your /etc/lvm/lvm.conf and running update-initramfs -u afterwards.


EDIT: The workaround from @Fidor doesn't seem to work when the partial LVs are active:

Activation of logical volume pve/data is prohibited while logical volume pve/data_tmeta is active.

It would require deactivating XYZ_tmeta and XYZ_tdata first.

Do I have to add it to a special section of lvm.conf?

 

[ShEV]

Do I have to add it to a special section of lvm.conf?

thin_check_options = present in config. It only needs to be find and corrected.

 

[L1243]

Now I updated to 5.13.19-2-pve
After that both workarounds arent working anymore.

Does anyone has an Idea?

Following error appears, even when I am using one of the workarounds
Activation of logical volume vm/vm is prohibited while logical volume vm/vm_tmeta is active.

SOLVED: By running these commands manually after a reboot

lvchange -a n lvm/lvm_tmeta
lvchange -a n lvm/lvm_tdata
lvchange -ay       (can take some time to run)

 

[Mohave County Library]

We are running 5.13.19-2 now and the edit to the lvm.conf file is still working for us.

 

[L1243]

We are running 5.13.19-2 now and the edit to the lvm.conf file is still working for us.

The edit of the conf file never worked for me.
That will be the reason I think

 

[ShEV]

Now I updated to 5.13.19-2-pve
After that both workarounds arent working anymore.

Today I upgraded the server to 5.13.19-2-pve. Everything works great.

 

[solarsparq]

It's not an LVM bug, but should rather be considered a bug in Proxmox VE's (and likely Debian's) init configuration/handling. What (likely) happens is that the thin_check during activation takes too long and pvscan is killed (see here for more information).

Another workaround besides the one suggested by @Fidor should be setting

thin_check_options = [ "-q", "--skip-mappings" ]

in your /etc/lvm/lvm.conf and running update-initramfs -u afterwards.

EDIT2: Upstream bug report in Debian

EDIT: The workaround from @Fidor doesn't seem to work when the partial LVs are active:

Activation of logical volume pve/data is prohibited while logical volume pve/data_tmeta is active.

It would require deactivating XYZ_tmeta and XYZ_tdata first.

I have a HP DL360p Gen8 with 1x Samsung 860EVO, 1x Seagate Firecuda, 1x Seagate Ironwolf, & 1x WD Red that was displaying this symptom. The Ironwolf HDD is the one it specifically hung up on every single time. I am running a fresh install of Proxmox 7.1-7 with new disks. I was running Kernel 5.13.X prior, but I opted-in for Kernel 5.15. The lvm.conf edit worked perfect in my scenario. lv.ironwolf.hdd no longer hangs & fails. Running Linux 5.15.19-1-pve now. Thanks for the hypervisor & contributions everyone. Likely HP-only problem based on my forum research on this topic.

Feb  9 14:23:01 creeperhost002 pvestatd[1641]: activating LV 'lv.ironwolf.hdd/lv.ironwolf.hdd' failed:   Activation of logical volume lv.ironwolf.hdd/lv.ironwolf.hdd is prohibited while logical volume lv.ironwolf.hdd/lv.ironwolf.hdd_tmeta is active.
Feb  9 14:23:02 creeperhost002 pve-guests[1773]: activating LV 'lv.ironwolf.hdd/lv.ironwolf.hdd' failed:   Activation of logical volume lv.ironwolf.hdd/lv.ironwolf.hdd is prohibited while logical volume lv.ironwolf.hdd/lv.ironwolf.hdd_tmeta is active.

 

[ledufakademy]

Just seing , grub boot with proxmox VE .
then initramFS ... after that :
blinking top left cursor , what are you doing with proxmox VE ?
when finally achieve to WebGui : can't see my LVM storage , does it meens promox kill all our datas ?

GREAT !!!

activating LV 'RAID6-14TB/RAID6-14TB' failed: Activation of logical volume RAID6-14TB/RAID6-14TB is prohibited while logical volume RAID6-14TB/RAID6-14TB_tmeta is active. (500)

 

[ledufakademy]

the updates to 7.1-12 and from kernel 5.13.19-6 to 5.13.19-15 has solved this awfull issue !!!

 

[Krypty]

It's not an LVM bug, but should rather be considered a bug in Proxmox VE's (and likely Debian's) init configuration/handling. What (likely) happens is that the thin_check during activation takes too long and pvscan is killed (see here for more information).

Another workaround besides the one suggested by @Fidor should be setting

thin_check_options = [ "-q", "--skip-mappings" ]

in your /etc/lvm/lvm.conf and running update-initramfs -u afterwards.

EDIT2: Upstream bug report in Debian

EDIT: The workaround from @Fidor doesn't seem to work when the partial LVs are active:

Activation of logical volume pve/data is prohibited while logical volume pve/data_tmeta is active.

It would require deactivating XYZ_tmeta and XYZ_tdata first.

Just wanted to share that setting thin_check_options as suggested by Fabian_E worked for me. I have two identical 12TB disks, and for whatever reason one of them will not activate after a reboot of the Proxmox server. I used to have to do the lvchange -an/lvchange -ay method but thin_check_options made this a non-issue.

Hopefully there's no real downside to this.