Qubes 4.0-rc4 - qvm-run on stopped VM is starting VM, but not application

[maaca]

Qubes OS version:

4.0-rc4

Steps to reproduce the behavior:

Executing:
qvm-run <whatever_vm> <whatever_command>
is starting VM, but command is not executed, no app window is opened.
qvm-run is working well with started VM.

Expected behavior:

Expecting to have started VM and executed command inside it.

Worked well in 4.0-rc2 and 4.0-rc3

General notes:

---

Related issues:

[andrewdavidwong]

Related thread:
https://groups.google.com/d/topic/qubes-users/PDIQzFlupS0/discussion

[andrewdavidwong]

Related thread:
https://groups.google.com/d/topic/qubes-users/PDIQzFlupS0/discussion

[awokd]

@maaca Could you please verify your templates and dom0 are using the same repository (both are set to the Testing one for example) and have both been updated recently?
If not, try that and see if it fixes it? I did experience some strange behaviour when I had dom0 on Testing but my template on Current.

[awokd]

@maaca Could you please verify your templates and dom0 are using the same repository (both are set to the Testing one for example) and have both been updated recently?
If not, try that and see if it fixes it? I did experience some strange behaviour when I had dom0 on Testing but my template on Current.

[awokd]

And in case it's not clear in the above comment, I mean your Qubes repositories (these https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories and https://www.qubes-os.org/doc/software-update-vm/#testing-repositories) only, not your operating system ones.

[awokd]

And in case it's not clear in the above comment, I mean your Qubes repositories (these https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories and https://www.qubes-os.org/doc/software-update-vm/#testing-repositories) only, not your operating system ones.

[maaca]

@awokd It is fresh 4.0-rc4 installation with default Fedora-26 template. Testing and unstable repos are disabled in both, template and dom0. Both are updated.

[maaca]

@awokd It is fresh 4.0-rc4 installation with default Fedora-26 template. Testing and unstable repos are disabled in both, template and dom0. Both are updated.

[awokd]

@maaca Thanks. I'm on testing on both and it's working fine for me. Maybe there's already a fix out there and it just needs to be pushed to current, or could be some other issue entirely.

[awokd]

@maaca Thanks. I'm on testing on both and it's working fine for me. Maybe there's already a fix out there and it just needs to be pushed to current, or could be some other issue entirely.

[mirrorway]

On 4.0rc4, I can reproduce this by having two VM { ... } sections in /etc/qubes/guid.conf, for example bad-guid.conf.txt. More generally, it might be caused by a malformed guid.conf, so maybe check yours?

It seems like it takes a few minutes / VM restarts after sabotaging the guid.conf file for qvm-run's to start hanging, and there is a similar delay after fixing guid.conf for qvm-run to start working again.

[mirrorway]

On 4.0rc4, I can reproduce this by having two VM { ... } sections in /etc/qubes/guid.conf, for example bad-guid.conf.txt. More generally, it might be caused by a malformed guid.conf, so maybe check yours?

It seems like it takes a few minutes / VM restarts after sabotaging the guid.conf file for qvm-run's to start hanging, and there is a similar delay after fixing guid.conf for qvm-run to start working again.

[maaca]

@mirrorway I've only uncommented allow_fullscreen in the guid.conf.txt.
VM starts normally in tens of seconds.

[maaca]

@mirrorway I've only uncommented allow_fullscreen in the guid.conf.txt.
VM starts normally in tens of seconds.

[awokd]

@maaca OK, fresh install of 4.0rc4 with 0 patches or other system changes. qvm-run work firefox starts Firefox whether the work qube has already been started or not. Rebooted to make sure it wasn't an issue with the first qube to start.

VM starts normally in tens of seconds.

This makes me wonder if your VMs aren't starting quickly enough and qrexec is timing out. What is your qvm-prefs <vmname> qrexec_timeout set to? Default is 60 seconds, maybe try making it 120 if your VMs take longer?

[awokd]

@maaca OK, fresh install of 4.0rc4 with 0 patches or other system changes. qvm-run work firefox starts Firefox whether the work qube has already been started or not. Rebooted to make sure it wasn't an issue with the first qube to start.

VM starts normally in tens of seconds.

This makes me wonder if your VMs aren't starting quickly enough and qrexec is timing out. What is your qvm-prefs <vmname> qrexec_timeout set to? Default is 60 seconds, maybe try making it 120 if your VMs take longer?

[maaca]

@awokd Setting qrexec_timeout to higher value didn't help.

Maybe heplful finding: I run qvm-run, it is running for cca 5 seconds. Then qvm-run ends (without error) and xfce is showing "Domain xxxx is started", but in qvm-ls I can see that the VM state is "Transient".

[maaca]

@awokd Setting qrexec_timeout to higher value didn't help.

Maybe heplful finding: I run qvm-run, it is running for cca 5 seconds. Then qvm-run ends (without error) and xfce is showing "Domain xxxx is started", but in qvm-ls I can see that the VM state is "Transient".

[marmarek]

@maaca did you had any problems during installation? I guess the relevant template isn't marked as supporting GUI applications, so starting the VM do not wait until X server is started there. You can verify this with qvm-features fedora-26 (in case of fedora-26 template). There should be gui entry. If it's missing, add it with:

qvm-features fedora-26 gui 1

And the same for qrexec - both should be set there.

[marmarek]

@maaca did you had any problems during installation? I guess the relevant template isn't marked as supporting GUI applications, so starting the VM do not wait until X server is started there. You can verify this with qvm-features fedora-26 (in case of fedora-26 template). There should be gui entry. If it's missing, add it with:

qvm-features fedora-26 gui 1

And the same for qrexec - both should be set there.

[maaca]

@marmarek Thank you for the hint. Adding these features solved the issue.

You are right, I had to run post-installation setting twice, because it failed first time. The second run went well, so I forgot on that.

[maaca]

@marmarek Thank you for the hint. Adding these features solved the issue.

You are right, I had to run post-installation setting twice, because it failed first time. The second run went well, so I forgot on that.

[andrewdavidwong]

Closing this as "resolved." If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.

[andrewdavidwong]

Closing this as "resolved." If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.