Created attachment 2129707 [details]
journal.txt

Created attachment 2129708 [details]
rpm-qa.txt

I've seen this one in openQA logs at least once, while trying to debug something else.

I notice that xdp-gtk and xdp-gnome are both installed. This seems similar to the early issues that existed on KDE when xdp-gtk and xdp-kde trying to activate would break things. I'm not sure why this would be cropping up now in Workstation, but it might be something to poke at. Maybe try removing xdp-gtk and see what happens?

> Maybe try removing xdp-gtk and see what happens

x-d-p-gtk is the fallback and a required dependency of gnome-shell (and x-d-p-kde for that matter...)

dnf will prevent you from removing x-d-p-gtk because that would uninstall gnome-shell and gnome-shell as marked as protected

In general: x-d-p-gtk is required for x-d-p to function correctly, because it's the generic fallback portal impl

I think this can also cause the welcome window on live images to be delayed (which can cause openQA tests to fail).

So, I rebuilt xdg-desktop-portal-gnome with the .service file tweaked to run it with -v , reproduced the problem, and checked the logs. It's interesting - it seems like the first start attempt just does nothing at all, like there are no messages logged. We see:

Feb 25 22:28:22 localhost-live systemd[1815]: Starting xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...

but then there's nothing at all logged by the process after that. Then it times out and starts again, and immediately starts logging verbosely:

Feb 25 22:29:06 localhost-live systemd[1815]: xdg-desktop-portal.service: start operation timed out. Terminating.
Feb 25 22:29:06 localhost-live systemd[1815]: xdg-desktop-portal.service: Failed with result 'timeout'.
Feb 25 22:29:06 localhost-live systemd[1815]: Failed to start xdg-desktop-portal.service - Portal service.
Feb 25 22:29:06 localhost-live gnome-software[2631]: Cannot get portal org.freedesktop.portal.Settings version: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer 'org.freedesktop.portal.Desktop': startup job failed
Feb 25 22:29:06 localhost-live gjs[2460]: Cannot get portal org.freedesktop.portal.Settings version: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer 'org.freedesktop.portal.Desktop': startup job failed
Feb 25 22:29:06 localhost-live systemd[1815]: Starting xdg-desktop-portal.service - Portal service...
Feb 25 22:29:07 localhost-live systemd[1815]: xdg-desktop-portal-gnome.service: start operation timed out. Terminating.
Feb 25 22:29:07 localhost-live systemd[1815]: xdg-desktop-portal-gnome.service: Failed with result 'timeout'.
Feb 25 22:29:07 localhost-live systemd[1815]: Failed to start xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).
Feb 25 22:29:07 localhost-live systemd[1815]: xdg-desktop-portal-gnome.service: Consumed 798ms CPU time over 45.020s wall clock time, 127.3M memory peak.
Feb 25 22:29:07 localhost-live systemd[1815]: Starting xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...
Feb 25 22:29:07 localhost-live xdg-desktop-portal-gnome[3138]: XDP: Monitoring /etc/fonts/fonts.conf
Feb 25 22:29:07 localhost-live xdg-desktop-portal-gnome[3138]: XDP: Monitoring /etc/fonts/conf.d
...

so, on the first startup attempt, it must be getting stuck very early, before it would log "XDP: Monitoring /etc/fonts/fonts.conf".

It looks like this broke between 49.0 and 50.alpha. I'll try and bisect more tomorrow.

Ah, the commit log from 49.0 to 50.alpha is very short and most of it is non-code stuff, so it should be a fairly easy bisect. It seems highly likely this is caused by one of:

commit 88d474a4fc7337984b7d44394ad2f6eadf20615a
Author: Jonas Ådahl <jadahl>
Date:   Mon Nov 17 16:59:06 2025 +0100

    Update libgxdp to override GTK settings
    
    Closes: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/186
    Part-of: <https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/239>

