Consolidating for Convenience and Algorithm Hell
I realize this information is available elsewhere, but by consolidating and reposting it here, I hope it helps both with search algorithms and for anyone facing similar issues. Plus, it saves me the trouble of tracking down the original sources when the problem inevitably crops up again. So yes, there’s a method to my madness.
I recently upgraded my Proxmox, Yunohost, Nextcloud, and Plex server to an HP DL380 G9. In the process, I nearly doubled the cores, more than doubled the memory, and tripled the drive capacity. After a series of headaches, I finally got everything transferred, upgraded, updated, backed up, and running just the way I wanted.
The final touch was installing an old Nvidia Quadro 4000 GPU, which the server should support—or so I thought. Unfortunately, the server choked on it. Despite having dual 800W PSUs, it turns out the system needs at least one 1400W PSU to support a GPU. So, no GPU for me. How did I find this out? The server refused to boot, throwing a hard error. It wouldn’t even post—just a blinking light and nothing else.
Once I pulled the GPU and rebooted, the server came back, but then I was greeted by a new error during boot:
“timed out for waiting the udev queue being empty”
The system would boot into Proxmox, but none of the VMs would start. Manually attempting to launch them threw this cryptic error:
“TASK ERROR: activating LV ‘pve/data’ failed: Activation of logical volume pve/data is prohibited while logical volume pve/data_tmeta is active.”
This was complete gibberish to me, so naturally, I turned to Google. After some digging, I found limited help, but most references pointed back to this article (written in Indonesian):
https://www.aviantorichad.com/2021/07/solved-mengatasi-lvm-proxmox-hilang.html?m=1
The author had a similar issue, though in his case, the VMs weren’t even visible (lucky me, mine were still in the menu, albeit with those dreaded question marks). Following his advice, I ran these three commands:
# lvchange -an pve/data
# lvconvert --repair pve/data
# lvchange -ay pve/data
The first command was quick, but the second took forever, likely because one of my VMs is nearly 7TB. After what felt like an eternity, the system finally processed it.
After rebooting, the node reappeared, but the VMs were still MIA.
Not ready to give up, I stumbled upon this thread in the Proxmox forums:
https://forum.proxmox.com/threads/local-lvm-not-available-after-kernel-update-on-pve-7.97406/page-2#post-430860
Here, @Fiona, a Proxmox staff member, recommended adding the following line to /etc/lvm/lvm.conf:
thin_check_options = [ "-q", "--skip-mappings" ]
After adding that and running update-initramfs -u, I rebooted again, and everything finally came back online. In fact, the reboot was faster than ever—probably a sign that this problem had been simmering for a while.
While the system is running smoothly now, I can’t help but wonder: is using --skip-mappings skipping something important for long-term system health? That’s a research project for another day. For now, I’m happy to have my server back, and I can turn my attention to the myriad of other projects waiting in the wings.
In the end, it was another day in the life of server management—fun, fun, fun. If you’re facing similar issues, I hope this saves you some time. If not, well, at least I’ve saved myself from having to search for the fix again!
