For a few weeks I've been using the latest official release from May 26, 2025, running just fine from my NVME drive.

 

But then I turned it on and at the screen where you get the Amrbian grey/red logo in the middle of the screen and the spinning circle, it went no further. The spinning circle would either stop rotating or disappear after a minute or so.

 

I can SSH into the device.

 

But when I use remote desktop from a Windows PC, the full and functioning desktop is there. It's just not on my TV screen any more.

 

I've done the usual HDMI cable testing and powering off the TV completely, but no change.

 

The fact that the desktop is accessible remotely does indicate that it must be loading in some fashion.

 

Took a log here: https://paste.next.armbian.com/qococumoga

 

I noticed that the resolution had been changed from 1920x1080 to 1364x768 but when using remote desktop there is no way to change the resolution using the GUI.

 

Is there a terminal command that can do it?

 

5 hours ago, compent said:

Is there a terminal command that can do it?

try xrandr

I suggest you check the logs for clues what is going wrong.  syslog, .Xsession-errors, etc.

@WERNER

 

If I try to use xrandr through an SSH connection using putty I get the response 'Can't open display'

 

I can use it in terminal via remote connection and the basic command returns:

 

Screen 0: minimum 256 x 256, current 1364 x 768, maximum 16384 x 16384
rdp0 connected primary 1364x768+0+0 0mm x 0mm
   1364x768      50.00* 
 

Messing around with xrandr, there seems to be more than one way to skin a cat, if I try something like:

 

xrandr --output rdp0 --mode 1280x720

 

I get a response of 'cannot find mode 1280x720'

 

I experimented with all manner of normal resolutions that I have used before and even tried both the minimum stated by the plain xrandr command, 256x256 and 16384x16384 but get exactly the same response.

 

It would seem likely that 1364 x 768 is why my TV is not showing the desktop because I suspect the resolution is not supported.

 

But I feel between a rock and a hard place for something that seems become hard locked.

 

 

@laibsch

 

I poured through the log I posted above but much of it seem to be more rocket science, so hard to pick out something that logically points me in the right direction.

 

Yes, your logs show hundreds of errors, so it will be hard to pinpoint which one it is exactly.  Here's a few things I can suggest that might move you along.

• "sudo service restart lightdm" # see if X now comes up on your TV, assuming that lightm is what you are using
• "sudo nano /home/*/.xsession-errors" # check the errors listed in those log files, they are more specific
• Can you try to flash an (older) image to a microSD card, boot off it and see what the results are?
• @Efe Çetin is the maintainer of your board, maybe he has a comment?  Your board is in community-maintained status for armbian.  There are no guarantees.

Lightdm wasn't seen as being installed but I installed it just to see what happened but no change.

 

sudo nano /home/*/.xsession-errors gave the following information.

 

Xsession: X session started for test at Fri 20 Jun 07:04:16 BST 2025
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=>
dbus-update-activation-environment: setting DISPLAY=:10.0
localuser:test being added to access control list
dbus-update-activation-environment: setting QT_ACCESSIBILITY=1
dbus-update-activation-environment: setting USER=test
dbus-update-activation-environment: setting LANGUAGE=en_GB.UTF-8
dbus-update-activation-environment: setting XDG_SESSION_TYPE=x11
dbus-update-activation-environment: setting HOME=/home/test
dbus-update-activation-environment: setting XRDP_PULSE_SINK_SOCKET=xrdp_chansrv>
dbus-update-activation-environment: setting XRDP_PULSE_SOURCE_SOCKET=xrdp_chans>
dbus-update-activation-environment: setting DBUS_SESSION_BUS_ADDRESS=unix:path=>
dbus-update-activation-environment: setting PULSE_SCRIPT=/etc/xrdp/pulse/defaul>
dbus-update-activation-environment: setting LOGNAME=test
dbus-update-activation-environment: setting XDG_SESSION_CLASS=user
dbus-update-activation-environment: setting PATH=/usr/local/sbin:/usr/local/bin>
dbus-update-activation-environment: setting XRDP_SOCKET_PATH=/run/xrdp/sockdir
dbus-update-activation-environment: setting XDG_RUNTIME_DIR=/run/user/1000
dbus-update-activation-environment: setting DISPLAY=:10.0
dbus-update-activation-environment: setting LANG=en_GB.UTF-8

 

I flashed an older image and this latest one (that had been working fine for a few weeks) and both ran fine from Micro SD cards or USB.

 

I'm not sure what connection Efe Çetin has as it's an Orange Pi 5 board, so perhaps they have some form of official input to design.

 

I'd love to know what triggered the change.

 

And yes, like many things, no guarantees but if what happens can give pointers to preventing it happening to others in the future or recording potential solutions for those that might end up in the same position.

 

18 hours ago, compent said:

I flashed an older image and this latest one (that had been working fine for a few weeks) and both ran fine from Micro SD cards or USB.

 

The image from https://dl.armbian.com/orangepi5/Noble_vendor_gnome works well for me. It might be good to see some GDM logs as i am not sure where the problem arises from. 

I had a look in /var/log/gdm3/, which was originally denying me permission but after obtaining access, it is empty, so no GDM log, as least in this folder.

 

I also edited custom.conf to enable GDM logs but it had no effect.

 

I was curious to know why there is a GDM3 folder, rather then GDM.

Edited July 5, 20251 yr by compent
update

I've gone round in circles with this one and it seems that there might not be a solution, so will set it up again on the NVME drive.

 

Thanks for all the help offered.