Werner

There are for once some inconsistencies in terms of prefixes across various soc families and for the other configng isn't perfect (yet ). Feel free to share your issue at its repository: https://github.com/armbian/configng/

Try setting ZRAM_PERCENTAGE=50 where 50 would be half of available memory. Not sure if the builder picks this up. If it doesn't I'd go the customize-image.sh route and use this to modify the /etc/default/armbian-zram-config file just before assembly closure.

Hm if an image works but self-made won't either means something has been messed up which I doubt since it fails at uboot level. Or a change in the code broke it in the mean time. Also interesting that kernel building fails when RKNPU is a module rather than built-in. I guess that goes to poor implementation on Rockchip's side. Which exact pre-built image did you test that works well? This is quite old. We had a few version bumps in the mean time. More recent vendor kernels should already contain 0.9.8 What you could also try is to integrated the most recent patch series for mainline npu driver into edge kernel: https://patchwork.kernel.org/project/linux-rockchip/cover/20250519-6-10-rocket-v4-0-d6dff6b4c0ae@tomeuvizoso.net/

Yes, DB9 won't work. But if, as eselarm mentions, a proper chip is on board already a simple usb-a to usb-c or c-to-c cable should do. Check dmesg when connection to see what pops up.

These things can happen, yes. Sometimes old vendor-style uboot cannot process a modern mainline kernel and vice versa. Glad to hear it worked well this time.

No worries. Everyone here started small edge and vendor are Armbian terms for kernel branches just like current. You guessed correct, edge is bleeding edge and usually follows latest mainline kernel (6.14.y today). vendor is based on Rockchip BSP kernel which is 6.1.y at the moment. While a bit out of date most hw functions work here. current usually follows latest available LTS mainline kernel. As you're a beginner and most likely just want things to work I suggest to try a vendor kernel based image first.

Support for the rk3588 soc is quite rudimentary in this LTS kernel. Also most likely the opp nodes are missing just like most other hw features. I suggest to use either vendor or edge for now.

Cannot reproduce test@orangepi5-plus:~$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 test@orangepi5-plus:~$ cat /sys/devices/system/cpu/cpufreq/policy6/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 2016000 2208000 2256000 2304000 2352000 2400000

If a kernel package exists as artifact in oci cache it will be downloaded and used. Only if there is no artifact it will be built from scratch. After a new kernel version is released it may take a few days until oci catches up. However once locally built it will also be cached locally so it will be re-used if you start another build.

This is not uncommon. Very few boards have hdmi support at boot level since developing this feature is expensive and simply not worth since the console output is also available via debug serial console where adapters for those are dirt cheap. To get an idea what happens inside you have to grab these logs and provide them. https://debug.armbian.de

$ xz -t Armbian_25.2.1_Khadas-edge2_noble_vendor_6.1.99_gnome_desktop.oowow.img.xz $ echo $? 0 Check your download. Probably corrupted.

Some chips that support 1.5Mbaud and more: - FT232R - CH340G - CP2104

No logs - no issue. https://debug.armbian.de

I think it is this script: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-resize-filesystem There might be a switch or option to prevent resize, need to check documentation. Or do manually after expansion: https://unix.stackexchange.com/questions/656836/how-do-i-shrink-a-partition-right-after-shrinking-its-filesystem-with-resize2fs

Issues with the build framework, building Armbian to say, should be reported in the framework repository. https://github.com/armbian/build/ Make sure you include full logs. Use the curl command at the very and of the process or use SHARE_LOG=yes as build switch. Otherwise report might be rejected.

I guess the image with Gnome already built-in ships some extra package that makes this work or has some tweaks. Latter are obviously missing when installing from standard packages. You have to dive into the code where tweaks are applied and/or into package lists. https://github.com/armbian/build

Check this. Also full logs are missing.

Then you are using a fork of Armbian which we don't support here. Ask at the place where you got the image from.

Hi, its just a warning. Check the files mentioned and remove duplicate lines.

I don't think so. You can check in /boot/armbianEnv.txt if there is panthor overlay enabled. If so, disable it so you can use the proprietary mali blobs.

Only possible with starting over with a fresh image written to sd. Armbian does not come with some sort of overlayfs.

unsupported host os for build environment. Grant the user access to Docker or use a Noble host.

split into new topic. Use one of the curl commands mentioned in your logs go upload full logs to a paste server. These will contain more information to debug this.

I don't know where these shortcuts link to, but I assume they both link to the same executable script which is the next generation version. I am not aware that any current Armbian image still ships the old version. So at the bottom-line there is no difference.

The correct way to modify a kernel with patches is to use - ./compile kernel-patch BOARD=... BRANCH=... - review your patches and if you are satisfied move them to patch/ or the equivalent directory under userpatches/ - ./compile.sh kernel BOARD=... BRANCH=...