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é
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
Please describe the desktop environment you are using and how it is set up
gnome+wayland aside of cinnamon
, 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
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).
Control: reassign -1 gnome-keyringExactly
On Fri, 11 Jul 2025 at 13:30:54 +0200, Daniel wrote:
[...]
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 wouldI did it in reportbug. I'ts Linux Asahi Trixie system
be able to set up an equivalent system themselves.
[...]
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.
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 /usr/libexec/gdm-wayland-session[285777]: dbus-daemon[285777]: [session uid=114 pid=285777 pidfd=5] Successfully activated service 'org.freedesktop.portal.Desktop'
On Thu, 10 Jul 2025 at 19:26:47 +0200, Daniel wrote:That's the logs I get when I try to connect to gnome-remote-desktop. On
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"?
As user I'm UID 1000 connected to the GUI and 114 is the one from gdm-wayland-sessionjuil. 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.)
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.
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]
Control: retitle -1 gnome-remote-desktop: blank screen afterIf you read carefully the logs I sended at the time I opened this bug,
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 aSure. On this computer I installed X11Vnc, Meshcentral and Rustdesk, all running well under X11. Rustdesk is running also under Wayland
screen and keyboard, and use it locally.
You also seem to be using gnome-remote-desktop in a less-common wayIf you tell it, I believe you. I didn't do anything more that the steps
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, pleaseTrying to use g-r-d finish with a blank screen on the client and those
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
If you check actual stand of bananas, a debian-installer is existing.
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
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 44:07:36 |
| Calls: | 12,111 |
| Calls today: | 2 |
| Files: | 15,008 |
| Messages: | 6,518,445 |