X11 applications no longer work with GNOME 3.38 #562
Comments
|
Some apps do work, e.g. emacs (I am running a gtk fork of emacs tho). But in general graphical apps do not work. |
|
Ah, I can open GTK apps here too. Perhaps they're going directly to Wayland and apps depending on X (perhaps even with XWayland) aren't working? |
|
I've logged out and logged back in using GNOME in X mode (non-Wayland) and all apps from within toolbox launch. Obviously, this doesn't fix the problem. 😉
|
|
I've rebooted Silverblue to: ...and I'm in Wayland and can run graphical apps again from toolbox. It looks like toolbox and podman are both at the same versions, so this might actually be an X and Wayland issue? |
|
In a VM with no overrides, I ran an update from (known good; tested running gitk in a toolbox container and it works) (known bad, latest; tested running gitk in a toolbox container and it fails) The changes when upgrading are: Neither podman nor toolbox show up on that list, so it cannot be toolbox or podman directly. It has to be some package on that list that's causing some issues. |
|
Well other things than packages might have changed, |
|
@A6GibKm: Good point. Is there a way to diff /etc/ between versions of Silverblue? (I know how to diff between local changes to /etc/, but not SB's.) |
|
|
|
@A6GibKm: Yep. That's what I was talking about. This is within a VM with an unchanged /etc, so diffing between system and Silverblue's /etc is not useful. (Diffing between /etc might be. Although many of the /etc changes come from packages anyway.) Meanwhile, I redirected env to a file for the system and toolbox in the working and broken states. There's no difference whatsoever in the toolbox container. And there's minimal difference (related to session) on the system. Here's a unified diff of the system's env: --- env-sys-working.txt 2020-09-21 12:56:12.920885043 +0200
+++ env-sys-broken.txt 2020-09-21 12:22:02.406835930 +0200
@@ -1,5 +1,5 @@
SHELL=/bin/bash
-SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1464,unix/unix:/tmp/.ICE-unix/1464
+SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1478,unix/unix:/tmp/.ICE-unix/1478
COLORTERM=truecolor
HISTCONTROL=ignoredups
XDG_MENU_PREFIX=gnome-
@@ -13,7 +13,7 @@
LOGNAME=garrett
XDG_SESSION_DESKTOP=gnome
XDG_SESSION_TYPE=wayland
-XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.RN94Q0
+XAUTHORITY=/run/user/1000/.mutter-Xwaylandauth.4M3FR0
GJS_DEBUG_TOPICS=JS ERROR;JS LOG
GDM_LANG=en_US.UTF-8
HOME=/var/home/garrett
@@ -23,21 +23,21 @@
XDG_CURRENT_DESKTOP=GNOME
VTE_VERSION=6003
WAYLAND_DISPLAY=wayland-0
-GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/72bbb014_1201_4bb5_8d9f_92b981a8fb9c
-INVOCATION_ID=81fe0a9268ce4c879b1c15b9831f9eb1
-MANAGERPID=1367
+GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/70d7dee0_be52_4b18_b618_93ce33bb45b9
+INVOCATION_ID=2faea5011a614329921ff66d8420329d
+MANAGERPID=1374
GJS_DEBUG_OUTPUT=stderr
GNOME_SETUP_DISPLAY=:1
XDG_SESSION_CLASS=user
TERM=xterm-256color
LESSOPEN=||/usr/bin/lesspipe.sh %s
USER=garrett
-GNOME_TERMINAL_SERVICE=:1.97
+GNOME_TERMINAL_SERVICE=:1.91
DISPLAY=:0
SHLVL=1
QT_IM_MODULE=ibus
XDG_RUNTIME_DIR=/run/user/1000
-JOURNAL_STREAM=8:37189
+JOURNAL_STREAM=8:39001
XDG_DATA_DIRS=/var/home/garrett/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
PATH=/var/home/garrett/.local/bin:/var/home/garrett/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
GDMSESSION=gnomeThe only difference I see (aside from the session variances) is GNOME_TERMINAL_SERVICE going from 1.91 to 1.97... but really I doubt it's that. |
|
Out of the list above, the following packages are the ones I'd guess are most likely: And of these, I'd guess mutter, gnome-shell, or gnome-session* are probably the most likely of the bunch to look into first, as this issue deals with X & Wayland issues. (I wonder if @kalev might be able to isolate the issue further?) |
|
Sounds like XWayland not working. I'll ask the gnome-shell people to see if they know what's up. |
|
I am running Version: 33.20200921.n.0 (2020-09-21T08:05:26Z) Silverblue. I have a Toolbox container made when F33 was rawhide. I installed qutebrowser in it (edit: which pulled in a bunch of deps) and had to also install qt5-qtwayland.x86_64 plugin to get it to run, but it runs. I am logged into my Gnome session as default Wayland. |
|
Snippet from #silverblue on Freenode: Since v0.0.94 Toolbox mounts a tmpfs to I'll try to play a bit with socket but I guess this is more of a question for @debarshiray. |
|
That's cause it's now running under Wayland. Xwayland apps are the
problem. Try gvim. Or xeyes.
…On Tue., Sep. 22, 2020, 13:45 Stephen Snow, ***@***.***> wrote:
I am running Version: 33.20200921.n.0 (2020-09-21T08:05:26Z) Silverblue. I
have a Toolbox container made when F33 was rawhide. I installed qutebrowser
in it and had to also install qt5-qtwayland.x86_64 plugin to get it to run,
but it runs. I am logged into my Gnome session as default Wayland.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#562 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA2BH3EMRY7BXDHQPJ3ZGZ3SHCTA7ANCNFSM4RUIRONQ>
.
|
|
You will note my edit above about gvim not working though. I understand XWayland is likely the issue here. |
|
I have a very rough solution for this issue in #564. Comments are very welcome. In general, I'd like to avoid cherry-picking of files as much as possible and I'm wondering whether this wish can be fulfilled here or not. |
|
xeyes does not work either, I get just "cannot open display: :0" |
I can confirm that running:
does indeed make the apps run. |
Some users tend to put random throwaway files in /tmp, so having that
location shared across the host operating system and toolbox containers
makes it a more pleasant user experience.
One nice side-effect of this is that it also makes the local file
system socket in /tmp/.X11-unix used by X11 clients available to
toolbox containers. So far, X11 clients inside toolbox containers used
the local abstract socket. However, since GNOME 3.38, Mutter no longer
listens on the abstract socket and only uses the file system socket to
start the Xwayland server [1]. Therefore, this makes it possible to
run X11 clients inside toolbox containers running on a GNOME 3.38 host.
[1] Mutter commit e2123768f635ee89
https://gitlab.gnome.org/GNOME/mutter/-/issues/1289
containers#562
|
This should be fixed by #570 |
debarshiray
changed the title
debarshiray
changed the title
Some users tend to put random throwaway files in /tmp, so having that
location shared across the host operating system and toolbox containers
makes it a more pleasant user experience.
One nice side-effect of this is that it also makes the local file
system socket in /tmp/.X11-unix used by X11 clients available to
toolbox containers. So far, X11 clients inside toolbox containers used
the local abstract socket. However, since GNOME 3.38, Mutter no longer
listens on the abstract socket and only uses the file system socket to
start the Xwayland server [1]. Therefore, this makes it possible to
run X11 clients inside toolbox containers running on a GNOME 3.38 host.
[1] Mutter commit e2123768f635ee89
https://gitlab.gnome.org/GNOME/mutter/-/issues/1289
containers#562
Re qt5-qtwayland missing dep: https://src.fedoraproject.org/rpms/qutebrowser/pull-request/10 |
Describe the bug
In Fedora 33, graphical applications no longer work from within toolbox containers when in Wayland. This breaks workflows for everyone using Silverblue and is relying on toolbox where graphical applications are needed. (Mainly: development work which may require graphical tools like gitk, VS Code, and so on.)
Steps how to reproduce the behaviour
Expected behaviour
Graphical apps should show up.
Actual behaviour
When running gitk from within toolbox, the following happens:
Output of
toolbox --version(v0.0.90+)toolbox version 0.0.95
Toolbox package info (
rpm -q toolbox)toolbox-0.0.95-1.fc33.x86_64
Output of
podman versionPodman package info (
rpm -q podman)podman-2.1.0-0.179.dev.git43f2771.fc33.x86_64
Info about your OS
Fedora Silverblue 33 beta
Additional context
This worked fine in the 2020-09-14 build of Silverblue 33 beta. It broke somewhere between then and the latest build of 2020-09-20. I believe it is podman related, especially due to it being a dev build.
Did a development version of podman slip into F33/SB, breaking toolbox, again?
..Or is it intended to use podman 2.1.x in Fedora 33 (and therefore toolbox would have to workaround or add support for the new version)?
Discussed in https://discussion.fedoraproject.org/t/issues-with-some-graphical-apps-in-f33-containers-toolbox/23456.
The text was updated successfully, but these errors were encountered: