Blank dark screen after update to 0.10 #3178
Comments
|
hmm, since you mention xrdp group: is it possible that you still use xrdp.service and xrdp-sesman.service from a debian package? if this is the "real" debian package, this resolves it, a bugreport should be created on bugs.debian.org |
|
xrdp/xorgxrdp had been installed from apt. I tried setting SessionSockdirGroup=xrdp under the [Security] section in sesman.ini - as you suggested - but this haven't resolved the problem. ( with runtime_xxxx not in xrdp.ini) This is the result of systemctl status xrdp after unsuccessful login remote login: and this is after systemctl restart xrdp: Interestingly, after xrdp restart , systemctl status xrdp-sesman replies with IS this expected? What else can be tried? |
|
It looks like debian only uses a single (probably autogenerated service from /etc/init.d/xrdp) xrdp.service, so the absence of xrdp-sesman is probably expected here. I think you got a different result this time (not a black screen but a disconnect), since now there is after lib_mod_connect: connecting via UNIX socket (that previously probably failed) now it seems that the x session immediately terminates. Can you check ~/.xsession-errors, maybe there is something useful |
|
there is no ~/.xsession-errors... the last lines from the most recent /var/log/xrdp.log: What is the potential source of "error in trans_connect chan" ? |
|
Do these warnings have any significance?
[2024-07-28T13:56:13.412-0400] [WARN ] client requested gfx protocol with
insufficient color depth
[2024-07-28T13:56:13.413-0400] [WARN ] Physical desktop dimensions (0x0)
are invalid
[2024-07-28T13:56:13.413-0400] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER
type 0xc006 is unknown (ignored)
[2024-07-28T13:56:13.413-0400] [WARN ] Received [MS-RDPBCGR] TS_UD_HEADER
type 0xc00a is unknown (ignored)
[2024-07-28T13:56:13.682-0400] [INFO ] Loading keymap file
/etc/xrdp/km-00000409.ini
[2024-07-28T13:56:13.682-0400] [WARN ] local keymap file for 0x00000409
found and doesn't match built in keymap, using local keymap file
[2024-07-28T13:56:13.682-0400] [WARN ] No information is available to
determine login screen DPI
[2024-07-28T13:56:13.682-0400] [WARN ] No DPI value is available to find
login font
…On Sun, Jul 28, 2024 at 3:32 PM akarl10 ***@***.***> wrote:
It looks like debian only uses a single (probably autogenerated service
from /etc/init.d/xrdp) xrdp.service, so the absence of xrdp-sesman is
probably expected here.
I think you got a different result this time (not a black screen but a
disconnect), since now there is
lib_mod_log_peer: xrdp_pid=1276 connected to Xorg_pid=1285 Xorg_uid=1000 Xorg_gid=1....
after lib_mod_connect: connecting via UNIX socket (that previously
probably failed)
now it seems that the x session immediately terminates. Can you check
~/.xsession-errors, maybe there is something useful
—
Reply to this email directly, view it on GitHub
<#3178 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH4KKZQD7STHMMTCLVZ5YK3ZOTQGXAVCNFSM6AAAAABLO7IWIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJUGUYDGMRXGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
client requested gfx protocol with insufficient color depth might be a problem (don't know how xrdp 0.10 handles this exactly, but if gfx is enabled 32bit colour depth must be set (what client are you using? if mstsc, there is a dropdown list where you can select different colour depths) |
|
I did try setting color depth to 32bit in mstsc, that didn't work.
…On Sun, Jul 28, 2024 at 9:20 PM akarl10 ***@***.***> wrote:
client requested gfx protocol with insufficient color depth might be a
problem (don't know how xrdp 0.10 handles this exactly, but if gfx is
enabled 32bit colour depth must be set (what client are you using? if
mstsc, there is a dropdown list where you can select different colour
depths)
—
Reply to this email directly, view it on GitHub
<#3178 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AH4KKZXWZIEZ3D2CJV5PNR3ZOUZADAVCNFSM6AAAAABLO7IWIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJUGYYDEMRZGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
After changing in /etc/X11/xrdp/xorg.conf
Screen/DefaultDepth to 32 (from 24) and in Screen/Display/Depth 32 (from
24), the 'insufficient color depth" warning is gone,
but "Physical desktop dimensions (0x0) are invalid" is there.
Interestingly, in ..xorg.conf, there is no "1920x1200" mode (neither under
Monitor nor under Screen/Display.....
and I have always connected with the "Full screen" option in mstsc..
|
|
I now (after steps above) see this in the log:
[ 98.115] rdpProbe: found DRMDevice xorg.conf value [/dev/dri/renderD128]
[ 98.115] rdpProbe: found DRI3 xorg.conf value [1]
[ 98.115] (II) XRDPDEV(0): using default device
[ 98.115] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card
support
[ 98.115] rdpPreInit:
[ 98.115] rdpPreInit: /dev/dri/renderD128 open ok, fd 12
[ 98.115] (**) XRDPDEV(0): Depth 32, (--) framebuffer bpp 32
[ 98.115] (EE) XRDPDEV(0): Weight given (000) is inconsistent with the
depth (32)
[ 98.115] rdpPreInit: xf86SetWeight failed
[ 98.115] rdpFreeScreen:
[ 98.115] (II) UnloadModule: "XRDPDEV"
[ 98.115] (EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
[ 98.115] (EE) no screens found(EE)
And now "X server cannot be started":
[2024-07-29T09:56:18.486-0400] [INFO ] starting xrdp-sesexec with pid 1259
[2024-07-29T09:56:18.501-0400] [INFO ] TerminalServerUsers group tsusers doesn't exist. Access granted for zheka
[2024-07-29T09:56:18.501-0400] [INFO ] Access permitted for user: zheka
[2024-07-29T09:56:18.502-0400] [DEBUG] Closed socket 9 (AF_UNIX)
[2024-07-29T09:56:18.502-0400] [INFO ] Received sys login status for zheka : logged in
[2024-07-29T09:56:18.502-0400] [INFO ] Received request from xrdp to create a session for user zheka
[2024-07-29T09:56:18.502-0400] [DEBUG] session_list_get_bydata: search policy=UB type=Xorg U=1000 B=24 D=(1920x1200) I=
[2024-07-29T09:56:18.502-0400] [DEBUG] session_list_get_bydata: No matches found
[2024-07-29T09:56:18.502-0400] [DEBUG] Did not find a running X server at /tmp/.X11-unix/X10
[2024-07-29T09:56:18.502-0400] [DEBUG] Did not find a running X server at /tmp/.X10-lock
[2024-07-29T09:56:18.502-0400] [DEBUG] Closed socket 15 ([::]:5910)
[2024-07-29T09:56:18.502-0400] [DEBUG] Did not find a running X server at 5910
[2024-07-29T09:56:18.502-0400] [DEBUG] Closed socket 15 ([::]:6010)
[2024-07-29T09:56:18.502-0400] [DEBUG] Did not find a running X server at 6010
[2024-07-29T09:56:18.502-0400] [DEBUG] Closed socket 15 ([::]:6210)
[2024-07-29T09:56:18.503-0400] [DEBUG] Closed socket 13 (AF_UNIX)
[2024-07-29T09:56:18.699-0400] [DEBUG] Waiting for X server to start on display :10
[2024-07-29T09:56:18.699-0400] [DEBUG] Calling exec (excutable: /usr/lib/x86_64-linux-gnu/xrdp/waitforx, arguments: /usr/lib/x86_64-linux-gnu/xrdp/waitforx -d :10)
[2024-07-29T09:56:18.700-0400] [DEBUG] waitforx: Opening display :10. Attempt 1 of 10
[2024-07-29T09:56:18.701-0400] [INFO ] Starting X server on display 10: /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log
[2024-07-29T09:56:18.701-0400] [DEBUG] Calling exec (excutable: /usr/lib/xorg/Xorg, arguments: /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log)
[2024-07-29T09:56:19.701-0400] [DEBUG] waitforx: Opening display :10. Attempt 2 of 10
[2024-07-29T09:56:20.702-0400] [DEBUG] waitforx: Opening display :10. Attempt 3 of 10
[2024-07-29T09:56:21.702-0400] [DEBUG] waitforx: Opening display :10. Attempt 4 of 10
[2024-07-29T09:56:22.703-0400] [DEBUG] waitforx: Opening display :10. Attempt 5 of 10
[2024-07-29T09:56:23.703-0400] [DEBUG] waitforx: Opening display :10. Attempt 6 of 10
[2024-07-29T09:56:24.703-0400] [DEBUG] waitforx: Opening display :10. Attempt 7 of 10
[2024-07-29T09:56:25.704-0400] [DEBUG] waitforx: Opening display :10. Attempt 8 of 10
[2024-07-29T09:56:26.704-0400] [DEBUG] waitforx: Opening display :10. Attempt 9 of 10
[2024-07-29T09:56:27.704-0400] [DEBUG] waitforx: Opening display :10. Attempt 10 of 10
[2024-07-29T09:56:28.704-0400] [ERROR] waitforx: Unable to open display :10
[2024-07-29T09:56:28.704-0400] [DEBUG] waiting for pid 1280 to exit
[2024-07-29T09:56:28.705-0400] [ERROR] X server failed to start
|
|
I'd suggest for the time being putting any defaults in https://github.com/neutrinolabs/xorgxrdp/blob/devel/xrdpdev/xorg.conf BTW this particular warning :- was addressed by d23d147. If the client asks for GFX but not 32bpp, we simply don't enable GFX when we reply to the client. So you should get a working login despite the warning. If you could get back to where you were, this would be useful. We don't have complete logs from the earlier time, but this looks to me like the session is terminating early. Apologies in advance for the bold, and also apologies if you've checked this, but a common cause of this is being logged in on the local console, and trying to log in over xrdp with the same user. Please make sure you're not logged in on the console as user zheka when using xrdp. This is covered in the FAQ. If that's not it, please post |
|
All tests are done straight after a reboot, and this is a remote server to which I don't have physical access. Putting back xorg.conf defaults, X server IS starting, but the screen is still black and now I shortly get kicked out of the rdp session. and here is /etc/xrdp/startwm.sh: which of the config file is /etc/X11/Xsession would you like to have a look at? Using lightdm with xfce; all worked fine prior to xrdp and xorg update to 0.10 |
|
Fine @Zheka17 - I had to ask about the console. It comes up a lot. The sesman log tells us the X server is starting, and is ready after about 2 seconds. At that point, This points to either the script, or something it's calling. Try this to get a log of what the script is doing:- |
|
Upon looking at what the /etc/xrdp/startwm.sh is doing, i found that it stopped at "..xxx...file not found" and didn't proceed to (This is somewhat strange, as on an identically setup machine - though VM and with prior version of xrdp) - a similar error did not stop the startwm.sh from proceeding and successfully launching an X session). Anyways, once i recreated the missing file, the startwm did proceed to create an X session and I finally saw the graphical desktop!! Several observations:
Does this hamper any functionality of xrdp/system in general? Other Qs:
Thank you. |
|
some comments to the observations:
other Questions:
|
|
Thanks a lot for your answers! On Q 1: |
|
Glad you got it working @Zheka17 To add some context to @akarl10's good comments:-
and:-
|
|
Thank you @matt335672 for those extra bits! I am accessing remote servers (one - a VM, another - physical w integrated gpu) running some ml/productivity applications; none using 3D graphics. So, I've always used 16-bit color depth to reduce overhead -both on a remote machine and on Win client. |
|
32-bit will use GFX which should give you the best performance. 24-bit will fall back to an older way of doing things. I think other settings will result in 24-bit being negotiated. |
|
I'm here because of this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076815 |
|
@alexmyczko - this is a Debian (downstream) packaging issue. They are the people who will need to fix this for you. We're not going to make their job harder by stepping on their toes. |
|
@matt335672 i'm part of that team myself :) i was just asking for help or hints, as i'm tapping in the dark about it... |
|
@alexmyczko here is what I did in my ppa and version 0.10: if systemctl --quiet --user is-active graphical-session.target; then
xmessage -button Logout:1,Terminate\ running\ graphical\ session:2 "Only a single graphical session is allowed.
If you terminate the current graphical session all unsaved data in that session will be lost"
action=$?
if [ "$action" -eq 2 ]; then
systemctl --user stop graphical-session.target
sleep 1
else
exit 0
fi
fimade a terrible .postinst upgrade script that tries to add Looking at the debian bugreport what I find odd is that the |
|
@alexmyczko - really sorry. I'd completely missed that. We've occasionally liaised with @Natureshadow in the past relating to Debian-issues. If you'd like to tell me which one of you is best placed for us to communicate with, that would be a great help. I know you're all busy people, and you won't want to keep up to speed with everything that is going on here, all of the time. I'll add to @akarl10's comments. I don't know how much of the history of this package you are aware of, but I'll add what I know. There's also a lot of stuff about permissions which has changed. I totally agree about the missing As for permissions... Up until now, xrdp has been delivered by us with We've been working to move the good work done by Debian into the base product, so that other distros which do minimal packaging can benefit from what is, frankly, an essential security feature in 2024. This code finally landed in v0.10.1. Details are here:- https://github.com/neutrinolabs/xrdp/wiki/Running-the-xrdp-process-as-non-root There's a significant difference between what we do and the original Debian patches. Rather than running I see you're running v0.10.0. Although we haven't delivered the complete code for running xrdp as non-root in that version, we have delivered code which moves sesman from communicating over TCP to a UNIX domain socket. Consequently, if you patch xrdp to run as non-root, you will need to set If you've got any questions on the above, please raise them on the Discussions forum and I'll do my best to answer them. |
xrdp version
0.10.0
Detailed xrdp version, build options
Operating system & version
Debian 12, 6.10.1
Installation method
dnf / apt / zypper / pkg / etc
Which backend do you use?
xorgxrdp
What desktop environment do you use?
xfce
Environment xrdp running on
IGP, with amd x7950x3d cpu
What's your client?
msdtc, from Win 7
Area(s) with issue?
Authentication, Session manager (sesman), Other
Steps to reproduce
Issue appeared upon upgrade to 0.10.x0-2 xrdp/ xorgxrdp from 0.9.24-5/ 0.19.9-1
✔️ Expected Behavior
No response
❌ Actual Behavior
rdp connection is established, but:
Downgrading back to 0.9.24-5 (and xorgxrdp 1:0.9.19-1) didn't resolve the issue.
Anything else?
/var/log/xrdp.log:
/var/log/xrdp-sesman.log:
.xorgxrdp.10.log:
xrdp.ini :
sesman.ini:
sudo groups xrdp:
xrdp : xrdp ssl-cert
All worked fine before the update.
The text was updated successfully, but these errors were encountered: