local-LVM not available after Kernel update on PVE 7

@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.
 
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.
 
A quick workaround:

Create a new systemd service:
Bash: 
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:
Bash: 
systemctl daemon-reload
systemctl enable lvm-fix.service

Reboot the server
 
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.
 
  • Like
Reactions: 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).

Another workaround besides the one suggested by @Fidor should be setting
Code: 
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:
Code: 
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.
 
Last edited:
  • Like
Reactions: wonko6x9, Nathan_B, Chris and 7 others
Fabian_E said:
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).
Click to expand...
Yes, I am following this discussion.

Fabian_E said:
Another workaround besides the one suggested by @Fidor should be setting...
Click to expand...
I will try to check soon
 
Fabian_E said:
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
Code: 
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:
Code: 
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.
Click to expand...
Do I have to add it to a special section of lvm.conf?
 
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

Code: 
lvchange -a n lvm/lvm_tmeta
lvchange -a n lvm/lvm_tdata
lvchange -ay       (can take some time to run)
 
Last edited:
  • Like
Reactions: miczmc and rolandmade
Fabian_E said:
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
Code: 
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:
Code: 
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.
Click to expand...

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.

Code: 
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.
 
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)
 
Fabian_E said:
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
Code: 
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:
Code: 
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.
Click to expand...

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.
 
  • Like
Reactions: rolandmade
You must log in or register to reply here.
Top Bottom