All Debian-based AppVMs are not displaying after update

I hope you are all safe and healthy.

I’m using Qubes 4.0 and xfce4 (xfce4-panel 4.12.0). Most of my AppVMs are based on Debian-10, and few ones on Fedora 26. Yesterday I’ve applied the updates that were alerted as available in the panel, and I remember that they included dom0.

Today I realized that any of those Debian AppVM I have are unable to be displayed on my screen. They can be initiated and kept in execution, however the applications are not appearing on my screen. Fedora-based and dom0 work as usual.
I’ve also noted that the dom0 graphical interface was updated, including functions like Switch User in the upper-right menu, and Run Program… in the upper-left menu.

I have already searched for similar issues and tried some commands (like calling the xterm using a Debian AppVm from dom0, no success). As this time I’m under a very strict academic schedule, it would be better to share this issue in advance.
This is the output of /var/log/qubes/guid.debian-10.log that may provide a clue about what is happening. Any recommendations to fix/workarounds would be extremely appreciated.

Icon size: 128x128
Icon size: 128x128
domain dead
Failed to connect to gui-agent

Thank you very much in advance!


1 Like

This is familiar but unfortunately I can’t remember how I solved it. I think I just reinstalled the Debian 10 as a new template in the end.

1 Like

More info:

It seems to be very similar to this issue:

Below is the output of ps x | grep (AppVM’s name)

FedoraVM (working ok):
10681 ? SLs 0:00 /usr/sbin/qubesdb-daemon 12 FedoraVM
10684 ? SLs 0:00 /usr/lib/qubes/qrexec-daemon -q 12 FedoraVM user
10698 ? SLs 0:01 /usr/bin/qubes-guid -N FedoraVM -c 0x555753 -i /usr/share/icons/hicolor/128x128/devices/appvm-gray.png -l 5 -q -d 12
10701 ? SL 0:00 pacat-simple-vchan -l 12 FedoraVM
10708 ? S 0:00 /usr/bin/python3 /usr/bin/qrexec-policy – 12 FedoraVM dom0 qubes.WindowIconUpdater SOCKET8
10709 ? SL 0:00 /usr/lib/qubes/qrexec-client -d dom0 -c SOCKET8 FedoraVM 12 QUBESRPC qubes.WindowIconUpdater FedoraVM name dom0
10713 ? S 0:00 logger -t qubes.WindowIconUpdater-FedoraVM -f /tmp/qrexec-rpc-stderr.10710

DebianVM (not working ok):
10877 ? S 0:00 /usr/bin/python3 /usr/bin/qvm-run -q -a --service – DebianVM qubes.StartApp+org.gnome.Terminal
11125 ? SLs 0:00 /usr/sbin/qubesdb-daemon 13 DebianVM
11128 ? SLs 0:00 /usr/lib/qubes/qrexec-daemon -q 13 DebianVM user
11139 ? SL 0:00 /usr/lib/qubes/qrexec-client -d DebianVM DEFAULT:QUBESRPC qubes.WaitForSession dom0
11142 ? SLs 0:00 /usr/bin/qubes-guid -N DebianVM -c 0x73d216 -i /usr/share/icons/hicolor/128x128/devices/appvm-green.png -l 4 -q -d 13
11146 ? SL 0:00 /usr/lib/qubes/qrexec-client -d DebianVM DEFAULT:QUBESRPC qubes.SetMonitorLayout dom0

And a “systemctl status qubes-gui-agent” shows “Unit qubes-gui-agent.service could not be found.”

Thanks again,


The last update was a pain… Most of my hvm’s can’t access the created additional virtual disks. A few can. I can’t also switch a virtual drive back from an hvm to a qubes pvh. I’ll survive for a while.

1 Like

Problem solved!

The issue was really weird, as it seemed like it was not restricted to X. While I was able to use Qube Manager and retrieve some logs from both the template as the AppVMs, I was unable to get an output from commands like “qvm-run --pass-io” issued from dom0 to Debian AppVMs (only) when trying to retrieve some config files to take a look.

Still, after re-reading some recommendations from issue #4140, I’ve decided to try to use the testing version of xserver-xorg-core. I jumped from dom0 to my Debian10TemplateVM shell with the “sudo xl console Debian10TemplateVM”, made a backup of /etc/apt/sources.list and replaced the strings “buster” by “testing” using sed as that shell is not so friendly with vi :slight_smile:
Once the sources.list was ready, I proceeded with apt-get update and upgrade. And that was when the reason of the issue was revealed:

“No space left on disk.”

That was the reason the previous update was broken somewhere, making all AppVMs act the way as described in this case.
Quickly, I restored the original sources.list, adjusted the disk space on Qubes Manager and proceeded with a new apt-get update and upgrade. Everything went just fine. Once my laptop was rebooted, my Debian AppVMs launched working 100% well.

My next step now is try to find out what levels of alert were generated during the upgrade process when the disk went to full capacity. Usually, the update app always alert very clearly when something didn’t work as expected. This time I don’t recall seeing anything similar (however, without proof I still need to consider human error here). Moreover, during all reboots performed after the error, neither Qubes Manager nor other Qubes app alerted that one of the base templates was full, which would raise red flags. And if this is the case, there would be a good suggestion for improvement on further versions.
Thanks to everyone who followed and share any ideas to this thread. Hope this can help any user in the future.