Unable start any qube after forcefully canceling wyng backup

Yes, I would say 79% usage for the metadata volume is very concerning/risky. The basic issue here is that metadata use can fluctuate much quicker than data use when complex operations are causing fragmentation, even if only momentarily. Therefore, I stopped following my data use % as an indicator and got better results by keeping metadata use well below 50%. You can do this with lvextend --poolmetadatasize <size> qubes_dom0/vm-pool. In your case I would at least double the current size. You might need to free up space in the volgroup before you can lvextend; in that case what I’ve done is to temporarily turn off dom0 swap with swapoff then use lvresize to shrink the swap lv a bit, and finally use mkswap to reformat the swap lv and then swapon -a.

I’m not aware of an auto-resize in Qubes. I do recall they were very concerned that some people were filling up their pool data, leaving dom0 root fs unable function and often making Qubes un-bootable. What they did in 4.1 was to move dom0 root to a separate dom0-only pool so that failure can’t happen again.

If i get it correctly, I’ll be able to load my lvm wyng backup on the btrfs partition?

Wyng will restore volumes that originated on LVM just fine on Btrfs or other fs, but it will be up to you to rename them appropriately under the new setup because you will have pathless LVM names like “vm-work-private”. There are different ways you can do this, such as renaming the archive vols to the right path before doing the receive. For example, wyng <dest> rename vm-work-private appvms/work/private.img – and then: wyng <dest> --local=/var/lib/qubes receive appvms/work/private.img. (The wyng-util-qubes wrapper currently in development will be able to handle this pathname difference automatically.)

Also note that in order to be able to wyng send from Btrfs the local path should be a subvolume. This is how I set it up (using the Qubes default pool as an example):

cd /var/lib
qvm-shutdown --all --force --wait
sudo mv qubes qubes-old
sudo btrfs subvolume create qubes
sudo mv qubes-old/* qubes

Of course, there are different ways to setup Qubes itself, so your main VM pool may have a different path than ‘/var/lib/qubes’.

1 Like