I have tried to download at least 3 times this image: Armbian_25.8.1_Orangepi5-plus_noble_vendor_6.1.115_gnome_desktop.img.xz All sha256sum verified Ok. And wrote 5 times on 3 different SDCards, and this img does not boot on my OPI-5-Plus. No image on monitor, partition armbi_root not expanded, no green lights... Just unusable (for me). Other img's that boot are OK: Deb-xfce, noble-cinnamon, noble-neon... Someone got success with this img??? I'm looking for a distro that works well on OPI5-Plus, well configured, and that works with HDMI audio. The best for now is Noble-Cinnamon but failed to setup Menu button, and I cant find support until now to solve this issue. Thanks, Cury

I see on the mint website that there is nothing mentioned about Arm64, so consider mint as 'stay away' if you use Arm64. You have to do it yourself, so I would go for the most integrated solution. Mint is good for x86, because Ubuntu kernel an various proprietary HW, but that is all not the case for an OPi5+. I would take Debian as base and put Cinnamon on it. You can do it yourself by running 'sudo tasksel' or you put EDK2-UEFI v1.1 firmware on the OPi5+ and use https://dl.armbian.com/uefi-arm64/Trixie_current_cinnamon The missing start button might be complicated to fix, it can be due to some tiny error somewhere when you did setup the computer. Maybe a second try it will work, but maybe it is a real bug. I have only ran Cinnamon once for test for 15 minutes or so, it worked, but I use KDE normally, so have no clue where to look to fix it.

My post on Mint Forum was rejected: Somebody knows were Can I get support for Cinnamon on Armbian distros???

Hi all, I decided to revive my old rk3229 board with NAND. Could someone please tell me how to unbrick it?

Just an information about the `edge` kernel (6.18) when used on the cm3588-nas system. The rtc driver is not initialized on a `poweron`. After a poweron, you will see the following in the log. Nov 11 01:17:10 uhutest kernel: rtc-hym8563 6-0051: could not init device, -6 Nov 11 01:17:10 uhutest systemd[1]: System time advanced to built-in epoch: Tue 2025-11-11 01:17:09 CET If you have `fake-hwclock` running, you will see the following a moment later. fake-hwclock restores the time, but the service will not properly start, because of the rtc device error. Nov 11 01:17:12 uhutest fake-hwclock.sh[461]: Restoring saved system time Nov 20 13:22:43 uhutest fake-hwclock.sh[466]: Thu Nov 20 01:22:43 PM CET 2025 Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Cannot access the Hardware Clock via any known method. Nov 20 13:22:43 uhutest fake-hwclock.sh[468]: hwclock: Use the --verbose option to see the details of our search for an access method. Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Main process exited, code=exited, status=1/FAILURE Nov 20 13:22:43 uhutest systemd[1]: fake-hwclock.service: Failed with result 'exit-code'. Nov 20 13:22:43 uhutest systemd[1]: Failed to start Restore system time on boot and save it on shutdown. You would need to restart the fake-hwclock service, if you want that it saves time before the next restart. If you do a `restart` of the system, the rtc device will get properly initialized and time is good. Following is seen in the logs. Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: registered as rtc0 Nov 20 13:26:14 uhutest kernel: rtc-hym8563 6-0051: setting system clock to 2025-11-20T12:26:11 UTC (1763641571) Nov 20 13:26:16 uhutest fake-hwclock.sh[455]: Not restoring old system time I have seen the issue right now only with the 6-18-RC kernel. The following patch mentioned here works as a pure workaround. https://patchwork.kernel.org/project/linux-rockchip/patch/20220608161150.58919-2-linux@fw-web.de/ Lets see how the development of kernel 6.18 goes and if the final version will not have this issue.