Werner

These overlays are most likely not made to be used with mainline kernel. I suggest to retry with vendor kernel. Standard overlays for it have been pushed yesterday:https://github.com/armbian/linux-rockchip/pull/345/files

moved

moved, edited

excerpts are useless. Provide full logs with the curl command suggested.

Try oldarchive https://fi.mirror.armbian.de/oldarchive/helios4/archive/

https://github.com/armbian/build/pull/7902 Support is there AS IS. May work, may not. If latter, feel free to fix it and send PRs.

Try it calling by its correct name: armbian-config

Check archive.armbian.com

AFAIK armbianinstall expects an empty eMMC without partitions. This should be easily achievable by overwriting the first few sectors of it. Like dd if=/dev/zero of=/dev/mmcblkX bs=512 count=1 A reboot might be required to make the OS aware of the altered partition table. Then retry installing.

You already did by opening this topic.

Could you check if CONFIG_NLS_ISO8859_2 is enabled in your kernel config? The package is locales I think. That it is not installed tells me you are most likely using a Minimal/IoT image which comes with the absolute bare minimum to have a working system. Designed for advanced users knowing how to install such tools afterwards if needed.

None I am aware of. If you find something feel free to share. Regressions happen all the time.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

since you do not state what exactly you tried the recommendations will probably match those attempts but well, your time. Use armbian-config to enable/disable overlays.

This is how to properly provide logs. Cannot reproduce the issue. Build works just fine: https://paste.armbian.de/otajagegij https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.05.0-trunk_Rock-5b_noble_vendor_6.1.99_gnome_desktop.img.xz My best guess is there is some issue reaching the repository due to firewall/vpn.

Not via armbian-config. This is just a very simply way to do an initial setup. Here is the code that basically happens behind the scenes: https://github.com/armbian/configng/blob/main/tools/modules/software/module_nextcloud.sh So nothing fancy. just a docker run command. I personally prefer using docker-compose.yml instead of endless docker commands. Stuff is well-arranged and after adjusting like mounts down, up and ready to go. As mentioned above for customized installation please refer to the origin of the nextcloud container linuxserver.io. I am pretty sure they have examples for docker compose as well.

Yes. I disabled the patch you mentioned (patch/kernel/archive/sunxi-6.12/series.conf#L472) and built a bookworm minimal edge image with this and successfully booted an Orange Pi Zero 2 H616. I cannot answer this. I am using my Orange Pi One Plus (H6) headless only. Maybe anyone else can.

Please provide proper logs with the command suggested at the end of the process.

I tried this and works with zero2 https://paste.armbian.com/enipilazib

if you need working hdmi use vendor or edge kernels. current (which is 6.12.y) does not have all the necessary patches already since they were (and still are) under heavy development.

I think so, yes root@pihole-v2:~# dmesg|grep -i gpu [ 5.922915] panfrost 1800000.gpu: clock rate = 432000000 [ 5.922952] panfrost 1800000.gpu: bus_clock rate = 200000000 [ 5.923733] panfrost 1800000.gpu: mali-t720 id 0x720 major 0x1 minor 0x1 status 0x0 [ 5.923762] panfrost 1800000.gpu: features: 00000000,00000408, issues: 00000000,21054400 [ 5.923770] panfrost 1800000.gpu: Features: L2:0x07110206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002821 AS:0xf JS:0x7 [ 5.923779] panfrost 1800000.gpu: shader_present=0x3 l2_present=0x1 [ 5.931337] [drm] Initialized panfrost 1.2.0 for 1800000.gpu on minor 1

Seems indeed broken for H61* H6 is fine.

root@pihole-v2:~# uname -a Linux pihole-v2 6.12.16-edge-sunxi64 #1 SMP Fri Feb 21 13:01:47 UTC 2025 aarch64 GNU/Linux

We had the case on various boards over a couple of years that sometimes warm reboots fail. Since the reason is always individual, hard to tell by heart. Anyway I suggest to extract proper logs from debug uart console. If you don't know what I am talking about: https://debug.armbian.de

Sure thing: https://github.com/armbian/linux-rockchip