DispVM doesn't start or load any applications. (Qubes 4.0 rc2)

[Lolibyte]

Qubes OS version: 4.0 rc2

Affected TemplateVMs: fedora-25-dvm and whonix-ws-dvm

---

Steps to reproduce the behavior:

1. Start fedora-25-dvm OR whonix-ws-dvm using any application added in the start menu
2. Wait until the disp. VM starts.
3. Qubes says the VM starts.

Expected behavior:

Applications open.

Actual behavior:

Applications do not open - the VM is crashed.

General notes:

Apologies if this is already a logged issue. I spent a few minutes checking around to make sure it wasn't duplicated and I couldn't find any.

If you check the Qubes VM manager, it'll show the DispVM in the list, but after it's done starting up it disappears and the applications don't open.

I also tried in debug mode, the terminal opens and it starts. It works until it reaches "Login" and then the terminal closes and the vm crashes.

---

Related issues:

[andrewdavidwong]

Does this happen with all applications, or only certain ones (e.g. xterm)?

[andrewdavidwong]

Does this happen with all applications, or only certain ones (e.g. xterm)?

[Lolibyte]

It happened to every application I tried.

[Lolibyte]

It happened to every application I tried.

[na--]

What happens when you run this in dom0 as a normal user?
qvm-run --verbose --autostart --service --dispvm=fedora-25-dvm -- qubes.StartApp+xterm

I could reproduce your issue only with gnome terminal - just a brief flicker of a window and the dispvm is gone. Other apps started normally and the dispvm stayed until I closed the application, so I assume that the issue is with gnome terminal in my case.

[na--]

What happens when you run this in dom0 as a normal user?
qvm-run --verbose --autostart --service --dispvm=fedora-25-dvm -- qubes.StartApp+xterm

I could reproduce your issue only with gnome terminal - just a brief flicker of a window and the dispvm is gone. Other apps started normally and the dispvm stayed until I closed the application, so I assume that the issue is with gnome terminal in my case.

[na--]

Another partial replication with whonix-ws-dvm: tor browser and Konsole work as expected, but Dolphin and WhonixCheck don't

[na--]

Another partial replication with whonix-ws-dvm: tor browser and Konsole work as expected, but Dolphin and WhonixCheck don't

[adrelanos]

Please check if this is a duplicate of #3187. @Lolibyte @na--

If this is a duplicate, please provide the requested debug output from comment #3187 (comment).

[adrelanos]

Please check if this is a duplicate of #3187. @Lolibyte @na--

If this is a duplicate, please provide the requested debug output from comment #3187 (comment).

[na--]

@adrelanos does not seem like it, at least in my case.

In my case I think the DispVMs start normally but in some cases the code that tracks whether the started application has exited (so the DispVM can be stopped and removed) malfunctions. Not sure exactly what the mechanism is for tracking that, I'll take a look later, but maybe a process fork or something else can confuse it.

[na--]

@adrelanos does not seem like it, at least in my case.

In my case I think the DispVMs start normally but in some cases the code that tracks whether the started application has exited (so the DispVM can be stopped and removed) malfunctions. Not sure exactly what the mechanism is for tracking that, I'll take a look later, but maybe a process fork or something else can confuse it.

[marmarek]

but maybe a process fork or something else can confuse it.

Yes, if process is forking (or other scheme like this - for example dbus service, like gnome-terminal, or nautilus), the mechanism will not work, because "main" process exits almost instantly.
Some idea would be tracking main application window, but it is very fragile. Maybe something based on Startup notification protocol...

But generally it is not something we can do for the final Qubes 4.0. For that, such applications are incompatible with DispVM, unfortunately. A workaround: launch xterm, then such application from there.

[marmarek]

but maybe a process fork or something else can confuse it.

Yes, if process is forking (or other scheme like this - for example dbus service, like gnome-terminal, or nautilus), the mechanism will not work, because "main" process exits almost instantly.
Some idea would be tracking main application window, but it is very fragile. Maybe something based on Startup notification protocol...

But generally it is not something we can do for the final Qubes 4.0. For that, such applications are incompatible with DispVM, unfortunately. A workaround: launch xterm, then such application from there.

[na--]

