Disp-VM starts and goes down a few moments later

Qubes-Whonix
1

I´ve discovered a problem and I´m not sure whether it´s one of Qubes or Whonix. It occurred a few weeks ago and was only resolved by completely reinstalling the Whonix system and its clones.

This problem has now reappeared in a clone since today after the Whonix update and looks like this:

When I call up a disp, it immediately goes down a few seconds later without the disp-window being visible.

Simply removing the disp-vm-template and reinstalling it is of no use; I think the error must therefore lie somewhere in the update from the Gateway or the Workstation or other.

Now I will reinstall the entire Whonix system, create the clone, update it, and see what happens.

What is the reason for that? Definitely a very annoying error followed by a lot of work.

Thank you for your opinions.

EDIT with new error:

In the attempt to completely eliminate the Whonix clone with qvm-purge, a new template suddenly appears with the name “dummy,” which is supposedly intended to serve as the basis for “sys-whonix-clone.” This template cannot be removed. Renaming the dependencies also does not lead to a better result.

I suspect that the “purge” command processes in the wrong order and causes a conflict. It is probably better to delete all VMs of a clone or even the original one individually rather than using the purge command.

Generally, the clone function in Qubes seems to have a lot of bugs that only appear in specific situations.

2

I haven’t noticed this myself, but will attempt to reproduce it. (Depending on what software you had installed in your Whonix-Workstation template, it’s possible you ran into a recent Chromium fontconfig bug which could cause Qt-based apps to immediately crash. DispVMs go down when the first app opened in them closes, so that might be an explanation. Any Chromium-based browser and potentially even Electron-based applications might theoretically cause the problem. The issue has been fixed upstream though and should hopefully not be a problem for much longer.)

3

I’m not sure if this is relevant, but I’ve encountered a similar issue in the past where VMs failed to boot due to memory allocation. Specifically, when trying to allocate too much RAM, the VM would hit a Kernel Panic during the memory expansion phase and shut down immediately.

1 Like
4

I didn´t use any software in the disp. I only started it with the “start-button” in the app-menu. Further, I didn´t allocate any RAM in it or in other VMs. But I´ll install the whonix-system again and then we´ll see what happens.

1 Like
5

Cant produce, im on fresh Qubes 4.3.2 with everything installed fresh + backup VMs = all good.

2 Likes
6

I´ve installed Whonix and it´s clons again (after removing all) and the problem doesn`t appear until now.

While updating the new installation, I noticed the following:

I removed and reinstalled the entire Whonix system. As original and as a clone.

Then I first updated the gateway VM (via sys-whonix). That went very quickly, in my opinion, way too quickly. Therefore, I checked the Tor Control Panel to see if it had been updated via Tor, but there was no typical entry like “deb.qubes-os.org” or “deb.kicksecure.com” etc. under the circuits on the left side.

I then looked at the update log and discovered the following line that gives me pause:

Refreshing available packages.
Refreshed.
Fetching 233 packages [119.01 MiB]
Fetched.
/usr/lib/python3/dist-packages/apt/cache.py:410: Warning: W:Download is performed unsandboxed as root as file ‘/var/cache/apt/archives/partial/libc6-dev_2.41-12+deb13u4_amd64.deb’ couldn’t be accessed by user ‘_apt’. - pkgAcquire::Run (13: Permission denied)
Updating packages.
res = fetcher.run()
Preconfiguring packages …

Then I restarted sys-whonix and the information appeared in the Tor Control Panel, the update also took much longer. But the line from earlier still appeared and is confusing, so I ask for clarification on whether this is a problem or not.

With the clone, it worked with both the gw-18 and the ws-18.

Could it be that despite the settings in the Qubes-Global-Config, the very first gateway update occurs over Clearnet?

In this context, the indication of the hard disk space consumption for the two gateways and workstations is also interesting:

For the workstations, the consumption is identical (3729.2 MiB). With the gateways, it differs by almost 300 MiB (gw = 3049.27 MiB, with the gateway clone only 2930.48 MiB). How can that be? The two gateways were updated in quick succession without any installations or changes being made.

7

The gateway being smaller sounds like less apt packages were downloaded and placed in apt’s cache. It’s possible one of the VMs you updated simply had less updates to install than the other one, unless I’m misunderstanding your setup. (It’s kind of hard to know how the clone and the vanilla installation differ and which one of the two you’re updating at each step when reading the description above.) The line you mention looks like a normal part of apt operating, though it’s a bit strange that you have a partially downloaded libc6 package hanging around. You might want to delete that file from the template; it’s part of apt’s cache so deleting it almost certainly can’t harm anything.

8

I will explain again for better understanding how I proceeded.

First, I downloaded the gateway and the workstation, then created “sys-whonix” and “anon-whonix” securely.

Then I cloned the gateway (“whonix-gateway2”), then the workstation (“whonix-workstation2”), and then created the “sys-whonix2” and again the anon-whonix clone (“anon-whonix2”).

So I have two completely pure systems, but intended for different purposes.

In the next step, I first updated the original, that is, the downloaded system, first the gateway, then the workstation.

In the final step, I completely shut down the original and then updated the clone in the same order as the original (via its own “sys-whonix2”).

I will try to delete the file. The warning “iDownload is performed unsandboxed as root” makes me the most suspicious.

1 Like
9

I assume “securely” means followed what mentioned in the wiki:

I assume you have cloned the Templates and created appVMs based on them, BUT “sys-whonix” is the default appVM for the original and the cloned ones (default N/A means they gonna use sys-whonix original), have you changed that for the new cloned ones (by /etc/qubes/policy.d/ from dom0)?

I assume you have done that properly dom0 as mentioned above, because changing that from GUI qubes manager → net qube is not the proper way to handle this.

If you done as mentioned above, post what you have added in the policy so i can reproduce from my end.

1 Like