Werner

You don't have to run on bare-metal. A proper VM will do too and is probably the better solution. Yes. Cross-compiling is used for everything that's not native. You're aware that the command in the docs is just an example, right?

Armbian does not come with some sort of admin console. Please elaborate. Try different patch cable. moved

where exactly does this error show up? while downloading with your browser? while writing to the sdcard? while booting? Please elaborate. debug boot issues: https://debug.armbian.de

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