Debian stretch: QXcbConnection: Could not connect to display :0

qubenix commented 8 years ago

Qubes OS version (e.g., `R3.1`):

r3.2

Affected TemplateVMs (e.g., `fedora-23`, if applicable):

Debian Stretch

Expected behavior:

After following instructions in documentation for upgrading Debian 8 to stretch all guis work as before upgrade.

Actual behavior:

No gui will open after the final shutdown of the TemplateVM. If an application is executed from the Applications Menu, after an hour still no application has launched. However, applications are launched fine after the upgrade in the TemplateVM terminal. Only after shutdown and restart is the template broken.

Via dom0:

[user@dom0 ~]$ qvm-run --pass-io d8-stretch "konsole"
QXcbConnection: Could not connect to display :0

All commands passed which do not require display work just fine.

[user@dom0 ~]$ qvm-run --pass-io d8-stretch "cat /etc/apt/sources.list.d/qubes*"
#deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm jessie main
#deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm jessie-testing main
#deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm jessie-securitytesting main
#deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm jessie-unstable main
deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm stretch main
[user@dom0 ~]$ qvm-run --pass-io d8-stretch "cat /etc/apt/sources.list.d/debian*"
#deb http://http.debian.net/debian jessie main contrib non-free
#deb-src http://http.debian.net/debian main/jessie main contrib non-free

#deb http://security.debian.org jessie/updates main contrib non-free
#deb-src http://security.debian.org jessie/updates main contrib non-free

deb  http://vwakviie2ienjx6t.onion/debian stretch main contrib non-free
deb http://sgvtcaew4bxjd7ln.onion stretch/updates main contrib non-free

Steps to reproduce the behavior:

Follow upgrade instructions to upgrade from Debian 8 to stretch completely. Restart TemplateVM, attempt to exec an application which requires display.

General notes:

Breaks documentation on at least these three pages:

https://www.qubes-os.org/doc/templates/debian/

https://www.qubes-os.org/doc/pentesting/kali/

https://www.qubes-os.org/doc/debian-template-upgrade-8/

Related issues:

https://github.com/QubesOS/qubes-issues/issues/2370 (might be duplicate, close if so)

unman commented 8 years ago

@qubenix Works for me exactly as per instructions. Can you provide more information about your system? What versions dom0 packages do you have? Did you install additional software or re-configure the debian-8 template before running the upgrade?

qubenix commented 8 years ago

My dom0 is updated from qubes-dom0-current-testing.

My debian-8 template did have software added. I'm trying again from a clone of a vanilla debian-8 template, will report back.

qubenix commented 8 years ago

Worked for me with a vanilla template. I still have the template that is broken and I can give any info from it for debugging, for instance: /var/log/apt/history.log. Or the issue can be closed, renamed, etc.

unman commented 8 years ago

Interesting - thanks for investigating. Clearly history.log and dpkg-query -l output will be useful. Also if you can confirm the versions of your dom0 packages?

I think it's worth keeping this open as it will likely affect other users: best to get to the bottom of it now. @andrewdavidwong Agreed? (If not, we can take to qubes-users or off-list)

qubenix commented 8 years ago

Here are the details you requested:

Broken Template: /var/log/apt/history.log

Broken Template: dpkg-query -l

Dom0 packages

andrewdavidwong commented 8 years ago

@unman: Agreed. Keeping it open.

unman commented 7 years ago

@qubenix I have not been able to reproduce this. As you know, upgrading the vanilla template to stretch works fine: I then followed your history log, installed the same packages and did not encounter your issue. I also tried running through the history, installing all the same packages on jessie, and finally upgrading to stretch. Again, the process went smoothly. I tested before and after the autoremove, and didn't encounter your issue. Of course, the packages I took for stretch are slightly different versions from those that you identify in your package list, so it is just possible that a version you downloaded had slightly different requirements from those in my packages, resulting in a broken autoremove.

However, I see from the package lists a number of significant differences - for example, you have qubes-gui-agent at 3.2.6+deb8u1. This would only have been available from a testing repo, since the version in Jessie stable is 3.2.5+deb8u1. The version in the stable Stretch repo is 3.2.5+deb9u1. My guess is that you were upgrading using Jessie testing repos. When you attempted to upgrade, none of the qubes files for Stretch were installed, because of the versioning difference. Now it isn't clear to me why this happened, since the instructions should have resulted in your pulling files from the stretch testing repo. I did test this: following the instructions with jessie testing enabled left a qubes-r3.list sources file with the stretch testing repository enabled, and dist-upgrade produced a working system.

Is it possible that you enabled the testing repo at one stage and then disabled it before running the upgrade? Can you check the contents of qubes-r3.list, and try running the upgrade with stretch testing enabled?

@andrewdavidwong I think this can be closed.

qubenix commented 7 years ago

However, I see from the package lists a number of significant differences - for example, you have qubes-gui-agent at 3.2.6+deb8u1. This would only have been available from a testing repo,...

Nice find! I did have qubes testing repos first, then attempted upgrade to stretch. Closing.

QubesOS / qubes-issues