Armbian 25.11.2 for ROCK5 ITX released

[Bobbox]

Yesterday I was happy to see the new and fresh Armbian release for the Rock 5 ITX after about 1 year from the last update.

I also tried the Armbian Imager and the SD creation was very easy and smooth. 

I selected the recommended release based on Ubuntu 24.04 + Gnome desktop.

Unfortunately when the desktop was about to start, everything when black, stucked and zero interface. On the other hand, the OS is alive and I can connect remotely via SSH.

Did anyone have the same problem? Possible solution?

 

[EDIT]. 

sudo systemctl restart gdm and desktop pops up. Restarting the system, black again.

 

Edited yesterday at 10:56 PM by Bobbox

[Werner]

10 hours ago, Bobbox said:

fresh Armbian release

We have hundreds of releases and multiple per version per board  hard to tell from this which kernel or which exactly

 

10 hours ago, Bobbox said:

Ubuntu 24.04 + Gnome desktop.

i make a wild guess and the kernel you tried is 6.12.y which isn't good for desktop. try 6.1.115 (with mesa-vpu extension, not sure if there are pre-made ones) or  6.18, 6.19 mainline kernel.

[eselarm]

On https://www.armbian.com/radxa-rock-5-itx/ there are several things wrong. 1 is a desktop image has stated size of 260.1 MB, that is certainly wrong.

Then below there are several filenames Armbian_24.11.1_Rock-5-itx* in a sort of test report list. Note sure if that makes sense, more than 1 year old images. Also 6.1.75 vendor kernel had a few issues for me, although other RK3588 SBC.

 

1 year old versions of images might rely on older non-KMS HDMI init of a HDMI-monitor (done by older U-Boot), while newer U-Boot fails to init HDMI-monitor and also newer kernel and the current KMS might do things in a different way. I have that for my NanoPi-R6C and a certain older Medion HDMI monitor. Sometimes the KDE login screen just pops-up in 640x480. When login, the normal desktop goes correctly to 1080p60 (fullHD). A soft reboot also keeps it then in 1080p60, but the 2026.x versioned U-Boot does not manage to init the HDMI (maybe on-purpose, I have not looked in build config etc).

I have not tried restarting displaymanager via ssh as the 640x480 came eventually, but did it several times in the past (from 2019 till 2024 or so until not using it with HDMI anymore) for 2 RPI4, also different monitor and also with or without a HDMI switch in between. A method is to put a video= statement on the kernel commandline with the desired mode. Earlier via RPi firmware in config.txt.

 

I also looked into journal for the NanoPi-R6C issues of course and various failures w.r.t. HDMI after kernel 6.16.x or so, but all not fatal. So in the end it works and now properly working with kernel 6.18.2 edge kernel (Armbian Trixie KDE6). I went back to other bootloader (EDK2-UEFI v1.1) as that manages to init the HDMI monitor before kernel load and that is what I need, else always other computer needed (serial console) to select a different kernel or kernel config. I have never used video= statement with Armbian (yet), maybe I'll try just to know if and how it could work.

 

So @Bobbox, can you post what image it is (exact filename and sha256sum) ? 

Even better is also kernel version and U-Boot version (exact UUID build strings), but a better human readable version will also give some hints already. 

And maybe upload armbianmonitor log, but that is maybe for later.

[Bobbox]

Many thanks for your replies.

 

@Werner I can only say that I got the image via Armbian Imager, well designed for lazy people like me. This:

 

 

On the Armbian Rock5 ITX web page, There are two candidates: 1 ) This one, because it's the only image in the list with variant "Gnome":

 

or 2) this one, because it has the same size (1.4 GB), but doesn't say anything about the variant.

 

The two images above have two different sha hashes.

 

If it's true that isn't good for desktop (I agree with you because it doesn't work properly), I don't understand why it's tagged as "Recommended" on Armbian Imager.

Anyway, I deleted everything and started from scratch, using another image tagged as "Recommended" based on Debian 13 and CLI only.

 

 This one is less complicated and till  now works.

 

@eselarm 

I tried two different monitors: the first one is quite modern as it supports not only many resolutions, but also different frequencies and other stuff. The second one is very basic: it can support up to 1980p at 60hz. In both cases, I got the same behavior.

I also tried in the past EDK2-UEFI, but it didn't work very well on my Rock 5 ITX due to unexpected behaviors that I could not control in an effective way.

That being said, unfortunately I don't have the exact filename and sha256sum of the previous image because I changed the image.