Blank screen/Bullseye/Raspbian

[Pauduan]

On a fresh install of Bulllseye I get blank screen after login. I've tried removing and reinstalling xrdp with 'apt install xrdp' and the longer command here: https://www.server-world.info/en/note?os=Debian_11&p=desktop&f=7

As before, I have no idea where to begin troubleshooting.

[matt335672]

Hi @Pauduan

Questions to start with:-

1. Are you trying to use the xorg backend or the xvnc backend? If the answer is "xorg" or "don't know" you'll need to sudo apt install xorgxrdp. If the answer is "xvnc", make sure that's selected on the login box.
2. Are you trying to log in to xrdp as the same user that is logged in to the graphical console. This won't work on Bullseye.
3. Can you provide contents of /var/log/xrdp.log and /var/log/xrdp-sesman.log after trying to log in?

Thanks.

[Pauduan]

Pretty sure running the xorg version. I didn't even know Windows client can work with VNC backend.

2. is definitely my issue, and might need to roll back to Buster as some of my installs don't have attached monitor but run Desktop environments purely for remote desktop duties. Didn't track this change else would never have upgraded. I can't function without the remote desktop capability.

I'll post the logs a bit later in the day. I think I removed the log by mistake while trying to clear it. It had over 1000 entries.

[MrFly72]

I have the same problem. Screen stays blank and after a long wait this error will appear:

[matt335672]

@Pauduan

1. If you're running xorg, you'll need xordxrdp installed. Also the log file $HOME/.xorgxrdp.$DISPLAY.log which is generated by this back end may contain useful information.
2. Just make sure you don't log in to two graphical desktops with the same user on the same box at the same time and you will be fine. Use cases like "ssh sessions and an rdp desktop for user zzz", or "ssh sessions and a console graphical desktop for user zzz" work OK. What won't work is "xrdp desktop and console graphical desktop for user zzz". For that, just use two separate users. Another alternative is to consider a non-systemd distribution, but that's going to be quite an upheaval.

[matt335672]

@MrFly72 - may or may not be the same problem. Many misconfigurations can present in the same way. Here's a list of past ones:-

https://github.com/neutrinolabs/xrdp/issues?q=is%3Aissue+%22blue+screen+%22+is%3Aclosed

Have a look in the above list, focussing on your own operating system and hardware. You'll probably find something which matches, but if you don't feel free to raise you own issue with a bit more detail in it.

[MrFly72]

Ok, I think I sorted out my problem with this:

1. raspi-consig and disable auto logon
   

2. Dont use VNC before using XRDP
   It seems to me that even loggoff from VNC will not then make a connect to XRDP successful (but I have not yet figured out in which scenarios this does not work anymore. Maybe when I once went onto the error?)

[matt335672]

They'll all be related to systemd --user.

Don't use the same user name for xrdp as your console login. Then you should be fine.

[matt335672]

@MrFly72 - you're hijacking an issue which is unrelated to your problem.

Feel free to raise a new issue and describe your problem in more detail, but please leave this issue for @Pauduan

[MrFly72]

Sorry, you are perfectly right with hijacking, was too much into "forum-mode".
Cleaned up my entries to help the Original Poster. Could be that he has to do the raspi-config stuff, as it seems that option B4 is the default in the install. I believe this helped me to get it work if I dont touch VNC ;-)

[Pauduan]

So here's my update...

I logged out from the Pi-400 after running a desktop update this am.

When I logged back into the system, everything seems to work correctly, I can see the mounted drives and have what looks like a working desktop. I can probably upgrade the 24x7 servers now, was waiting for this.

Matt, will I have to stay logged out of local desktop once upgraded to bullseye, and will my system services work correctly? I have piHole, LMS, Samba and Transmission. Not sure if you can answer, but slightly worried. When we log off Windows many applications no longer work.

I think the issue can be closed. Sorry haven't posted the logs but the fix ended up being pretty easy.

[matt335672]

Thanks for the update @Pauduan.

The simplest rule for Bullseye (and rPI OS based on Bullseye) is "don't use the same user on the graphical console as for xrdp sessions". If you stick with that you should be OK.

If you're using Raspberry PI OS, be careful with a restart and autologin, as (IIRC) the user pi will be logged in to the console automatically. If that's the case on your system, do one of the following:-

1. Set up a user other than pi for xrdp sessions, or
2. Disable autologin for pi using raspi-config.

If you go down route 1) you might want to consider using something like pam_access to restict particular users to particular login methods or locations. That's a more advanced topic however.

System services should be fine if they're being started by the system, and not by a console login.

As ever, the way to ensure a successful deployment is to test and test again. Two things to bear in mind:-

1. I may have misunderstood part of your description, or not even thought of something that's really obvious to you.
2. To you, I'm just a "Random Guy on the Internet". By all means consider my opinion, but it's your system.

I'll close this for now. Please come back to me if you've any questions.

[carbiderasp]

Thanks for the update @Pauduan.

The simplest rule for Bullseye (and rPI OS based on Bullseye) is "don't use the same user on the graphical console as for xrdp sessions". If you stick with that you should be OK.

If you're using Raspberry PI OS, be careful with a restart and autologin, as (IIRC) the user pi will be logged in to the console automatically. If that's the case on your system, do one of the following:-

1. Set up a user other than pi for xrdp sessions, or
2. Disable autologin for pi using raspi-config.

If you go down route 1) you might want to consider using something like pam_access to restict particular users to particular login methods or locations. That's a more advanced topic however.

System services should be fine if they're being started by the system, and not by a console login.

As ever, the way to ensure a successful deployment is to test and test again. Two things to bear in mind:-

1. I may have misunderstood part of your description, or not even thought of something that's really obvious to you.
2. To you, I'm just a "Random Guy on the Internet". By all means consider my opinion, but it's your system.

I'll close this for now. Please come back to me if you've any questions.

This resolved my issue.. thanks for the tip !!!

[Iksas]

The solution from #2060 (comment) doesn't require creating a new user:

Also, try this; can you edit the file /etc/X11/xrdp/xorg.conf, and find this line:-

Option "DRMDevice" "/dev/dri/renderD128"

Comment it out, and replace it with a line with no value:-

#Option "DRMDevice" "/dev/dri/renderD128"
Option "DRMDevice" ""

That should stop the driver trying to use the DRI device, and may prevent the hang.

[Iksas]

Note that the fix above can lead to performance issues.
This can be fixed by this workaround: #2060 (comment)

[cartpauj]

sudo deluser pi render worked for me.