Werner

moved Like most cheap sbcs this board does not have any kind of standard like uefi, therefore generic images will not work. Check images from here: https://github.com/armbian/community/releases/ Board is community supported, therefore its status is unknown to the Armbian team. Images may work, maybe not.

I'd start reading the existing script on how the first login works behind the scenes: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstlogin

moved

Regressions happen all the time and not uncommon at all. Some get fixed upstream, some fix itself, some we have to find a fix. One of thousands of great ideas we'd love it implement but simply can't due to lack of (human) resources. This is why we highly appreciate community involvement.

I am not 100% certain but I think one of these images are installed (and upgraded) on my boards spi/nvme where I confirmed emmc working: http://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepi5-plus_noble_vendor_6.1.84_kde-neon-kisak_desktop.img.xz http://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepi5-plus_noble_vendor_6.1.99_kde-neon_desktop.img.xz

Hi, the manual way of enabling/disabling overlays is checking their availability in /boot/dtb/<family>/overlay and edit /boot/armbianEnv.txt. In your case it seems that a new overlays needs to be written. You can decompile an existing one that is similar using the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dtc utility. Once you created a new dts file you can use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbian-add-overlay <filename>.dts to compile and enable it. What exact values are necessary to achieve your particular case I don't know. I guess for that you have to dig through the datasheets of both your board and the SoC it is built around.

moved

I just put a random emmc module on my 5+ with vendor kernel and got detected as /dev/mmcblk0. So...cannot reproduce

I do.

vendor is just a name for one of our three main branches besides current and edge. The vendor name refers to the fact that this kernel is built from rockchip sdk sources (which is Linux 6.1.y but HEAVILY modified) with a bunch of our own patches on top. Though this branch is mainly for rk35xx devices. No idea how much work for rk32xx or rk33xx devices was made there.

Sometimes armbian-config is unreliable when adding overlays, therefore I suggested to check manually as well.

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

Check if there are pwm overlays available in /boot/dtb/allwinner/overlay. If so try enable via armbian-config or manually with overlays= in /boot/armbianEnv.txt

moved

Here and there things are sent upstream, but I am not aware of any defconfig changes that have been sent. So the answer is probably no. Also keep in mind that kernel configuration is one part only. Also other factors come into play like additional patches to the kernel regarding drivers or device tree.

You don't need the wireguard or wireguard-dkms package since all Armbian images ship the wireguard kernel module by default. All you need is the wireguard-tools package which you can install with the --no-install-recommends switch for apt which will prevent installing useless dependencies like kernels which wont work

Then go straight to dinner

Just for fun you could try an edge image for the board with btrfs. vendor is using a very old vendor-hacked uboot to make it work while edge follows mainline uboot which may have better btrfs support.

Ah. I guess at time of installation 6.6.y was current but since 6.12 is now available as new lts it has been moved to legacy. Therefore the name is different. Simplest to get matching packages is IMHO using the framework to create a set of packages and install them via dpkg.

Check how and why this kernel is installed: /boot/uInitrd-6.12.12+bpo-arm64-16k Seems like Debian backports kernel which WILL not work with your board. Make sure the vendor kernel is the only kernel installed. Write a fresh image to microsd and boot from it. chroot into your nvme and remove the wrong kernel. Make sure the symlinks to initramfs and kernel image are correct again. Should be sufficient.

next generation armbian-config still has some rough edges and constantly receiving fixes and improvements. If you can reproduce a special case where something doesnt work right, feel free to report at the github repo.

moved

code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } apt-cache search linux-headers If not there, use the build framework to create your own set of kernel packages including headers: https://docs.armbian.com/Developer-Guide_Build-Preparation/

Probably at April 1st 2026.

Could be. btrfs installation, especially on other devices, are not much tested. So breakage could be possible. Needs investigation. Should usually just work Yes, documentation is a constant problem. We don't have enough helping hands to keep everything in good shape. Keeping up with kernel development is already a challenge with hundreds of boards. Either the answer is right there or a mirror is out of sync which can happen from time to time. Feel free to fix apt source to a fixed mirror from this list: https://docs.armbian.com/Mirrors/