commit a4e520ff8512d424801aaa308a3672b3fe4355b2
Author: Sebastian Wick <sebastian.wick>
Date:   Wed Oct 15 17:22:33 2025 +0200

    globalshortcuts: Send the activation token from shell to the frontend
    
    Since 82347e30 ("global-shortcuts: Allow passing activation tokens in
    (de)actiavated") the frontend supports passing through an activation
    token when a shortcut gets activated/deactivated.
    
    Recent versions of shell send the activation-token as well. Connect the
    shell with the frontend!
    
    Part-of: <https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/merge_requests/235>

commit 056029c6506dd1e7bd285943099e9fcc091cff8b
Author: Marco Trevisan (Treviño) <mail>
Date:   Thu Sep 18 17:30:17 2025 +0200

    screencast: Disconnect signal handlers on data free
    
    We may still receive dbus requests while the dialog handle has been
    free'd, so disconnect any signal bound to to it when free'ing it

Annoyingly, this does seem to be specific to the live boot: I can't get it to reproduce on an installed system, even with autologin enabled to be more similar to the live boot. I'm not sure what the difference is, but it makes bisecting more inconvenient (as I have to build a live image at each step).

It looks to me like it's "Update libgxdp to override GTK settings". I did a scratch build with the previous libgxdp forced in - https://koji.fedoraproject.org/koji/taskinfo?taskID=142778111 - and built a live image with that build in it; I've booted that image 20 times and not hit the problem once. On regular images I usually hit the problem after 4 or 5 tries. It's easy to spot whether you hit the problem, because if you did, the "Welcome to Fedora Linux" window takes a long time to appear; if it appears in less than 15-20 seconds on boot, it means you didn't hit the problem. You can confirm with the journal messages, but that's the easy way.

So, that means this is caused by https://gitlab.gnome.org/GNOME/libgxdp/-/merge_requests/8 , as that's the only significant change in the libgxdp version bump. Ping mclasen...

Agh, crap, this bug is determined to make me look like an idiot. It was reproducing relatively easily in testing some other images earlier today, but I just figured I'd confirm I could still reproduce it easily with the Fedora-Workstation-Live-44_Beta-1.1.x86_64.iso image and I cannot. I've booted it about 40 times and haven't hit the bug once. No clue whether I'm just getting incredibly (un)lucky, there's some kind of wall clock element to this, or what.

So that makes it harder to say the libgxdp thing is actually the problem. I guess I'll bash at it some more tomorrow.

(In reply to Adam Williamson from comment #10)
> Annoyingly, this does seem to be specific to the live boot

Yesterday, I've seen a situation once where the gnome-initial-setup (after the installation is done and system rebooted) took a long time to display. I haven't checked the logs, but it might be the same cause. Not sure if OpenQA detected some issues in g-i-s startups?

(In reply to Adam Williamson from comment #12)
> but I just figured I'd confirm I could still reproduce it easily with the
> Fedora-Workstation-Live-44_Beta-1.1.x86_64.iso image and I cannot. I've

You can rest easy, I just reproduced the issue with that image.

> Not sure if OpenQA detected some issues in g-i-s startups?

There's necessarily quite a lot of slack in the timeout for g-i-s, because we're waiting for a whole system boot, which can vary quite a bit in speed. So, no, openQA is pretty unlikely to fail even if g-i-s takes 45 seconds longer than expected.

> You can rest easy, I just reproduced the issue with that image.

Sure, but the problem is it makes bisecting problematic because it's very hard to declare an image 'good'. I thought I had it isolated to the libgxdp change because I booted an image with libgxdp downgraded a bunch of times and didn't hit the bug...but turns out that probably isn't good enough :(

I'll set up an openQA test cannon for this today, looks like we'll need that unfortunately. I was trying to get away without needing it, but...sigh.

Hmm, so with a test cannon, it looks like this happens even with xdg-desktop-portal-gnome 49.1, kinda implying the problem might be in another component, but I'll have to try and check for sure exactly when the problem showed up.

I *did* manage to get a backtrace of the stuck process (by building a live image with a build of x-d-p-g with the systemd timeout bumped to 5 minutes, booting it till the problem happened, then `gdb attach`ing to the process). Here it is:

#0  __syscall_cancel_arch () at ../sysdeps/unix/sysv/linux/x86_64/syscall_cancel.S:56
No locals.
#1  0x00007f56d02721ec in __internal_syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=271) at cancellation.c:49
        result = <optimized out>
        pd = <optimized out>
        ch = <optimized out>
#2  0x00007f56d0272234 in __syscall_cancel (a1=<optimized out>, a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, a5=a5@entry=8, a6=a6@entry=0, nr=271) at cancellation.c:75
        r = <optimized out>
#3  0x00007f56d02eca66 in __GI_ppoll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>, sigmask=sigmask@entry=0x0) at ../sysdeps/unix/sysv/linux/ppoll.c:42
        tval = {tv_sec = 0, tv_nsec = 535828664}
#4  0x00007f56cf836504 in gst_poll_wait (set=0x561607e0b2b0, timeout=<optimized out>) at /usr/include/bits/poll2.h:101
        tsptr = <optimized out>
        _g_boolean_var_76 = <optimized out>
        mode = <optimized out>
        ts = <optimized out>
        t = <optimized out>
        restarting = 0
        is_timer = <optimized out>
        res = -1
        old_waiting = <optimized out>
        __func__ = "gst_poll_wait"
        _g_boolean_var_84 = <optimized out>
#5  0x00007f56cf898f1e in exchange_packets (l=l@entry=0x561607e030d0) at ../gst/gstpluginloader.c:1042
        res = <optimized out>
        __func__ = "exchange_packets"
#6  0x00007f56cf89abb9 in plugin_loader_free (loader=0x561607e030d0) at ../gst/gstpluginloader.c:175
        cur = <optimized out>
        got_plugin_details = <optimized out>
        fsync_ret = <optimized out>
#7  0x00007f56cf84983a in clear_scan_context (context=0x7ffd7eee72e0) at ../gst/gstregistry.c:1145
No locals.
#8  scan_and_update_registry (write_changes=1, default_registry=0x561607df1440, registry_file=<optimized out>, error=0x7ffd7eee72c0) at ../gst/gstregistry.c:1875
        plugin_path = <optimized out>
        changed = 0
        l = <optimized out>
        context = {registry = 0x561607df1440, helper_state = REGISTRY_SCAN_HELPER_RUNNING, helper = 0x561607e030d0, changed = 0}
        __func__ = <optimized out>
        _g_boolean_var_128 = <optimized out>
#9  ensure_current_registry (error=0x7ffd7eee72c0) at ../gst/gstregistry.c:1952
        reuse_env = <optimized out>
        registry_file = <optimized out>
        default_registry = 0x561607df1440
        do_update = <optimized out>
        have_cache = <optimized out>
        __func__ = <optimized out>
#10 gst_update_registry () at ../gst/gstregistry.c:2025
        err = 0x0
        __func__ = "gst_update_registry"
#11 0x00007f56cf7cb78e in init_post (error=<optimized out>, data=<optimized out>, group=<optimized out>, context=<optimized out>) at ../gst/gst.c:804
        __func__ = <optimized out>
        _g_boolean_var_18 = <optimized out>
#12 0x00007f56cf7cc73d in init_post (error=<optimized out>, data=<optimized out>, group=<optimized out>, context=<optimized out>, context=<optimized out>, group=<optimized out>, data=<optimized out>, error=<optimized out>) at ../gst/gst.c:827
        __func__ = "init_post"
        _g_boolean_var_19 = <optimized out>
        _g_boolean_var_20 = <optimized out>
        _g_boolean_var_21 = <optimized out>
#13 0x00007f56d174a6f9 in g_option_context_parse (context=context@entry=0x561607de53d0, argc=argc@entry=0x0, argv=argv@entry=0x0, error=error@entry=0x7ffd7eee7540) at ../glib/goption.c:2077
        group = <optimized out>
        i = 32598
        k = <optimized out>
        list = 0x561607de61a0
        __func__ = "g_option_context_parse"
#14 0x00007f56cf7c35db in gst_init_check (argc=argc@entry=0x0, argv=argv@entry=0x0, error=error@entry=0x7ffd7eee7540) at ../gst/gst.c:416
        group = <optimized out>
        ctx = 0x561607de53d0
        res = <optimized out>
        __func__ = "gst_init_check"
#15 0x00007f56cf7c367c in gst_init (argc=argc@entry=0x0, argv=argv@entry=0x0) at ../gst/gst.c:455
        err = 0x0
#16 0x00007f56d0d73f1d in gtk_gst_media_file_get_type_once () at ../gtk/media/gtkgstmediafile.c:100
        g_define_type_id = 94652621279664
#17 0x00007f56d0a76a8b in gtk_gst_media_file_get_type () at ../gtk/media/gtkgstmediafile.c:100
        g_define_type_id = <optimized out>
        static_g_define_type_id = <optimized out>
#18 gtk_media_file_extension_init () at ../gtk/gtkmediafile.c:625
        ep = 0x561607de4dd0
        scope = <optimized out>
        paths = <optimized out>
        i = <optimized out>
#19 do_post_parse_initialization () at ../gtk/gtkmain.c:606
        display_manager = <optimized out>
        text_dir = <optimized out>
        before = 21254337048
#20 gtk_init_check () at ../gtk/gtkmain.c:659
        ret = <optimized out>
        __func__ = <optimized out>
#21 gtk_init_check () at ../gtk/gtkmain.c:643
        ret = <optimized out>
        __func__ = "gtk_init_check"
#22 0x00005615d6b63210 in gxdp_wayland_init (service_client_type=GXDP_SERVICE_CLIENT_TYPE_PORTAL_BACKEND, error=0x7ffd7eee7670) at ../subprojects/libgxdp/src/gxdp-wayland.c:283
        local_error = 0x0
        proxy = 0x561607dd93d0
        fd_variant = 0x7f56b0002d80
        fd_list = 0x561607ddb670
        fd = <optimized out>
        fd_str = 0x561607db9ab0 "8"
#23 gxdp_init_gtk (service_client_type=GXDP_SERVICE_CLIENT_TYPE_PORTAL_BACKEND, error=0x7ffd7eee7670) at ../subprojects/libgxdp/src/gxdp.c:69
        forced_gdk_backend = 0x0
        session_type = <optimized out>
#24 gxdp_init_gtk (service_client_type=GXDP_SERVICE_CLIENT_TYPE_PORTAL_BACKEND, error=0x7ffd7eee7670) at ../subprojects/libgxdp/src/gxdp.c:34
        forced_gdk_backend = <optimized out>
        session_type = <optimized out>
        _g_boolean_var_10 = <optimized out>
#25 main (argc=<optimized out>, argv=<optimized out>) at ../src/xdg-desktop-portal-gnome.c:304
        owner_id = <optimized out>
        error = 0x0
        session_bus = <optimized out>
        signal_handler_source = 0x0
        context = 0x561607dd5550
quit
Detaching from program: /usr/libexec/xdg-desktop-portal-gnome, process 2737
[Inferior 1 (process 2737) detached]

Hmmm. That perhaps points to:

https://gitlab.gnome.org/GNOME/gtk/-/commit/7436533d8948939ff9c9f4d4283802fbf5f8c20c "media: Initialize gstreamer when loading the module"
which is part of:
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7186

The commit date is 2021, but it was only submitted in a PR in 2024 and only *merged* in November; it looks like it only arrived in Fedora with gtk4-4.21.5-2.fc44 , which was tagged on Feb 6. The previous build in Fedora was gtk4-4.21.1-2.fc44 , and 4.21.1 did not include that commit.

mclasen, that's you again; wdyt?

on matrix, mclasen pointed to https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9547 as another place where this is currently being discussed, and we agreed that https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/9547/diffs?commit_id=057a90b4751b207142b60f4d2b94636ccd5a2cd1 from that MR may well help with this. I'll do a scratch build of GTK with that patch applied and fire the test cannon at it.

It looks a lot like that commit does fix this, yeah. At least, I fired the test cannon ~80 times and got no failures. I'll fire it a few more just to be sure.

We might want to consider this for a Beta, if we have enough time before Go. Marking as such.

Discussed on the Fedora Blocker Review Meeting on March, 2nd 2026 with the resolution.

Accepted Beta FreezeException

See https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2026-03-02/f44-blocker-review.2026-03-02-17.00.log.txt