Ok, that explains all of my issues and probably the only needed fix is to remove the problematic DispVM applications from the default menus and mention something about potential problems in the documentation. The default fedora-25-dvm apps (Firefox and xterm) are ok, but some whonix-ws-dvm default apps (Chat support, Dolphin, TorBrowser Downloader) are problematic, WhonixCheck partially works (the check passes but it quits before the result is displayed) and the rest (Konsole, TorBrowser) are ok.

@Lolibyte: it looks like you have a different issue, can you attach some logs from /var/log/qubes and /var/log/xen/console/ for a specific crashed dispvm?

[na--]

Ok, that explains all of my issues and probably the only needed fix is to remove the problematic DispVM applications from the default menus and mention something about potential problems in the documentation. The default fedora-25-dvm apps (Firefox and xterm) are ok, but some whonix-ws-dvm default apps (Chat support, Dolphin, TorBrowser Downloader) are problematic, WhonixCheck partially works (the check passes but it quits before the result is displayed) and the rest (Konsole, TorBrowser) are ok.

@Lolibyte: it looks like you have a different issue, can you attach some logs from /var/log/qubes and /var/log/xen/console/ for a specific crashed dispvm?

[Lolibyte]

Hello everyone, I have read through everything and I think I do have a different issue.

@na--, I have tried that command that you gave me for dom0 terminal and it does not achieve a different result.

Attached is every log gathered for a DispVM -- there was a pacat.disp52.log but that was empty.

From /var/log/qubes
guid.disp52.log
qrexec.disp52.log
qubesdb.disp52.log
vm-disp52.log

From /var/log/xen/console
guest-disp52.log
guest-disp52-dm.log

[Lolibyte]

Hello everyone, I have read through everything and I think I do have a different issue.

@na--, I have tried that command that you gave me for dom0 terminal and it does not achieve a different result.

Attached is every log gathered for a DispVM -- there was a pacat.disp52.log but that was empty.

From /var/log/qubes
guid.disp52.log
qrexec.disp52.log
qubesdb.disp52.log
vm-disp52.log

From /var/log/xen/console
guest-disp52.log
guest-disp52-dm.log

[andrewdavidwong]

Hello everyone, I have read through everything and I think I do have a different issue.

@Lolibyte, please feel free to create a separate GitHub issue to help keep things organized.

[andrewdavidwong]

Hello everyone, I have read through everything and I think I do have a different issue.

@Lolibyte, please feel free to create a separate GitHub issue to help keep things organized.

[Lolibyte]

@andrewdavidwong Sorry, but I am the original poster of this thread, my "different issue" reference was in reference to @na-- explaining about his issue and that mine is different.

[Lolibyte]

@andrewdavidwong Sorry, but I am the original poster of this thread, my "different issue" reference was in reference to @na-- explaining about his issue and that mine is different.

[andrewdavidwong]

Sorry, but I am the original poster of this thread, my "different issue" reference was in reference to @na-- explaining about his issue and that mine is different.

Oh, I see now! Sorry for the misunderstanding. Thanks for clarifying.

[andrewdavidwong]

Sorry, but I am the original poster of this thread, my "different issue" reference was in reference to @na-- explaining about his issue and that mine is different.

Oh, I see now! Sorry for the misunderstanding. Thanks for clarifying.

[JPL1]

I am also getting this error with rc2

[JPL1]

I am also getting this error with rc2

[tutaleedoo]

A workaround is to restart Qubes OS. This resolved the issue for me, although temporarily (the issue came back).

[tutaleedoo]

A workaround is to restart Qubes OS. This resolved the issue for me, although temporarily (the issue came back).

[tutaleedoo]

After failing to launch an application in a disposable VM, I looked at journalctl and saw "didnt react to memory request"

I wonder if this issue is related to issue #3079

[tutaleedoo]

After failing to launch an application in a disposable VM, I looked at journalctl and saw "didnt react to memory request"

I wonder if this issue is related to issue #3079

[marmarek]

#3079 would result in killing some process - you'd see that in journalctl. Do you see any messages from qubesd service there?

[marmarek]

#3079 would result in killing some process - you'd see that in journalctl. Do you see any messages from qubesd service there?

[tutaleedoo]

@marmarek, I don't see any mention of "kill" in journalctl after reproducing the issue

Here are the qubesd messages:

