Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.bugs.dist > #1252344 > unrolled thread
| Started by | Daniel <tech@tootai.net> |
|---|---|
| First post | 2025-07-10 19:50 +0200 |
| Last post | 2025-07-12 17:00 +0200 |
| Articles | 13 — 4 participants |
Back to article view | Back to linux.debian.bugs.dist
Bug#1109065: xdg-desktop-portal: Failed to create secret proxy for StartServiceByName Daniel <tech@tootai.net> - 2025-07-10 19:50 +0200
Bug#1109065: xdg-desktop-portal: Failed to create secret proxy for StartServiceByName Simon McVittie <smcv@debian.org> - 2025-07-10 20:10 +0200
Bug#1109065: xdg-desktop-portal: Failed to create secret proxy for StartServiceByName Daniel <tech@tootai.net> - 2025-07-11 13:50 +0200
Bug#1109065: xdg-desktop-portal: Failed to create secret proxy for StartServiceByName Simon McVittie <smcv@debian.org> - 2025-07-11 14:10 +0200
Bug#1109065: xdg-desktop-portal: Failed to create secret proxy for StartServiceByName Simon McVittie <smcv@debian.org> - 2025-07-11 16:20 +0200
Bug#1109065: xdg-desktop-portal: Failed to create secret proxy for StartServiceByName Daniel <tech@tootai.net> - 2025-07-11 16:30 +0200
Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 Simon McVittie <smcv@debian.org> - 2025-07-11 18:30 +0200
Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 Daniel <tech@tootai.net> - 2025-07-11 19:10 +0200
Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 Daniel <tech@tootai.net> - 2025-07-11 19:20 +0200
Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 NoisyCoil <noisycoil@disroot.org> - 2025-07-11 19:20 +0200
Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 Daniel <tech@tootai.net> - 2025-07-18 11:40 +0200
Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 NoisyCoil <noisycoil@disroot.org> - 2025-07-18 14:30 +0200
Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 NoisyCoil <noisycoil@tutanota.com> - 2025-07-12 17:00 +0200
| From | Daniel <tech@tootai.net> |
|---|---|
| Date | 2025-07-10 19:50 +0200 |
| Subject | Bug#1109065: xdg-desktop-portal: Failed to create secret proxy for StartServiceByName |
| Message-ID | <L73zb-gEDg-11@gated-at.bofh.it> |
Package: xdg-desktop-portal Version: 1.20.3+ds-1 Severity: important juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - [WTSReceiveChannelData]: unknown channelId 1006 ignored juil. 10 18:39:30 apple xdg-desktop-por[286207]: Failed to create secret proxy: Erreur lors de l’appel de StartServiceByName pour org.freedesktop.secrets : Le délai d’attente est dépassé juil. 10 18:39:30 apple xdg-desktop-por[286207]: No skeleton to export juil. 10 18:39:30 apple /usr/libexec/gdm-wayland-session[286294]: discover_other_daemon: 1 juil. 10 18:39:30 apple /usr/libexec/gdm-wayland-session[285777]: dbus-daemon[285777]: [session uid=114 pid=285777 pidfd=5] Successfully activated service 'org.freedesktop.portal.Desktop' juil. 10 18:39:34 apple gnome-remote-de[16112]: [DaemonSystem] Aborting handover, removing remote client with remote id /org/gnome/RemoteDesktop/Client/972001666 juil. 10 18:39:34 apple gnome-remote-desktop-daemon[16112]: [18:39:34:766] [16112:00003ef0] [ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_CB_CONNECTION_CANCELLED [0x00010409] juil. 10 18:39:35 apple systemd[1]: systemd-localed.service: Deactivated successfully. juil. 10 18:39:35 apple systemd[1]: systemd-hostnamed.service: Deactivated successfully. -- System Information: Debian Release: 13.0 APT prefers testing APT policy: (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 6.14.6-asahi (SMP w/8 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xdg-desktop-portal depends on: ii bubblewrap 0.11.0-2 ii dbus-user-session [default-dbus-session-bus] 1.16.2-2 ii fuse3 3.17.2-2 ii gstreamer1.0-plugins-base 1.26.2-1 ii gstreamer1.0-plugins-good 1.26.2-1 ii init-system-helpers 1.68 ii libc6 2.41-9 ii libfuse3-4 3.17.2-2 ii libgdk-pixbuf-2.0-0 2.42.12+dfsg-3 ii libglib2.0-0t64 2.84.3-1 ii libgstreamer-plugins-base1.0-0 1.26.2-1 ii libgstreamer1.0-0 1.26.2-2 ii libgudev-1.0-0 238-6 ii libjson-glib-1.0-0 1.10.6+ds-2 ii libpipewire-0.3-0t64 1.4.2-1 ii libsystemd0 257.7-1 Versions of packages xdg-desktop-portal recommends: ii librsvg2-common 2.60.0+dfsg-1 xdg-desktop-portal suggests no packages. -- no debconf information
[toc] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2025-07-10 20:10 +0200 |
| Message-ID | <L73Sx-gF0a-1@gated-at.bofh.it> |
| In reply to | #1252344 |
Control: tags -1 + moreinfo
On Thu, 10 Jul 2025 at 19:26:47 +0200, Daniel wrote:
>juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - [WTSReceiveChannelData]: unknown channelId 1006 ignored
>juil. 10 18:39:30 apple xdg-desktop-por[286207]: Failed to create secret proxy: Erreur lors de l’appel de StartServiceByName pour org.freedesktop.secrets : Le délai d’attente est dépassé
x-d-p tried to contact your implementation of the
org.freedesktop.secrets D-Bus interface (normally gnome-keyring or
KWallet), but didn't receive a reply to that request. x-d-p cannot solve
this: it will need to be fixed in either the implementation of
org.freedesktop.secrets, or some sort of desktop session infrastructure
around it.
What implementation of org.freedesktop.secrets did you expect it to be
using? This bug should be reassigned to whatever that implementation is.
Please describe the desktop environment you are using and how it is set
up, and please check the systemd Journal for messages regarding startup
of org.freedesktop.secrets, gnome-keyring or KWallet. They are likely to
appear in the period between 18:38:00 and 18:39:30 (perhaps earlier than
the part you quoted).
smcv
[toc] | [prev] | [next] | [standalone]
| From | Daniel <tech@tootai.net> |
|---|---|
| Date | 2025-07-11 13:50 +0200 |
| Message-ID | <L7kql-gPxO-13@gated-at.bofh.it> |
| In reply to | #1252346 |
Le 10/07/2025 à 19:58, Simon McVittie a écrit : > Control: tags -1 + moreinfo > > On Thu, 10 Jul 2025 at 19:26:47 +0200, Daniel wrote: >> juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: >> [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - >> [WTSReceiveChannelData]: unknown channelId 1006 ignored >> juil. 10 18:39:30 apple xdg-desktop-por[286207]: Failed to create >> secret proxy: Erreur lors de l’appel de StartServiceByName pour >> org.freedesktop.secrets : Le délai d’attente est dépassé > > x-d-p tried to contact your implementation of the > org.freedesktop.secrets D-Bus interface (normally gnome-keyring or > KWallet), but didn't receive a reply to that request. x-d-p cannot > solve this: it will need to be fixed in either the implementation of > org.freedesktop.secrets, or some sort of desktop session > infrastructure around it. > > What implementation of org.freedesktop.secrets did you expect it to be > using? This bug should be reassigned to whatever that implementation is. gnome-keyring dh@apple ~ $ ls -l /etc/xdg/autostart/gnome* -rw-r--r-- 1 root root 8877 20 mars 15:18 /etc/xdg/autostart/gnome-keyring-pkcs11.desktop -rw-r--r-- 1 root root 8341 20 mars 15:18 /etc/xdg/autostart/gnome-keyring-secrets.desktop -rw-r--r-- 1 root root 6825 20 mars 15:18 /etc/xdg/autostart/gnome-keyring-ssh.desktop > > Please describe the desktop environment you are using and how it is set up gnome+wayland aside of cinnamon apt install task-gnome-desktop > , and please check the systemd Journal for messages regarding startup > of org.freedesktop.secrets, gnome-keyring or KWallet. They are likely > to appear in the period between 18:38:00 and 18:39:30 (perhaps earlier > than the part you quoted). journalctl | grep gnome-keyring juil. 10 17:41:26 apple systemd[2924]: Listening on gnome-keyring-daemon.socket - GNOME Keyring daemon. juil. 10 17:41:26 apple systemd[2924]: Started gnome-keyring-daemon.service - GNOME Keyring daemon. juil. 10 17:41:26 apple gnome-keyring-daemon[2975]: GNOME_KEYRING_CONTROL=/run/user/1000/keyring juil. 10 17:41:26 apple gnome-keyring-daemon[2975]: The Secret Service was already initialized juil. 10 17:41:26 apple gnome-keyring-daemon[3115]: discover_other_daemon: 1 juil. 10 17:41:26 apple gnome-keyring-secrets.desktop[3115]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring juil. 10 17:41:26 apple gnome-keyring-d[2975]: The Secret Service was already initialized juil. 10 17:41:26 apple gnome-keyring-daemon[2975]: The PKCS#11 component was already initialized juil. 10 17:41:26 apple gnome-keyring-d[2975]: The PKCS#11 component was already initialized juil. 10 17:41:26 apple gnome-keyring-daemon[3117]: discover_other_daemon: 1 juil. 10 17:41:26 apple gnome-keyring-pkcs11.desktop[3117]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring juil. 10 17:41:26 apple gnome-keyring-daemon[3119]: discover_other_daemon: 1 juil. 10 17:41:26 apple gnome-keyring-ssh.desktop[3119]: discover_other_daemon: 1GNOME_KEYRING_CONTROL=/run/user/1000/keyring juil. 10 17:41:26 apple gnome-keyring-ssh.desktop[3119]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh juil. 10 17:46:53 apple systemd[31544]: Listening on gnome-keyring-daemon.socket - GNOME Keyring daemon. juil. 10 17:46:54 apple systemd[31544]: Started gnome-keyring-daemon.service - GNOME Keyring daemon. juil. 10 17:46:54 apple gnome-keyring-daemon[32163]: GNOME_KEYRING_CONTROL=/run/user/114/keyring juil. 10 17:46:54 apple gnome-keyring-daemon[32163]: The Secret Service was already initialized juil. 10 17:46:54 apple gnome-keyring-daemon[32162]: discover_other_daemon: 1 juil. 10 17:46:54 apple gnome-keyring-d[32163]: The Secret Service was already initialized juil. 10 17:51:54 apple gnome-keyring-daemon[32163]: The Secret Service was already initialized juil. 10 17:51:54 apple gnome-keyring-d[32163]: The Secret Service was already initialized juil. 10 17:51:54 apple gnome-keyring-daemon[57216]: discover_other_daemon: 1 juil. 10 18:39:05 apple gnome-keyring-daemon[32163]: The Secret Service was already initialized juil. 10 18:39:05 apple gnome-keyring-daemon[286294]: discover_other_daemon: 1 juil. 10 18:39:05 apple gnome-keyring-d[32163]: The Secret Service was already initialized journalctl |grep org.freedesktop.secrets When I run systemctl --user --all I don't see any org.freedesktop.secrets, seems normal as it should be activated by dbus Thanks for taking care to this problem -- Daniel
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2025-07-11 14:10 +0200 |
| Message-ID | <L7kJH-gPUH-1@gated-at.bofh.it> |
| In reply to | #1252417 |
Control: reassign -1 gnome-keyring
On Fri, 11 Jul 2025 at 13:30:54 +0200, Daniel wrote:
>Le 10/07/2025 à 19:58, Simon McVittie a écrit :
>>Control: tags -1 + moreinfo
>>
>>On Thu, 10 Jul 2025 at 19:26:47 +0200, Daniel wrote:
>>>juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]:
>>>[18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] -
>>>[WTSReceiveChannelData]: unknown channelId 1006 ignored
>>>juil. 10 18:39:30 apple xdg-desktop-por[286207]: Failed to create
>>>secret proxy: Erreur lors de l’appel de StartServiceByName pour
>>>org.freedesktop.secrets : Le délai d’attente est dépassé
>>
>>x-d-p tried to contact your implementation of the
>>org.freedesktop.secrets D-Bus interface (normally gnome-keyring or
>>KWallet), but didn't receive a reply to that request. x-d-p cannot
>>solve this: it will need to be fixed in either the implementation of
>>org.freedesktop.secrets, or some sort of desktop session
>>infrastructure around it.
>>
>>What implementation of org.freedesktop.secrets did you expect it to
>>be using? This bug should be reassigned to whatever that
>>implementation is.
>
>gnome-keyring
Reassigning to gnome-keyring for further investigation, then.
>>Please describe the desktop environment you are using and how it is set up
>
>gnome+wayland aside of cinnamon
What does "gnome+wayland aside of cinnamon" mean? Do you mean that you
have both GNOME and Cinnamon installed, and you are logging in to a
GNOME (Wayland) session?
Please describe the system in sufficient detail that a developer would
be able to set up an equivalent system themselves.
>>, and please check the systemd Journal for messages regarding
>>startup of org.freedesktop.secrets, gnome-keyring or KWallet. They
>>are likely to appear in the period between 18:38:00 and 18:39:30
>>(perhaps earlier than the part you quoted).
>
>journalctl | grep gnome-keyring
grep for gnome-keyring is not sufficient, there could be other relevant
messages related to it that do not contain the word "gnome-keyring".
We will need to see all messages from systemd and/or dbus-daemon that
relate to GNOME Keyring - those messages might not mention the word
"gnome-keyring", they might describe it as "GNOME Keyring" or "Secret
Service" or some other term. Please quote the whole section of the
Journal while the system is trying to start gnome-keyring for you. You
can censor messages that contain private information or are clearly
irrelevant, but please indicate where you have done so.
If you are not in the adm group, you will need to run journalctl as
root to be able to see everything.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2025-07-11 16:20 +0200 |
| Message-ID | <L7mLv-gRaK-7@gated-at.bofh.it> |
| In reply to | #1252344 |
On Thu, 10 Jul 2025 at 19:26:47 +0200, Daniel wrote:
>juil. 10 18:39:30 apple xdg-desktop-por[286207]: Failed to create secret proxy: Erreur lors de l’appel de StartServiceByName pour org.freedesktop.secrets : Le délai d’attente est dépassé
What I should have asked at the beginning is:
Is there a user-visible symptom that you are reporting, like some
program crashing or taking a long time to start, that is in some way
related to the warning you have quoted?
Or can your bug report be summarized as "there is a warning in the
system log, and I don't think there should be any warnings at all"?
>juil. 10 18:39:30 apple /usr/libexec/gdm-wayland-session[285777]: dbus-daemon[285777]: [session uid=114 pid=285777 pidfd=5] Successfully activated service 'org.freedesktop.portal.Desktop'
This is the special mini-session that is used for the gdm "greeter"
(login prompt), not part of a user's login session. It is normal that
this mini-session has limited functionality, and I would not expect
either gnome-keyring or xdg-desktop-portal to be usefully active in that
session.
(Perhaps that session should prevent these services from running at all.)
smcv
[toc] | [prev] | [next] | [standalone]
| From | Daniel <tech@tootai.net> |
|---|---|
| Date | 2025-07-11 16:30 +0200 |
| Message-ID | <L7mVb-gRf0-7@gated-at.bofh.it> |
| In reply to | #1252432 |
Le 11/07/2025 à 16:11, Simon McVittie a écrit : > On Thu, 10 Jul 2025 at 19:26:47 +0200, Daniel wrote: >> juil. 10 18:39:30 apple xdg-desktop-por[286207]: Failed to create >> secret proxy: Erreur lors de l’appel de StartServiceByName pour >> org.freedesktop.secrets : Le délai d’attente est dépassé > > What I should have asked at the beginning is: > > Is there a user-visible symptom that you are reporting, like some > program crashing or taking a long time to start, that is in some way > related to the warning you have quoted? > > Or can your bug report be summarized as "there is a warning in the > system log, and I don't think there should be any warnings at all"? That's the logs I get when I try to connect to gnome-remote-desktop. On the client I'm asked to enter user, password and domain, once done I get a blank screen and those logs appear on the server. Client software was gnome-connections or remmina an MBA M1 running as well Asahi Linux, same result with remmina from a 22.04 Ubuntu client. > >> juil. 10 18:39:30 apple /usr/libexec/gdm-wayland-session[285777]: >> dbus-daemon[285777]: [session uid=114 pid=285777 pidfd=5] >> Successfully activated service 'org.freedesktop.portal.Desktop' > > This is the special mini-session that is used for the gdm "greeter" > (login prompt), not part of a user's login session. It is normal that > this mini-session has limited functionality, and I would not expect > either gnome-keyring or xdg-desktop-portal to be usefully active in > that session. > > (Perhaps that session should prevent these services from running at all.) As user I'm UID 1000 connected to the GUI and 114 is the one from gdm-wayland-session
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2025-07-11 18:30 +0200 |
| Subject | Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 |
| Message-ID | <L7oNj-gSpF-3@gated-at.bofh.it> |
| In reply to | #1252436 |
Control: retitle -1 gnome-remote-desktop: blank screen after connecting to Mac Mini M2
Control: reassign -1 gnome-remote-desktop
Control: affects -1 + asahi-platform
Control: severity -1 normal
On Fri, 11 Jul 2025 at 16:22:49 +0200, Daniel wrote:
>Le 11/07/2025 à 16:11, Simon McVittie a écrit :
>>What I should have asked at the beginning is:
>>
>>Is there a user-visible symptom that you are reporting, like some
>>program crashing or taking a long time to start, that is in some way
>>related to the warning you have quoted?
>
>That's the logs I get when I try to connect to gnome-remote-desktop.
>On the client I'm asked to enter user, password and domain, once done
>I get a blank screen and those logs appear on the server.
OK, if the user-visible symptom is "I try to remote-control my computer
with gnome-remote-desktop and the result is a blank screen", please
start with that. Package maintainers cannot know that you are using
gnome-remote-desktop unless you tell us!
Please try upgrading to the remote desktop server to
gnome-remote-desktop 48.1-4 (currently in unstable but not in testing)
which is known to fix a bad interaction with newer versions of Mesa,
then reboot the remote desktop server and try connecting to it again.
If that is not successful, please describe the steps to reproduce the
problem you are seeing, without assuming that the package maintainers
know everything about your computer. You must have done some
configuration to make your computer offer remote desktop access -
please describe how you achieved that. The reason I ask for this is
that there is more than one way to use gnome-remote-desktop.
Remote-controlling a GNOME system with gnome-remote-desktop is not the
typical configuration: the typical configuration is to plug in a screen
and keyboard, and use it locally. You also seem to be using
gnome-remote-desktop in a less-common way where you are creating a
"headless" UI session, rather than sharing an existing GUI session.
If you are reporting a bug and you want it to be solvable, please always
start with:
- what you did (how you configured the system), and especially anything
that you did that is unusual, like:
- installing on Apple hardware using an unofficial version of Debian;
- using gnome-remote-desktop rather than a locally connected screen
and keyboard
- what you expected to happen
- what actually happened
The warning message logged by xdg-desktop-portal does not necessarily
have anything to do with you seeing a blank screen. It is potentially
useful information, but also potentially misleading, so we should start
by getting the full facts.
So let's start again: if you had provided that information at the
beginning, what would you have said?
Also please note that the "Bananas" port for Apple M1/M2 hardware is not
an official part of Debian, and relies on components that are not part
of Debian. I don't know how much of it is expected to work, and probably
some of it is known not to be ready at the moment. If you are not
already an experienced Debian user, I would recommend trying it on x86
hardware (like an old laptop) first.
Because gnome-remote-desktop interacts with video rendering, it is
dependent on the unofficial kernel and Mesa graphics stack provided by
"Bananas", which is not part of Debian.
Other log messages that could be particularly relevant include:
> juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - [WTSReceiveChannelData]: unknown channelId 1006 ignored
...
> juil. 10 18:39:34 apple gnome-remote-de[16112]: [DaemonSystem] Aborting handover, removing remote client with remote id /org/gnome/RemoteDesktop/Client/972001666
> juil. 10 18:39:34 apple gnome-remote-desktop-daemon[16112]: [18:39:34:766] [16112:00003ef0] [ERROR][com.freerdp.core.peer] - [rdp_set_error_info]: ERRINFO_CB_CONNECTION_CANCELLED [0x00010409]
(note for cc'd maintainers: there is a more full log in a previous
message on the bug)
smcv
[toc] | [prev] | [next] | [standalone]
| From | Daniel <tech@tootai.net> |
|---|---|
| Date | 2025-07-11 19:10 +0200 |
| Subject | Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 |
| Message-ID | <L7pq2-gSUc-13@gated-at.bofh.it> |
| In reply to | #1252445 |
Le 11/07/2025 à 17:56, Simon McVittie a écrit : > Control: retitle -1 gnome-remote-desktop: blank screen after > connecting to Mac Mini M2 > Control: reassign -1 gnome-remote-desktop > Control: affects -1 + asahi-platform > Control: severity -1 normal > > On Fri, 11 Jul 2025 at 16:22:49 +0200, Daniel wrote: >> Le 11/07/2025 à 16:11, Simon McVittie a écrit : >>> What I should have asked at the beginning is: >>> >>> Is there a user-visible symptom that you are reporting, like some >>> program crashing or taking a long time to start, that is in some way >>> related to the warning you have quoted? >> >> That's the logs I get when I try to connect to gnome-remote-desktop. >> On the client I'm asked to enter user, password and domain, once done >> I get a blank screen and those logs appear on the server. > > OK, if the user-visible symptom is "I try to remote-control my > computer with gnome-remote-desktop and the result is a blank screen", > please start with that. Package maintainers cannot know that you are > using gnome-remote-desktop unless you tell us! If you read carefully the logs I sended at the time I opened this bug, g-r-d is clearly mentioned as well as the linux kernel version indicating asahi > > Please try upgrading to the remote desktop server to > gnome-remote-desktop 48.1-4 (currently in unstable but not in testing) > which is known to fix a bad interaction with newer versions of Mesa, > then reboot the remote desktop server and try connecting to it again. This after trying remmina from Ubuntu 24.04. dh@apple ~ $ systemctl status gnome-remote-desktop ● gnome-remote-desktop.service - GNOME Remote Desktop Loaded: loaded (/usr/lib/systemd/system/gnome-remote-desktop.service; enabled; preset: enabled) Active: active (running) since Fri 2025-07-11 18:16:49 CEST; 7min ago Invocation: 80894c50e6d846c49cdab9a709139bf6 Main PID: 810 (gnome-remote-de) Tasks: 4 (limit: 4508) Memory: 40M (peak: 45.6M) CPU: 42ms CGroup: /system.slice/gnome-remote-desktop.service └─810 /usr/libexec/gnome-remote-desktop-daemon --system juil. 11 18:16:48 apple systemd[1]: Starting gnome-remote-desktop.service - GNOME Remote Desktop... juil. 11 18:16:49 apple gnome-remote-de[810]: Init TPM credentials failed because No TPM device found, using GKeyFile as fallback juil. 11 18:16:49 apple systemd[1]: Started gnome-remote-desktop.service - GNOME Remote Desktop. juil. 11 18:17:04 apple gnome-remote-de[810]: RDP server started juil. 11 18:17:45 apple gnome-remote-de[810]: [RDP] Client did not advertise support for the Graphics Pipeline, closing connection juil. 11 18:17:45 apple gnome-remote-de[810]: [RDP] Network or intentional disconnect, stopping session juil. 11 18:17:45 apple gnome-remote-desktop-daemon[810]: [18:17:45:387] [810:00001e20] [ERROR][com.freerdp.api] - [rdp_peer_handle_state_demand_active]: [CONNECTION_STATE_CAPABILITIES_EXCHANGE_DEMAND_ACTIVE] freerdp_peer::Capabilities() callback failed juil. 11 18:17:45 apple gnome-remote-desktop-daemon[810]: [18:17:45:387] [810:00001e20] [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1] Test trom MBA M1 under Trixie Asahi Linux ask me to enter credentials and then got a blankscreen. Attached you will fing logs from this second attempt. > > If that is not successful, please describe the steps to reproduce the > problem you are seeing, without assuming that the package maintainers > know everything about your computer. You must have done some > configuration to make your computer offer remote desktop access - > please describe how you achieved that. The reason I ask for this is > that there is more than one way to use gnome-remote-desktop. install xtask-cinnamon-desktop tried X11vnc wich was working Now knowing that trixie is Wayland only, I installed gnome install xtask-gnome-desktop From here nothing more that trying to connect from 2 others notebook in RDP knowing that Debian removed VNC from g-r-d I tried wayvnc+wayfire and could not get it work, always getting "wayvnc virtual pointer protocol not supported by compositor" > > Remote-controlling a GNOME system with gnome-remote-desktop is not the > typical configuration: the typical configuration is to plug in a > screen and keyboard, and use it locally. Sure. On this computer I installed X11Vnc, Meshcentral and Rustdesk, all running well under X11. Rustdesk is running also under Wayland > You also seem to be using gnome-remote-desktop in a less-common way > where you are creating a "headless" UI session, rather than sharing an > existing GUI session. If you tell it, I believe you. I didn't do anything more that the steps above as far as I remember. > > If you are reporting a bug and you want it to be solvable, please > always start with: > > - what you did (how you configured the system), and especially anything > that you did that is unusual, like: > - installing on Apple hardware using an unofficial version of Debian; > - using gnome-remote-desktop rather than a locally connected screen > and keyboard > - what you expected to happen > - what actually happened > > The warning message logged by xdg-desktop-portal does not necessarily > have anything to do with you seeing a blank screen. It is potentially > useful information, but also potentially misleading, so we should > start by getting the full facts. > > So let's start again: if you had provided that information at the > beginning, what would you have said? Trying to use g-r-d finish with a blank screen on the client and those are the logs I see (those sended on original message) > > Also please note that the "Bananas" port for Apple M1/M2 hardware is > not an official part of Debian, and relies on components that are not > part of Debian. I don't know how much of it is expected to work, and > probably some of it is known not to be ready at the moment. If you are > not already an experienced Debian user, I would recommend trying it on > x86 hardware (like an old laptop) first. I use Asahi/Linux Debian on an MBA M1 since 2 and a half year, was under bookworm at first, now Ttrixie. If you check actual stand of bananas, a debian-installer is existing. I'm connected to the team via #debian-bananas and doing some tests -I'm not the only one- for them. So no, will not change to x86-hardware. Anyway, I write this message and all others before with a Dell XPS 13 7390 Ubuntu 24.04 If you really fill that this case shouldn't be, feel free to close this bug, I can live with. Thanks for your help > > Because gnome-remote-desktop interacts with video rendering, it is > dependent on the unofficial kernel and Mesa graphics stack provided by > "Bananas", which is not part of Debian. > > Other log messages that could be particularly relevant include: > >> juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: >> [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - >> [WTSReceiveChannelData]: unknown channelId 1006 ignored > ... >> juil. 10 18:39:34 apple gnome-remote-de[16112]: [DaemonSystem] >> Aborting handover, removing remote client with remote id >> /org/gnome/RemoteDesktop/Client/972001666 >> juil. 10 18:39:34 apple gnome-remote-desktop-daemon[16112]: >> [18:39:34:766] [16112:00003ef0] [ERROR][com.freerdp.core.peer] - >> [rdp_set_error_info]: ERRINFO_CB_CONNECTION_CANCELLED [0x00010409] > > (note for cc'd maintainers: there is a more full log in a previous > message on the bug) > > smcv
[toc] | [prev] | [next] | [standalone]
| From | Daniel <tech@tootai.net> |
|---|---|
| Date | 2025-07-11 19:20 +0200 |
| Subject | Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 |
| Message-ID | <L7pzH-gSXH-11@gated-at.bofh.it> |
| In reply to | #1252447 |
To clarify, a monitor, keyboard and mouse are connected to the mini M2
[toc] | [prev] | [next] | [standalone]
| From | NoisyCoil <noisycoil@disroot.org> |
|---|---|
| Date | 2025-07-11 19:20 +0200 |
| Subject | Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 |
| Message-ID | <L7pzH-gSXH-9@gated-at.bofh.it> |
| In reply to | #1252447 |
Hi all. I'll get to this bug when I find some time to see if there's any indication that it affects our port and not parts of the stack which are in Debian. Until then please note that On 11/07/25 18:58, Daniel wrote: > If you check actual stand of bananas, a debian-installer is existing. no, we don't have a debian-installer. In the context of reporting bugs to Debian proper, e.g. by using the BTS, there is one and only debian-installer, and that does not support Apple Silicon. The Bananas Team has *an* installer, which is not the debian-installer, that uses custom packages, including the kernel, to install Debian on Apple machines. For more details see [1]. Will get back to this, Cheers (for now) [1] https://lists.debian.org/debian-devel/2025/06/msg00241.html
[toc] | [prev] | [next] | [standalone]
| From | Daniel <tech@tootai.net> |
|---|---|
| Date | 2025-07-18 11:40 +0200 |
| Subject | Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 |
| Message-ID | <L9PJn-Rqu-23@gated-at.bofh.it> |
| In reply to | #1252445 |
After a re-installation from scratch problem disappear, g-r-d is working. Seems that apt install task-gnome-desktop don't do the complete job. Le 11/07/2025 à 17:56, Simon McVittie a écrit : > Control: retitle -1 gnome-remote-desktop: blank screen after > connecting to Mac Mini M2 > Control: reassign -1 gnome-remote-desktop > Control: affects -1 + asahi-platform > Control: severity -1 normal > > On Fri, 11 Jul 2025 at 16:22:49 +0200, Daniel wrote: >> Le 11/07/2025 à 16:11, Simon McVittie a écrit : >>> What I should have asked at the beginning is: >>> >>> Is there a user-visible symptom that you are reporting, like some >>> program crashing or taking a long time to start, that is in some way >>> related to the warning you have quoted? >> >> That's the logs I get when I try to connect to gnome-remote-desktop. >> On the client I'm asked to enter user, password and domain, once done >> I get a blank screen and those logs appear on the server. > > OK, if the user-visible symptom is "I try to remote-control my > computer with gnome-remote-desktop and the result is a blank screen", > please start with that. Package maintainers cannot know that you are > using gnome-remote-desktop unless you tell us! > > Please try upgrading to the remote desktop server to > gnome-remote-desktop 48.1-4 (currently in unstable but not in testing) > which is known to fix a bad interaction with newer versions of Mesa, > then reboot the remote desktop server and try connecting to it again. > > If that is not successful, please describe the steps to reproduce the > problem you are seeing, without assuming that the package maintainers > know everything about your computer. You must have done some > configuration to make your computer offer remote desktop access - > please describe how you achieved that. The reason I ask for this is > that there is more than one way to use gnome-remote-desktop. > > Remote-controlling a GNOME system with gnome-remote-desktop is not the > typical configuration: the typical configuration is to plug in a > screen and keyboard, and use it locally. You also seem to be using > gnome-remote-desktop in a less-common way where you are creating a > "headless" UI session, rather than sharing an existing GUI session. > > If you are reporting a bug and you want it to be solvable, please > always start with: > > - what you did (how you configured the system), and especially anything > that you did that is unusual, like: > - installing on Apple hardware using an unofficial version of Debian; > - using gnome-remote-desktop rather than a locally connected screen > and keyboard > - what you expected to happen > - what actually happened > > The warning message logged by xdg-desktop-portal does not necessarily > have anything to do with you seeing a blank screen. It is potentially > useful information, but also potentially misleading, so we should > start by getting the full facts. > > So let's start again: if you had provided that information at the > beginning, what would you have said? > > Also please note that the "Bananas" port for Apple M1/M2 hardware is > not an official part of Debian, and relies on components that are not > part of Debian. I don't know how much of it is expected to work, and > probably some of it is known not to be ready at the moment. If you are > not already an experienced Debian user, I would recommend trying it on > x86 hardware (like an old laptop) first. > > Because gnome-remote-desktop interacts with video rendering, it is > dependent on the unofficial kernel and Mesa graphics stack provided by > "Bananas", which is not part of Debian. > > Other log messages that could be particularly relevant include: > >> juil. 10 18:39:18 apple gnome-remote-desktop-daemon[16112]: >> [18:39:18:988] [16112:000458c4] [WARN][com.freerdp.core.server] - >> [WTSReceiveChannelData]: unknown channelId 1006 ignored > ... >> juil. 10 18:39:34 apple gnome-remote-de[16112]: [DaemonSystem] >> Aborting handover, removing remote client with remote id >> /org/gnome/RemoteDesktop/Client/972001666 >> juil. 10 18:39:34 apple gnome-remote-desktop-daemon[16112]: >> [18:39:34:766] [16112:00003ef0] [ERROR][com.freerdp.core.peer] - >> [rdp_set_error_info]: ERRINFO_CB_CONNECTION_CANCELLED [0x00010409] > > (note for cc'd maintainers: there is a more full log in a previous > message on the bug) > > smcv
[toc] | [prev] | [next] | [standalone]
| From | NoisyCoil <noisycoil@disroot.org> |
|---|---|
| Date | 2025-07-18 14:30 +0200 |
| Subject | Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 |
| Message-ID | <L9SnU-T8X-9@gated-at.bofh.it> |
| In reply to | #1253135 |
Control: affects -1 - asahi-platform On 18/07/25 11:31, Daniel wrote: > After a re-installation from scratch problem disappear, g-r-d is working. > > Seems that apt install task-gnome-desktop don't do the complete job. Thanks for reporting back! It's possible that some required dependency is missing when installing gnome via task-gnome-desktop. P.S.: Simon, in the future feel free to tell our users to get in touch with us directly if you think a bug may only affect our port. I don't want to bother you with the details, but we have our own non-BTS bug trackers four our out-of-archive packages. asahi-platform only tracks packages in Debian proper, we're not using it as a catch-all pseudo-package. But of course, if you nonetheless need to catch our eye I understand it and will not be offended :-) Thanks for all the work!
[toc] | [prev] | [next] | [standalone]
| From | NoisyCoil <noisycoil@tutanota.com> |
|---|---|
| Date | 2025-07-12 17:00 +0200 |
| Subject | Bug#1109065: gnome-remote-desktop: blank screen after connecting to Mac Mini M2 |
| Message-ID | <L7JRM-h6hY-5@gated-at.bofh.it> |
| In reply to | #1252344 |
Package: gnome-remote-desktop Followup-For: Bug #1109065 X-Debbugs-Cc: noisycoil@tutanota.com, tech@tootai.net Hi all, I'm afraid I can't reproduce this bug on an M1 Mac Mini and on an M1 Pro MacBookPro. Using the same kernel and mesa drivers as the submitter, I successfully started gnome-remote-desktop (48.1-2) on both, connected from the other using both remmina and gnome-connections and controlled the desktop remotely. Both systems run GNOME 48. The only time I saw a blank screen was when the server was sleeping. This doesn't exclude something may be off with M2s, but I have no indication currently that M2s should have different behavior. I'll ask someone from the Team with an M2 to check this out. Cheers!
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.bugs.dist
csiph-web