Logical volume "vm-sys-net-volatile" already exists in volume group"qubes_dom0"

gg11331 · January 14, 2022, 4:59pm

How I can solve this problem?

adw · January 15, 2022, 3:41pm

Try rebooting dom0.

github.com/QubesOS/qubes-issues

ERROR: Logical Volume "vm-sys-<vm-name>-root-snap" already exists in volume group "qubes_dom0"

opened 03:05PM - 06 Jun 18 UTC

closed 02:31PM - 24 Dec 21 UTC

tortugaverde98

T: bug C: core P: major diagnosed C: storage

Qubes 4.0 ### Affected component(s): All VMs ### Steps to reproduce the …behavior:  Boot computer, decrypt, and log in. ### Expected behavior: VMs start as usual, sys-usb, sys-net, sys-firewall, etc. ### Actual behavior: No VMs start. No USB items function. When attempting to start a VM, an error is provided: ERROR: b' Logical Volume "vm-sys-usb-root-snap" already exists in volume group "qubes_dom0" \n' Everything appeared normal when I shut it down last night, with the exception that I had to kill the vault VM since it repeatedly prompted for it. That was the first time vault didn't shut down cleanly on its own. Typically that only happens with the VPN VMs and it never caused a problem. I rebooted repeatedly today in hopes it would resolve itself but to no avail. Any VM which has internet access, when attempting to start, references vm-sys-net-root-snap in the error. Presumably because that is the first VM in the chain that must start. Oddly, except sys-usb which references itself, VMs which do not have internet access, such as vault, when attempting to start, provide a different, puzzling error: ERROR: b" Can't create snapshot vm-sys-whonix-private as origin vm-sys-whonix-private -snap is not suspended.\n Failed to suspend qubes_dom0/pool00 with queued messages.\n" Why offline VMs should refer to sys-whonix is beyond me. I lack the skills to troubleshoot this. Any and all help would be extremely appreciated. ### General notes: --- ### Related issues:

user3 · May 3, 2022, 5:26pm

After my system crashed and rebooted I had the same error message. I was able to fix it by issuing the following commands in dom0:

dom0: lvdisplay (and searching for the path to the logical volume, e.g. lvdisplay|grep vm-sys-net-volatile)
dom0: lvremove (e.g. lvremove /dev/qubes_dom0/vm-sys-net-volatile)

My expectation was that the volatile logical volumes are only temporary. So by deleting it I only lose the temporary changes after the last reboot of the VM. It worked like expected, but I didn’t check for any data loss. I was able to boot the VM and all was working like expected.