Bug 2355207 - Remote install via RDP fails (client either drops connection immediately or hangs at a white screen) since Fedora-42-20250316.n.0
Summary: Remote install via RDP fails (client either drops connection immediately or h...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pipewire
Version: 42
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Wim Taymans
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker openqa
Depends On:
Blocks: F42FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2025-03-27 01:07 UTC by Adam Williamson
Modified: 2025-04-03 06:10 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2025-04-03 06:10:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME gnome-remote-desktop issues 254 0 None opened Fails with pipewire 1.4.1: "Failed to start stream: Couldn't connect pipewire context" 2025-03-27 19:30:34 UTC
Github weldr lorax pull 1467 0 None open runtime-postinstall: allow pipewire to run as root 2025-03-29 00:06:03 UTC

Description Adam Williamson 2025-03-27 01:07:59 UTC
Since Fedora-42-20250316.n.0 , the openQA RDP remote install test has been failing. The server end seems to set up OK, but when we connect via GNOME Connections, it either immediately drops back to the main screen, or hangs at a blank white screen.

I can reproduce this locally, running the installer on my test box and GNOME Connections on my main laptop (on F42 Silverblue). If I have the test box use a USB stick written with Fedora-Everything-netinst-x86_64-42-20250315.n.0.iso , things work fine and I can navigate the installer. If I have the test box use a USB stick written with Fedora-Everything-netinst-x86_64-42-20250316.n.0.iso , I hit the bug. In both cases I use the kernel args `inst.rdp inst.rdp.username=test inst.rdp.password=test`.

I have been trying to pin down the cause of this, but it seems weirdly slippery. This is the diff between the packages used to build those two images:

[adamw@toolbx tmp]$ diff -u0 20250315.pkgs 20250316.pkgs 
--- 20250315.pkgs	2025-03-26 16:19:52.095935571 -0700
+++ 20250316.pkgs	2025-03-26 16:19:46.731050959 -0700
@@ -8,2 +8,2 @@
-Install amd-gpu-firmware-20250211-1.fc42.noarch
-Install amd-ucode-firmware-20250211-1.fc42.noarch
+Install amd-gpu-firmware-20250311-1.fc42.noarch
+Install amd-ucode-firmware-20250311-1.fc42.noarch
@@ -21 +21 @@
-Install atheros-firmware-20250211-1.fc42.noarch
+Install atheros-firmware-20250311-1.fc42.noarch
@@ -46,2 +46,2 @@
-Install bootc-1.1.5-1.fc42.x86_64
-Install brcmfmac-firmware-20250211-1.fc42.noarch
+Install bootc-1.1.6-3.fc42.x86_64
+Install brcmfmac-firmware-20250311-1.fc42.noarch
@@ -63 +63 @@
-Install cirrus-audio-firmware-20250211-1.fc42.noarch
+Install cirrus-audio-firmware-20250311-1.fc42.noarch
@@ -182 +182 @@
-Install dvb-firmware-20250211-1.fc42.noarch
+Install dvb-firmware-20250311-1.fc42.noarch
@@ -202,0 +203 @@
+Install fftw-libs-single-3.3.10-15.fc42.x86_64
@@ -327,3 +328,3 @@
-Install intel-audio-firmware-20250211-1.fc42.noarch
-Install intel-gpu-firmware-20250211-1.fc42.noarch
-Install intel-vsc-firmware-20250211-1.fc42.noarch
+Install intel-audio-firmware-20250311-1.fc42.noarch
+Install intel-gpu-firmware-20250311-1.fc42.noarch
+Install intel-vsc-firmware-20250311-1.fc42.noarch
@@ -340,3 +341,3 @@
-Install iwlegacy-firmware-20250211-1.fc42.noarch
-Install iwlwifi-dvm-firmware-20250211-1.fc42.noarch
-Install iwlwifi-mvm-firmware-20250211-1.fc42.noarch
+Install iwlegacy-firmware-20250311-1.fc42.noarch
+Install iwlwifi-dvm-firmware-20250311-1.fc42.noarch
+Install iwlwifi-mvm-firmware-20250311-1.fc42.noarch
@@ -381,2 +382,2 @@
-Install libavcodec-free-7.1-1.fc42.x86_64
-Install libavutil-free-7.1-1.fc42.x86_64
+Install libavcodec-free-7.1.1-1.fc42.x86_64
+Install libavutil-free-7.1.1-1.fc42.x86_64
@@ -426,0 +428 @@
+Install libebur128-1.2.6-11.fc42.x86_64
@@ -432 +434 @@
-Install libertas-firmware-20250211-1.fc42.noarch
+Install libertas-firmware-20250311-1.fc42.noarch
@@ -523,2 +525,2 @@
-Install libswresample-free-7.1-1.fc42.x86_64
-Install libswscale-free-7.1-1.fc42.x86_64
+Install libswresample-free-7.1.1-1.fc42.x86_64
+Install libswscale-free-7.1.1-1.fc42.x86_64
@@ -590,2 +592,2 @@
-Install linux-firmware-20250211-1.fc42.noarch
-Install linux-firmware-whence-20250211-1.fc42.noarch
+Install linux-firmware-20250311-1.fc42.noarch
+Install linux-firmware-whence-20250311-1.fc42.noarch
@@ -619 +621 @@
-Install mt7xxx-firmware-20250211-1.fc42.noarch
+Install mt7xxx-firmware-20250311-1.fc42.noarch
@@ -655 +657 @@
-Install nvidia-gpu-firmware-20250211-1.fc42.noarch
+Install nvidia-gpu-firmware-20250311-1.fc42.noarch
@@ -657 +659 @@
-Install nxpwireless-firmware-20250211-1.fc42.noarch
+Install nxpwireless-firmware-20250311-1.fc42.noarch
@@ -689,2 +691,2 @@
-Install pipewire-1.2.7-4.fc42.x86_64
-Install pipewire-libs-1.2.7-4.fc42.x86_64
+Install pipewire-1.4.1-1.fc42.x86_64
+Install pipewire-libs-1.4.1-1.fc42.x86_64
@@ -764 +766 @@
-Install qed-firmware-20250211-1.fc42.noarch
+Install qed-firmware-20250311-1.fc42.noarch
@@ -771 +773 @@
-Install realtek-firmware-20250211-1.fc42.noarch
+Install realtek-firmware-20250311-1.fc42.noarch
@@ -829 +831 @@
-Install tiwilink-firmware-20250211-1.fc42.noarch
+Install tiwilink-firmware-20250311-1.fc42.noarch

Obviously the thing that sticks out like a sore thumb there is the ffmpeg components - libavcodec-free, libavutil-free, libswresample-free and libswscale-free. So I built an image from the 20250315.n.0 tree but with an additional repo containing the 7.1.1-1.fc42 build of ffmpeg, and...that image isn't affected by the bug. Works fine.

I'm out of time for today, so will try and poke into this more tomorrow. In any case it seems like a blocker bug, so proposing as one per https://fedoraproject.org/wiki/Basic_Release_Criteria#Installation_interfaces - we need to update that to say RDP not VNC, though, since we replaced VNC with RDP in F42.

I'm filing against anaconda for now as I haven't been able to identify what's actually causing this yet.

Comment 1 Adam Williamson 2025-03-27 19:05:24 UTC
Ugh, I'm an idiot. My second guess turns out to be correct - it's pipewire. And I could've figured it out a lot sooner by just looking at the journal on the server end, because it says:

Mar 27 19:01:07 node-1w7jr9qu0rzvjvceq9aaaixdo.ipv6.telus.net gnome-remote-de[3766]: [RDP.CLIPRDR] Relieving CLIPRDR filename restriction
Mar 27 19:01:07 node-1w7jr9qu0rzvjvceq9aaaixdo.ipv6.telus.net gnome-remote-de[3766]: [RDP.CLIPRDR] Client capabilities: long format names, stream file clip, file clip no file paths, can lock clip data, huge file support
Mar 27 19:01:07 node-1w7jr9qu0rzvjvceq9aaaixdo.ipv6.telus.net gnome-remote-de[3766]: Failed to start screen cast stream: GDBus.Error:org.freedesktop.DBus.Error.Failed: Failed to start stream: Couldn't connect pipewire context
Mar 27 19:01:07 node-1w7jr9qu0rzvjvceq9aaaixdo.ipv6.telus.net gnome-remote-desktop[3766]: [19:01:07:278] [3766:00000eb6] [ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_RPC_INITIATED_DISCONNECT [0x00010001]
Mar 27 19:01:07 node-1w7jr9qu0rzvjvceq9aaaixdo.ipv6.telus.net systemd[1]: run-user-0-gnome\x2dremote\x2ddesktop-cliprdr\x2dEW2NPb.mount: Deactivated successfully.

Comment 2 Adam Williamson 2025-03-27 19:20:46 UTC
Oh, sorry, to be clear: it's pipewire-1.4.1-1.fc42 . This is broken by the update from pipewire-1.2.7-4.fc42 to pipewire-1.4.1-1.fc42 . Remote install (and, looking at the error message, I'm guessing any use of gnome-remote-desktop...) works fine with pipewire 1.2.7, breaks with 1.4.1.

Comment 3 Adam Williamson 2025-03-27 19:56:35 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/1814 , marking accepted blocker.

Comment 4 Wim Taymans 2025-03-28 16:17:41 UTC
> Failed to start screen cast stream: GDBus.Error:org.freedesktop.DBus.Error.Failed: Failed to start stream: Couldn't connect pipewire context

This seems to come from here: https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/meta-screen-cast-stream-src.c?ref_type=heads#L2078

It seems something more fundamental, like pipewire is not started or the socket permissions are not correct.

Comment 5 Wim Taymans 2025-03-28 16:37:00 UTC
Could it be this? Does remote install run as root? https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/17eaf83fe80ad7b70ec14b1b92515f8291594f96

Comment 6 Adam Williamson 2025-03-28 18:52:37 UTC
ooh, yeah, it may well be that. I can check it later, in the middle of something else right now.

Comment 7 Adam Williamson 2025-03-28 22:35:23 UTC
OK, yeah, it's exactly that. anaconda, on the traditional installer images, runs as root. There's a log message specifically showing the pipewire socket refusing to start because we're root.

So, this needs sorting out between anaconda and pipewire somehow, I guess. We *could* hack up the service in the installer environment via lorax, feels ugly but it's an option.

Comment 8 Adam Williamson 2025-03-29 00:06:03 UTC
I ginned up https://github.com/weldr/lorax/pull/1467 , that seems to fix this in my testing.

Comment 9 Fedora Update System 2025-03-31 23:57:24 UTC
FEDORA-2025-8d33b5abba (lorax-42.8-1.fc42) has been submitted as an update to Fedora 42.
https://bodhi.fedoraproject.org/updates/FEDORA-2025-8d33b5abba

Comment 10 Fedora Update System 2025-04-01 03:26:13 UTC
FEDORA-2025-8d33b5abba has been pushed to the Fedora 42 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-8d33b5abba`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-8d33b5abba

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2025-04-02 21:59:12 UTC
FEDORA-2025-8d33b5abba (lorax-42.8-1.fc42) has been pushed to the Fedora 42 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 12 Kamil Páral 2025-04-03 06:06:43 UTC
Reopening for testing.

Comment 13 Adam Williamson 2025-04-03 06:10:54 UTC
I already confirmed the fix in Rawhide.


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