dom0 qubesd[2399]: Creating directory: /var/lib/qubes/appvms/disp5812
dom0 qubesd[2399]: Creating icon symlink: /var/lib/qubes/appvms/disp5812/icon.png -> /usr/share/icons/hicolor/128x128/devices/appvm-blue.png
dom0 qubesd[2399]: Starting disp5812
dom0 qubesd[2399]: Setting Qubes DB info for the VM
dom0 qubesd[2399]: Starting Qubes DB
dom0 qubesd[2399]: Activating the disp5812 VM
dom0 qubesd[2399]: Removing volume private: appvms/disp5812/private
dom0 qubesd[2399]: Removing volume kernel: 4.9.56-21
dom0 qubesd[2399]: Removing volume root: appvms/disp5812/root
dom0 qubesd[2399]: Removing volume volatile: appvms/disp5812/volatile

[tutaleedoo]

@marmarek, I don't see any mention of "kill" in journalctl after reproducing the issue

Here are the qubesd messages:

dom0 qubesd[2399]: Creating directory: /var/lib/qubes/appvms/disp5812
dom0 qubesd[2399]: Creating icon symlink: /var/lib/qubes/appvms/disp5812/icon.png -> /usr/share/icons/hicolor/128x128/devices/appvm-blue.png
dom0 qubesd[2399]: Starting disp5812
dom0 qubesd[2399]: Setting Qubes DB info for the VM
dom0 qubesd[2399]: Starting Qubes DB
dom0 qubesd[2399]: Activating the disp5812 VM
dom0 qubesd[2399]: Removing volume private: appvms/disp5812/private
dom0 qubesd[2399]: Removing volume kernel: 4.9.56-21
dom0 qubesd[2399]: Removing volume root: appvms/disp5812/root
dom0 qubesd[2399]: Removing volume volatile: appvms/disp5812/volatile

[Echnaton70]

I have the same issue.

This happens after on all restored hvm from 3.2.

Behaviour:
qvm-start works fine.
vm is in the list as started, but no apllication works.

in qubesd messages i found (not know if related)

dom0 qubesd [33432] Warning: Sum of all thin volume sizes (1.87 TiB) exceed the size of thin pool qubes_dom0/pool00 and the size of whole volume group

1,87 TiB is by far not true.

update: not hvm, it happens with standalone vms from qubes os 3.2

[Echnaton70]

I have the same issue.

This happens after on all restored hvm from 3.2.

Behaviour:
qvm-start works fine.
vm is in the list as started, but no apllication works.

in qubesd messages i found (not know if related)

dom0 qubesd [33432] Warning: Sum of all thin volume sizes (1.87 TiB) exceed the size of thin pool qubes_dom0/pool00 and the size of whole volume group

1,87 TiB is by far not true.

update: not hvm, it happens with standalone vms from qubes os 3.2

[JPL1]

I have the same issue with rc3 (and also had it with rc2). It is installed on a 128GB USB3 stick and my PC has 8GB RAM and I have no other VMs open apart from sys-net and sys-firewall, so memory shouldn't be a problem. It happens with both Fedora and Whonix dispVMs, exactly as the OP describes. The dispVM starts, no applications open, then it crashes.

I also tried (see post above).

qvm-run --verbose --autostart --service --dispvm=fedora-25-dvm -- qubes.StartApp+xterm

Same result. I have never managed to get a dispVM working on 4.0 at all.

[JPL1]

I have the same issue with rc3 (and also had it with rc2). It is installed on a 128GB USB3 stick and my PC has 8GB RAM and I have no other VMs open apart from sys-net and sys-firewall, so memory shouldn't be a problem. It happens with both Fedora and Whonix dispVMs, exactly as the OP describes. The dispVM starts, no applications open, then it crashes.

I also tried (see post above).

qvm-run --verbose --autostart --service --dispvm=fedora-25-dvm -- qubes.StartApp+xterm

Same result. I have never managed to get a dispVM working on 4.0 at all.

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.25-1.fc26) has been pushed to the r4.0 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.25-1.fc26) has been pushed to the r4.0 testing repository for the Fedora template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.25-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.25-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 stable repository for the Fedora centos7 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.28-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component core-agent-linux (including package python2-dnf-plugins-qubes-hooks-4.0.28-1.fc26) has been pushed to the r4.0 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.28-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.28-1+deb9u1 has been pushed to the r4.0 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update