Werner

It seems like there is a mix-up between specs for the framework and for the OS. A lightweight desktop can run on 512MB, yes but probably not much fun, depending on applications. Won't recommend running a web browser. I'd probably get some existing cheap sbcs with similar specs and play with them to elaborate if the performance is sufficient.

IIRC until like half a year ago this also worked just fine. I assume then this check was introduced upstream which caused this - more or less cosmetical - error.

@JohnTheCoolingFan any clue?

moved. All boards using rk3588/s soc most likely work best with either vendor or edge kernel. Current has limited functionality since when this kernel became LTS only basic support was there. All further enhancements regarding hardware featureless were upstreamed later.

I think there are some directories in /etc which contain initramfs pre/post scripts. I don't have hw on hand to check right now but I believe there was some script starting with z50- filename that contained this check and there should be a 2nd one from Armbian that actually does what the upstream script refuses to do.

It would make more sense to send a PR to fix this so it is included in all upcoming images/releases.

https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card

I think this "unsupported version" thingy when doing initramfs update is just a cosmetical thing. The script comes from upstream and checks for version string included in upstream (directly from Raspberry to say) kernels. However I believe this has been worked around by our own bsp which is silently executed right after. Cannot tell for sure if that's the issue I remember it is since I don't have access to hw atm.

Have you tried to get into by keyboard/hdmi or serial console? If so you could track down why sshd refuses to start

Basically you as heads-up for upcoming kernel bump in this branch and everyone else for attention getting this merged (or not)

Never had an issue like that. However we also have mirrors in Asia or RU/UA where politics might interfere with bandwidth. So perhaps you hit one of those? Or you simply hit a mirror which was under heavy load at this time.

Sent a nudge.

The three holes could be access to a serial console if necessary. Ground Transmit Receive. If you want to try this, baudrate is most likely 115200 like all Allwinner SoCs.

I think the easiest would be to get/build an image with mesa-vpu extension enabled. Unfortunately there is no automated way to do the stuff this extension does while building, in a live system. In general there are two ways to get hw acceleration: panthor or proprietary mali blobs. Former is from my feels better for general desktop usage and latter for hw encoding/decoding. Both cannot co-exist, no idea why. Latter needs vendor kernel branch. This would give you a Noble Gnome desktop image with Panthor driver enabled: ./compile.sh BOARD=youyeetoo-r1-v3 BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED='browsers desktop_tools internet multimedia' DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base ENABLE_EXTENSIONS=mesa-vpu KERNEL_CONFIGURE=no RELEASE=noble Feel free to test: https://testing.armbian.de/Armbian-unofficial_25.11.0-trunk_Youyeetoo-r1-v3_noble_vendor_6.1.115_gnome_desktop.img.xz

edge = 6.16.y vendor = 6.1.115 Which kernel do you actually use? Also isn't panthor the backported gpu driver for rk35xx?

So besides Armbian a more recent image from khadas themselves also fails to boot?

Yes, this is quite common that feature xy has been implemented but the device trees don't get necessary updates. Often this is fixed by inheritance but sometimes adjustments on board level are necessary. Feel free to compare and send a PR to fix this until edge is bumped to 6.17 or even 6.18-rc1

This is severely outdated. Use this one instead: https://docs.armbian.com/Developer-Guide_Build-Preparation/

No need to emulate anything. Customization can be done while building. Easiest is via customize-image.sh script in userpatches: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

https://debug.armbian.de tl;dr: get an USB uart adapter and debug via serial console.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

moved

Probably never will until roll-over to next LTS version. We don't have people to maintain this.

mainline support for rk3588 is still incomplete. If you need vpu stuff mostly work you need to use vendor kernel which is based on rockchip bsp.

Should be resolved