Bug 2418196 - openQA remote desktop test often displays blank white screen, seems like session fails to start correctly
Summary: openQA remote desktop test often displays blank white screen, seems like sess...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-remote-desktop
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jonas Ådahl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-12-02 02:34 UTC by Adam Williamson
Modified: 2026-03-05 16:44 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
log extract from a passed test (showing the session starting normally) (36.39 KB, text/plain)
2025-12-02 02:34 UTC, Adam Williamson
no flags Details
log extract from a failed test (not much happens for a while after the smartcard errors, then a timeout) (36.62 KB, text/plain)
2025-12-02 02:35 UTC, Adam Williamson
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME gnome-remote-desktop issues 307 0 None opened GNOME Remote Desktop (RDP remote login) connects but shows a blank white screen and disconnects shortly afterwards (Fedo... 2026-03-05 16:44:17 UTC

Description Adam Williamson 2025-12-02 02:34:14 UTC
The openQA remote desktop test seems quite often to fail with the client showing just a blank white screen, then failing back to the connection selection screen (using Connections as the client).

On the server end, we see these log messages that seem significant when it fails:

Dec 01 20:34:27 kaermorhen.test.openqa.fedoraproject.org gnome-remote-desktop-daemon[2277]: 0;1;38:5:185m0;1;38:5:185m[DaemonHandover] Failed to request remote desktop handover: Timeout was reached
Dec 01 20:34:30 kaermorhen.test.openqa.fedoraproject.org gnome-remote-desktop-daemon[914]: 0;1;38:5:185m0;1;38:5:185m[DaemonSystem] Aborting handover, removing remote client with remote id /org/gnome/RemoteDesktop/Client/3839824341
Dec 01 20:34:30 kaermorhen.test.openqa.fedoraproject.org gnome-remote-desktop-daemon[914]: [20:34:30:186] [914:00000392] [ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_CB_CONNECTION_CANCELLED [0x00010409]

when the test passes, we don't see those messages, we instead see a bunch of expected busywork messages from the session starting up. I'm attaching server log extracts from passed and failed tests covering the same approximate timeframe when the client was attempting to connect to the server.

Comment 1 Adam Williamson 2025-12-02 02:34:49 UTC
Created attachment 2117025 [details]
log extract from a passed test (showing the session starting normally)

Comment 2 Adam Williamson 2025-12-02 02:35:24 UTC
Created attachment 2117026 [details]
log extract from a failed test (not much happens for a while after the smartcard errors, then a timeout)

Comment 3 Jerry James 2026-02-27 17:11:08 UTC
I'm seeing the same symptoms trying to connect to a machine at work.  Most of the time it works, but I occasionally get the blank screen and nothing happens thereafter.  I've been restarting gnome-remote-desktop then trying again, and that has worked ... until the most recent freerdp update, to version 3.23.0.  Now I get the blank screen every single time.  I've tried restarting gnome-remote-desktop, rebooting the machine ... no joy.  This may be relevant: https://github.com/FreeRDP/FreeRDP/issues/12388.  For now, I've downgraded to 3.22 so I can get some work done.

Comment 4 Adam Williamson 2026-03-05 16:44:04 UTC
openQA testing doesn't show the same, Jerry - since 3.23.0 landed in Rawhide we're still seeing the same "sometimes passes, sometimes fails" behavior. e.g. in today's Rawhide it failed on the Workstation live and disk image tests, but passed on the upgrade tests (where we start out at Fedora 44, upgrade to Rawhide, then run the test). On 20260303.n.0 it passed on the disk image test - https://openqa.fedoraproject.org/tests/4373012 . That compose definitely had 3.23.0, I checked.


Note You need to log in before you can comment on or make changes to this bug.