Bug 1921947

This is a clear violation of https://fedoraproject.org/wiki/Basic_Release_Criteria#Installer_must_run , "The installer must run when launched normally from the release-blocking images."

The installer was working on Wayland for months. I made the switch back in November[1][2].

It's possible that there's something funky about the switch to systemd user sessions[3]. Rex had pulled in some fixes for that[4][5], which might help.


[1]: https://src.fedoraproject.org/rpms/plasma-workspace/c/c401c311ba92598dcf37997e06ccfbb0186269b9?branch=master
[2]: https://src.fedoraproject.org/rpms/sddm/c/e8d8c16c2d17fcd3dba572f53de359fd31437999?branch=master
[3]: https://src.fedoraproject.org/rpms/plasma-workspace/c/364da8e9c2b292af6239de774bab5badea675161?branch=master
[4]: https://src.fedoraproject.org/rpms/plasma-workspace/c/bc9ef72076507b7015970aebe2d625f605419bea?branch=master
[5]: https://src.fedoraproject.org/rpms/kwin/c/653b2e3c2bca0fedd98ac01aab6246ad4acf014c?branch=master

So...not really figured this out yet, but got a bit more data anyway.

It broke between 20210124.n.0 and 20210127.n.1 (there are no successful composes between those too), by the looks of things. anaconda didn't change in 01217.n.1, and neither did anything GTK+-y or gobject-y that I can see. What did change is indeed plasma-workspace, from 5.20.90-3 to 5.20.90-5, which included the systemd user sessions change.

The problem seems to be that GTK initialization is failing at the bottom of gi/overrides/Gtk.py , where it does (for GTK+ 3, which is what we're on) `initialized, argv = Gtk.init_check(sys.argv)` . If you add a debug print right there, it shows that `initialized` winds up as False. The console line "No protocol specified" is printed during this check, but I'm not sure if that's significant or not.

I reduced Gtk.py to what should be a simple reproducer, but it *doesn't* reproduce, at least not when run directly:

    import sys

    from gi.repository import GObject
    from gi.module import get_introspection_module


    Gtk = get_introspection_module('Gtk')
    initialized, argv = Gtk.init_check(sys.argv)

    print(initialized)

if I run that directly as liveuser or root, it prints True. So either something else about what Gtk.py does, or what gets done before it, or about running through consolehelper, results in the different outcome, I guess.

re-assigning to plasma-workspace, at least tentatively.

Switching off systemd user sessions by renaming /etc/xdg/startkderc to /etc/xdg/startkderc.disabled does not fix this.

I attempted to run Anaconda (by running liveinst in Konsole) and still get the same traceback as I do with systemd user sessions enabled.

(In reply to Neal Gompa from comment #5)
> Switching off systemd user sessions by renaming /etc/xdg/startkderc to
> /etc/xdg/startkderc.disabled does not fix this.
> 
> I attempted to run Anaconda (by running liveinst in Konsole) and still get
> the same traceback as I do with systemd user sessions enabled.

I forgot to mention, I rebooted between those runs where I disabled or enabled systemd user sessions. Since Anaconda is installed on an installed system, I attempted to run that from Konsole, and that's where I saw the tracebacks.

I can reproduce this on fedora 33 plasma wayland session as well. plasma x11 session starts ok.

Created attachment 1755447 [details]
Screenshot of Anaconda working with xhost +

Some *weird* progress...

I was able to get Anaconda to run by doing the following (in Rawhide 20210206.n.0 build):

$ xhost +
$ liveinst

That causes Anaconda to start up correctly and I can run through installation.

Created attachment 1755462 [details]
Diff of the environment variables between GNOME and KDE Plasma

I took a sample of the environment variables between GNOME and KDE with the same Rawhide compose, and attached the output of the diff between the two.

The main differences I note that might have an impact:

* No XAUTHORITY variable pointed to Xauthority socket
* Different value for DISPLAY

I suspect the lack of Xauthority socket is the failure mode here.

This is likely caused by Kwin, since it starts the Xwayland bits in the Wayland session...

When investigating a prior sddm issue, I found it only sets xauthority bar for x sessions.  We could consider setting it unconditionally.

liveinst-setup does some "xhost" stuff, but it doesn't work: https://github.com/rhinstaller/anaconda/blob/59231a831ef6647fe81d9c6971b98a2ab7d9b520/data/liveinst/liveinst-setup.sh#L11

I tried it manually, and "xhost +si:localuser:root" does not work in Plasma. This is *definitely* because of the difference in Wayland session initialization in Plasma vs GNOME. Even switching to GDM does not fix it.

I've filed a bug upstream with KDE: https://bugs.kde.org/show_bug.cgi?id=432625

Thanks for figuring that out, Neal!

I've cherry-picked a fix proposed upstream into our kwin package[1] and notified upstream that it fixes our issue in my local testing.

I've pushed a build into Koji too: https://koji.fedoraproject.org/koji/buildinfo?buildID=1705067

It should be fixed with the next compose.

[1]: https://src.fedoraproject.org/rpms/kwin/c/f6befa54b9a3202eca123f10e53b6c19d21f0959?branch=rawhide

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

FEDORA-2021-2a1eb24b14 contains a potential fix. Setting to ON_QA.

Yes, this is indeed fixed now.