Boxes: Recover deleted VM? Help needed

Hi all,

I messed up quite badly by accidentally deleting a VM in Boxes. This particular VM had some important files on it. I would greatly appreciate any help on how to recover this image. Needless to say, keeping important stuff on a VM without proper backup routines in place is bad on so many levels. But here I am…

Host-OS: Pop!_OS 20.04 LTS 64-bit
Gnome-boxes: 3.36.5-stable

I will try to recap what happened below, step by step.

  1. Before all problems started I had a total of 2 VMs in Boxes. The one with the important stuff I will call “img01” and is an Ubuntu 22.04 LTS machine. The other one is based on a different OS and is not related to this situation.

  2. In an effort to create a new VM, for another use case, I started off by cloning “img01”. We can call this new one “img02”. The plan was to revert “img02” to a “clean state” snapshot which was created in “img01” long time ago (before the important files were created).

  3. Apparently the snapshots associated with “img01” didn’t show up for “img02” in Boxes. After some digging I found the snapshot xml files under ~/.config/libvirt/qemu/snapshot/. The relevant subfolders here are called boxes-unknown/ (for “img01”) and boxes-unknown-2/ (for “img02”). I figured I could simply copy the snapshot files from boxes-unknown/ to boxes-unknown-2/.

  4. By doing this the snapshots were associated with “img02” in Boxes, after restarting the application. So under the properties for “img02”, I revert the state to a particular snapshot. Everything seems ok, but when the reverting process is finished the “img02” VM won’t start, and gives an error message in Boxes. This is not exactly shocking.

  5. (*) No big deal. In Boxes, I right-click to delete the “img02” VM, as it is not working anyway. For a split second the dialog with the “Undo” button shows up. Then, BOTH “img01” and “img02” disappear in the GUI. I panic and reboot the computer. When starting Boxes again, ONLY the non-working “img02” is available.

(* This is what happened, to the best of my memory, when the deleting took place. But I would say that there is a slight chance that I accidentally clicked the “img01” icon instead of “img02”. This would make more sense, given the actual outcome.)

So, what do I do now? Where do the files go when the VMs are deleted in Boxes? And for how long? I would assume this is OS dependent. In the desktop Trash-folder there are no Boxes related files.

There are some traces of “img01” under ~/.config/libvirt/ and ~/.config/gnome-boxes/, but it’s quite confusing (to me at least) because of the similarities with “img02”.

Under ~/.local/share/gnome-boxes/images there are two files, “boxes-unknown” and the unrelated image for the other VM. They appear to be QCOW2 files. It would make more sense to me if the remaining image file was named “boxes-unknown-2”, instead of “boxes-unknown”. The file is time-stamped yesterday, when the “img02” VM was created.

Again, any suggestions on how to solve this mess are greatly appreciated. Let me know if you need to know more details. I could also provide you with logs etc. In that case, please describe where the log files are located or if I should be using some specific terminal commands.

I think you could attempt to create new virtual machines from these qcow2 files. In Boxes 42 (you can get on Flathub) you can feed the qcow2 file to the VM creation assistant and select the operating system. This will likely allow you to boot into the contents of these qcow2 files (which are the disks of your VM).

Thank you for input, Felipe.

I’ll make an attempt the, way you suggest. However, even if I do succeed to boot into the “boxes-unknown” QCOW2 file I’m afraid the disk is reverted to a state when the important files didn’t exist. But it’s definitely worth a try.

I’ll give an update once I’ve tried this method.

Ok, so I was able to boot into the remaining disk image (I could clearly see that the other file is unrelated because it’s using another OS). Not by using Boxes 42, but through a different QEMU emulation software. Unfortunately, the disk is reverted to the “clean” state without the important files (see points 3 and 4 in the original post).

The alternatives I could think of now is:

  1. Try to find the other “img01/02” QCOW2 image, if that file still exists somewhere on the host file system. Again, there are no such files in the Trash and I’m not really sure where else to look for it.
  2. Try to undo the snapshot revertion (is that even a word?) on the QCOW2 file, if that is possible somehow. I still have access to the “clean state” xml snapshot file, if that helps. Unfortunately, I have never created any late stage snapshots of the original disk image.
  3. Using a tool to do some advanced disk analysis on the bootable image itself. Could it be possible to find some “later stage” files on a snaphot reverted disk this way?

Any advice is greatly appreciated! Let me know if you need further details.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.