Recent content by udotirol

I ran into a somehow similar issue when migrating a VM, albeit not with the affinity setting but with a very special set of low level qemu args. I guess it boils down to the same privilege issue? 2025-05-29 11:00:32 ERROR: error - tunnel command...

your calculation makes sense, yes ... yet again, it is somehow hard to believe ... And so I decided to have a look at some other servers and devices coming with those devices and what shall I say, it appears, you're correct after all :) With a similar drive and the identical firmware I see...

yes, I'm aware of that limitation (that is shared by many cheap SSDs, even today). Like I said, hard to believe though that a pure boot device running PVE can generate so much written data.

No, percent lifetime remaining says 116 (RAW_VALUE). The 240 you are referring to are from the VALUE column. The VALUE column represents the "normalized", current value of the attribute on a scale of usually 1 to 253 (sometimes also 1 to 100). WORST is the worst value observed so far in the...

One of our servers uses two Crucial MX500 SSDs in a ZFS RAID1 setup as boot drives. By chance, I checked the servers' SMART values in the UI and it shows a whopping negative -140% wearout. Not sure what to make of this? In the shell, smartctl -a doesn't show anything extraordinary except the...

thanks @leesteken, the idea of shrinking the swap partition and using the additional space for the /boot partition got me on the right track :) I didn't use GParted but did it on the running node. In case anyone stumbles on this as well, here's what I did as root (assuming that md0 is mounted...

One of my PVE nodes has been installed some years ago and even though it has always upgraded it to the newest PVE version (currently 8.4.3), one thing has been bothering me for a while. When the node was installed, it was done by using ext4 & mdstat, ending in a partition layout like this: $...

thanks a lot, this is really much appreciated!

thanks again @Fantu for those really helpful explanations! For the time being, I think I have experimented enough with the effects of this likely hardware issue and my next step would be to remove the faulty device from my RAID1 array or "profile" in btrfs terms :) Simply attempting to remove...

First thank you @Fantu and @waltar for your support so far. I've had a little time today to investigate the issue further, and I found some strange things. This time, from the grub command line, which I ended upon reboot, I could successfully do a ls (hd0,gpt3)/ as well as a ls (hd1,gpt3)/...

well, looks like I'm back at square one: the node again only boots into grub. Yesterday evening I decided to start a scrub, and that ended in low level block storage errors like these: [27979.988958] nvme nvme1: I/O tag 604 (b25c) opcode 0x2 (I/O Cmd) QID 8 timeout, aborting req_op:READ(0)...

Thanks for the extensive explanation. What I did with clonezilla is to just see if I could manually mount the two btrfs partitions like I did before with the proxmox live system. And I could, apparently, it just worked. I didn't perform any cloning or whatever, but headed directly to the...

well, and it get's even more fascinating. After just mounting and subsequently unmounting the two partitions in clonezilla, I attempted a simple reboot into proxmox and that worked. After booting, the ring buffer contains heaps of lines like these, however: [Mon Jan 6 15:47:54 2025] BTRFS...

I am afraid, I wasn't clear enough, sorry. blkid shows that both partitions on both NVMes have the same UUID (see my last screenshot). What is different, is the error message I get. One says "device 1 uuid 3f3d..." and when trying with the other NVMe, I get a different "device 2 uuid 6...."...

it's the same, unfortunately, just bailing out with a different UUID