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

Brad · August 19, 2022, 6:00am

I am aware that there is already some documentation about this, most notably:

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

opened 03:05PM - 06 Jun 18 UTC

T: bug C: core P: major hardware support needs diagnosis C: storage affects-4.1

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:

I will need people to bear with me on this as I don’t understand how github works but from my reading of the link above it appears to be solved?

The problem has come out of the blue. I don’t make many demands of my qubes machine and there was no bad shutdowns etc. What I will say is that a couple of weeks ago I upgraded to the latest Fedora and also updated dom0. I have posted elsewhere that since I did that I have to unplug my usb keyboard otherwise the pc gets caught in a loop that keeps taking me back to the disk encryption pw. That problem never resolved and now I have this problem.

This link here:

Comes up with this solution:

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)*

I’m stuck on the first part of locating the logical volume…the solution is probably staring at me but is asking beyond my current skill level.

Another suggestion from ADW was to reboot dom0.

So, if I could get a couple of pointers.
1. ADW’s problems here were resolved with a reboot of dom0. If I reboot/restart it returns the same error. Can I reboot dom0 from the terminal and is this what I should be doing rather than shutdown/restart from the GUI? Is there an advantage to a terminal reboot?
2. Can anybody walk me through how to plug the correct commands for the path to my logical volume as per the solution above?

I will be very grateful if I can rescue things from here. Otherwise I have my crucial qubes backups that are a week old so they would do at a pinch.

Thanks for any tips, pointers, solutions.

adw · August 20, 2022, 6:08pm

Both ways of rebooting dom0 are equivalent. It sounds like you just have a different problem than the one that I had, even though we got similar error messages.

I’m not very familiar with the volume stuff either, so I’m afraid I can’t be of much help there.

Brad · August 21, 2022, 5:32am

Well, it looks like I stumbled onto a solution. The only science was me punching in things to the terminal that I came across. But, it seems to be fixed.
First up I tried the above solution (that I am sure didn’t work the other day). I got an error message telling me that a particular appVM was doing something (can’t remember what as I was just resigned that I wouldn’t be able to fix it and I was already resigned to a reinstall so I was going for it). I was able to delete this VM as I had it cloned anyway).

But a reboot didn’t fix it. So I had a look at the git documentation. I tried these of which neither worked

  sudo lvremove vm-sys-whonix-private-tmp  

  qvm-remove sys-whonix

Then I tried this below (which was corrected code)

   lvremove qubes_dom0/vm-sys-usb-root-snap

Then it was crash through or crash. A place I’ve been to before with Linux! From this it asked me if I wanted to individually remove a whole bunch of files (105?). Anyway, I just deleted the lot and rebooted and it booted as normal without my deleted VM.

Everything appears to be fine. All my qubes are there, all the templates, nothing missing.

So, I don’t know if unscientific things like this actually help, but I’m relieved that I got this back at least allowing me to immediately back my qubes up. Happy until the next time!