All Activity

Totally undestand, just I probably know less then you about those things ... mpv is the king, I know that. But most people don't and they will keep asking why VLC, Totem or whatever player doesn't support accelerated video. Every SoC family has its own tricks to get this working ...

@Igor, @robertoj: Update: Friendlyelec image uses its own libav* libraries, not the Debian ones: # ls -1 /usr/local/lib/aarch64-linux-gnu libavcodec.so libavcodec.so.61 libavcodec.so.61.19.101 libavfilter.so libavfilter.so.10 libavfilter.so.10.4.100 libavutil.so libavutil.so.59 libavutil.so.59.39.100 It also has the following packages, not in Armbian: # dpkg -l *mpp* ... ii librockchip-mpp-dev 20260226-2 arm64 Media Process Platform ii librockchip-mpp1 20260226-2 arm64 Media Process Platform ii libv4l-rkmpp 1.8.0-1 arm64 A rockchip-mpp V4L2 wrapper plugin for chromium video dec and enc ii rockchip-mpp-demos 20260226-2 arm64 Media Process Platform Demos I copied the relevant files from Friendlyelec system to Armbian system (both are Trixie), ran ldconfig, and ran `strace mpv my.mp4` on both systems. Comparison of strace output revealed that certain apparently required device files under /dev/dma_heap are missing on Armbian, plus incorrect permissions on /dev/mpp_service: On Friendlyelec: # ls -l /dev/dma_heap total 0 crw-rw-r-- 1 root video 251, 4 Jul 20 06:48 cma crw-rw-r-- 1 root video 251, 5 Jul 20 06:48 cma-uncached crw-rw-r-- 1 root video 251, 0 Jul 20 06:48 system crw-rw-r-- 1 root video 251, 1 Jul 20 06:48 system-dma32 crw-rw-r-- 1 root video 251, 2 Jul 20 06:48 system-uncached crw-rw-r-- 1 root video 251, 3 Jul 20 06:48 system-uncached-dma32 # ls -l /dev/mpp_service crw-rw-rw- 1 root video 241, 0 Jul 20 06:48 /dev/mpp_service On Armbian: # ls -l /dev/dma_heap total 0 crw------- 1 root root 251, 0 Jul 19 19:41 system crw------- 1 root root 251, 1 Jul 19 19:41 system-uncached # ls -l /dev/mpp_service crw------- 1 root root 241, 0 Jul 20 06:48 /dev/mpp_service Removing the cma= arg from the kernel cmdline gave me /dev/dma_heap/cma, and I manually fixed up the permissions, but still no video accel for mpv. Something else is apparently required, perhaps the remaining missing device files under /dev/dma_heap.

@Igor: Update: I have HW accel with sound for chromium with my minimal trixie/vendor image, which I installed xfce on top of. This is the image from armbian.org as opposed to the latest release from Github, which is what I tested in my review of Gnome images above. However Chromium doesn’t support AC3 audio, which means it can’t play the majority of the files in my video collection with sound: https://issues.chromium.org/issues/41253735 And there's a good deal besides that Chromium cannot do. This is why Chromium is not enough and we need mpv/ffmpeg/libav* support. mpv plays literally every media file you can throw at it.

@BipBip1981In your first post you wrote that 6.18.10 works, while 6.18.35 and 6.18.37 don't. Did you test both the new Armbian overlay and the old DTB with 6.18.35, or only one of them? I'm trying to find out whether the DTB makes any difference on 6.18.35.

512M seems too low: [ 70.791346] containerd: page allocation failure: order:1, mode:0x40820(GFP_ATOMIC|__GFP_COMP), nodemask=(null),cpuset=containerd.service,mems_allowed=0 [ 70.791404] CPU: 1 UID: 0 PID: 1727 Comm: containerd Not tainted 6.18.10-current-meson64 #1 PREEMPT [ 70.791410] Hardware name: linux,dummy-virt (DT) [ 70.791414] Call trace: [ 70.791417] show_stack+0x20/0x38 (C) [ 70.791427] dump_stack_lvl+0x74/0x90 [ 70.791436] dump_stack+0x18/0x28 [ 70.791441] warn_alloc+0x134/0x1c0 [ 70.791449] __alloc_frozen_pages_noprof+0x780/0xe70 [ 70.791457] alloc_pages_mpol+0xbc/0x1c8 [ 70.791463] alloc_frozen_pages_noprof+0x50/0xd0 [ 70.791468] new_slab+0x2ec/0x3a8 [ 70.791474] ___slab_alloc+0x654/0xbb8 [ 70.791480] __slab_alloc.isra.0+0x50/0xa8 [ 70.791485] __kmalloc_noprof+0x410/0x638 [ 70.791491] virtqueue_add_sgs+0x2e4/0x6d0 [ 70.791499] virtblk_add_req+0xb8/0x130 [ 70.791507] virtio_queue_rq+0x80/0x208 [ 70.791513] blk_mq_dispatch_rq_list+0x104/0x6f0 [ 70.791521] __blk_mq_sched_dispatch_requests+0x45c/0x570 [ 70.791527] blk_mq_sched_dispatch_requests+0x38/0x88 [ 70.791532] blk_mq_run_hw_queue+0x25c/0x2d0 [ 70.791538] blk_mq_dispatch_list+0x110/0x420 [ 70.791545] blk_mq_flush_plug_list+0x5c/0x190 [ 70.791551] __blk_flush_plug+0xf0/0x158 [ 70.791559] blk_finish_plug+0x40/0x60 [ 70.791565] read_pages+0x130/0x2c8 [ 70.791573] page_cache_ra_unbounded+0x1e4/0x300 [ 70.791580] page_cache_ra_order+0x41c/0x488 [ 70.791586] filemap_fault+0x5d8/0xb68 [ 70.791592] __do_fault+0x44/0x240 [ 70.791599] __handle_mm_fault+0x9e4/0x18a0 [ 70.791604] handle_mm_fault+0x194/0x2e0 [ 70.791609] do_page_fault+0x110/0x6f8 [ 70.791616] do_translation_fault+0x54/0x80 [ 70.791623] do_mem_abort+0x4c/0xa8 [ 70.791630] el0_ia+0x50/0xd0 [ 70.791637] el0t_64_sync_handler+0xe0/0xe8 [ 70.791644] el0t_64_sync+0x198/0x1a0 [ 70.791650] Mem-Info: [ 70.791832] active_anon:11944 inactive_anon:39978 isolated_anon:0 [ 70.791832] active_file:11107 inactive_file:13422 isolated_file:0 [ 70.791832] unevictable:0 dirty:0 writeback:8 [ 70.791832] slab_reclaimable:5622 slab_unreclaimable:10672 [ 70.791832] mapped:6999 shmem:423 pagetables:2117 [ 70.791832] sec_pagetables:0 bounce:0 [ 70.791832] kernel_misc_reclaimable:0 [ 70.791832] free:912 free_pcp:426 free_cma:29 [ 70.791874] Node 0 active_anon:47776kB inactive_anon:159912kB active_file:44428kB inactive_file:53688kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:27996kB dirty:0kB writeback:32kB shmem:1692kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB kernel_stack:6016kB pagetables:8468kB sec_pagetables:0kB all_unreclaimable? no Balloon:0kB [ 70.791907] Node 0 DMA free:3648kB boost:4096kB min:6768kB low:7436kB high:8104kB reserved_highatomic:2048KB free_highatomic:56KB active_anon:47776kB inactive_anon:159912kB active_file:44428kB inactive_file:53460kB unevictable:0kB writepending:32kB zspages:76228kB present:524288kB managed:484516kB mlocked:0kB bounce:0kB free_pcp:1960kB local_pcp:908kB free_cma:116kB [ 70.791945] lowmem_reserve[]: 0 0 0 0 [ 70.791963] Node 0 DMA: 276*4kB (MEC) 54*8kB (MEH) 90*16kB (MEH) 20*32kB (UE) 2*64kB (U) 0*128kB 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4000kB [ 70.792025] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 70.792038] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ 70.792051] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 70.792063] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ 70.792076] 24919 total pagecache pages [ 70.792084] 33 pages in swap cache [ 70.792091] Free swap = 184kB [ 70.792098] Total swap = 242256kB [ 70.792105] 131072 pages RAM [ 70.792112] 0 pages HighMem/MovableOnly [ 70.792119] 9943 pages reserved [ 70.792126] 32768 pages cma reserved [ 70.792133] 0 pages hwpoisoned [ 70.792140] SLUB: Unable to allocate memory on CPU 1 (of node 0) on node -1, gfp=0x820(GFP_ATOMIC) [ 70.792154] cache: kmalloc-8k, object size: 8192, buffer size: 8192, default order: 3, min order: 1 [ 70.792168] node 0: slabs: 29, objs: 116, free: 0 ... and many OOM killer actions to follow, but could type: poweroff It might be that is no zram swap and swap on disk, that is could work, but from some earlier HA topic here I remember that was a swapping hell on a 4-core Cortex-A53 and SD-card, way too slow. My KVM is image on NVME on ROCK5B, so fastest available more or less for 'cheap' ARM64 SBC. To compare: Domoticz did run OK with about the same amount of objects on a NanoPi-NEO (4x Cortex-A7, 512MiB, SD-card). It still does, but I moved most objects to a 2x Cortex-A55 1G RAM (KVM on same ROCK5B). # free -m total used free shared buff/cache available Mem: 963 330 77 2 635 632 Swap: 981 45 936 BUT I see also something with 'containers' when ZigBee in my google search. I would maybe see what exactly is needed. After many years, I also figured out that my 433MHz transceiver internally is just a 38k4 serial thing tied to an serial-to-USB chip. It was driven as serial port by Domoticz via USBIP on that NanoPi-NEO, but that needs explicit sync/reconnect actions at reboot. Now done via ser2net, swapping/replacing the device from serial to LAN in Domoticz, same database history, no actions at reboot/powercycle and with ser2net point-to-multipoint, also also available to multiple softwares in the home LAN or VPN etc if needed. Of course respecting write/send operations to be exclusive, just one. Same ser2net trick with electricity meter, that is why I can easily run HA/HAOS simultaneously with my normal home automation software stuff.

I changed allocated RAM for the virtual machine from 2G to 1G, still 4x Cortex-A55 vCPUs from RK3588 ROCK5B yesterday. At reboot and first login, it showed on 2 container, while earlier it showed a lot more. So now manual stats: root@lepotato:/etc/update-motd.d# ./10-armbian-header ; ./15-ap-info ; ./25-containers-info ; ./30-armbian-sysinfo _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v26.2.1 for Le potato running Armbian Linux 6.18.10-current-meson64 Packages: Debian stable (trixie) Containers: hassio_multicast, hassio_audio, hassio_dns, hassio_cli, homeassistant, hassio_observer, hassio_supervisor Performance: Load: 5% Uptime: 12h 18m Memory usage: 64% of 975M Zram usage: 56% of 487M Usage of /: 79% of 7.8G RX today: 54 MiB Only thing it really does is showing energy page, is 4x 10s sampled data (2x solar and power and delivery). Various Tasmota modules via MQTT don't claim that much resources I think. But strange is a rather constant regular dmesg like this: [44265.955953] hassio: port 2(vethf224414) entered disabled state [44265.957193] vethed7ef10: renamed from eth1 [44266.109287] hassio: port 2(vethf224414) entered disabled state [44266.116189] vethf224414 (unregistering): left allmulticast mode [44266.116262] vethf224414 (unregistering): left promiscuous mode [44266.116357] hassio: port 2(vethf224414) entered disabled state [44266.186986] docker0: port 1(veth76765bf) entered disabled state [44266.187218] veth1a28eaf: renamed from eth0 [44266.285174] docker0: port 1(veth76765bf) entered disabled state [44266.292147] veth76765bf (unregistering): left allmulticast mode [44266.292219] veth76765bf (unregistering): left promiscuous mode [44266.292256] docker0: port 1(veth76765bf) entered disabled state [44268.119635] docker0: port 1(veth51c04e7) entered blocking state [44268.119726] docker0: port 1(veth51c04e7) entered disabled state [44268.119797] veth51c04e7: entered allmulticast mode [44268.120352] veth51c04e7: entered promiscuous mode [44268.245380] eth0: renamed from veth916ebeb [44268.251728] docker0: port 1(veth51c04e7) entered blocking state [44268.251798] docker0: port 1(veth51c04e7) entered forwarding state [44268.384290] hassio: port 2(vethaf9bc59) entered blocking state [44268.384376] hassio: port 2(vethaf9bc59) entered disabled state [44268.384423] vethaf9bc59: entered allmulticast mode [44268.384986] vethaf9bc59: entered promiscuous mode [44268.513343] eth1: renamed from veth48fb602 [44268.520780] hassio: port 2(vethaf9bc59) entered blocking state [44268.520872] hassio: port 2(vethaf9bc59) entered forwarding state [44274.819685] audit: type=1400 audit(1784532963.305:477): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="hassio-supervisor" pid=35485 comm="apparmor_parser" [44274.819758] audit: type=1400 audit(1784532963.305:478): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="hassio-supervisor///usr/bin/gdbus" pid=35485 comm="apparmor_parser" [44274.819829] audit: type=1400 audit(1784532963.305:479): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="hassio-supervisor///usr/bin/git" pid= Maybe that is because the minimal KVM QEMU arguments: if ! test -f /usr/lib/u-boot/qemu_arm64/u-boot.bin ; then apt install u-boot-qemu fi cd /local/s0/vmimg taskset --cpu-list 0-3 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 1024 -smp 4 \ -bios /usr/lib/u-boot/qemu_arm64/u-boot.bin \ -drive if=none,file=armimg.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \ -nographic I think I will further limit to 512M and see if it still works; My older own HA Supervised used Btrfs as rootfs (compress-force=zstd:3 mount option), for this fake/KVM lepotato still Ext4 and I did: truncate -s8G armimg.img before 1st boot. For reference, I initially did change boot.cm/boot.scr to something rather static I had done long time ago for virtualizing ROCK3A, but it is more effective if this extlinux method is added to the image (need loopmount it before 1st boot, it assumes extlinux overrides boot.scr method): root@lepotato:/boot# cat extlinux/extlinux.conf menu title Select the kernel variant DEFAULT default TIMEOUT 80 LABEL default KERNEL /boot/Image INITRD /boot/uInitrd APPEND root=LABEL=armbi_root rootwait rw earlyprintk loglevel=7

Any updates on this H6 vs H616 ethernet issue?

Looks like I accidentally erased most of my u-boot from SPI flash since I don't have much experience with it. Are there any ways to restore it and what soft- and hardware do I need, apart from having a Linux PC and UART?

Updating U-Boot was the solution, kernel is now up to date!!! Thanks everyone for the tips, learned a few new things and the UART cable is really usefull!

@Werner @SteeMan Hah, I legit didn't know about the armbian-install command. I updated the bootloader and I guess I'm more up to date now U-Boot on boot is now U-Boot 2026.04_armbian-2026.04-S88dc-P3cfe-H5025-V315b-Bd0d2-R448a (May 30 2026 - 05:51:20 +0000) odroid-n2/n2-plus Gonna try to update the kernel now

Much to my chagrin I have had to do a similar dance today after running updates./. I tried sudo dpkg-reconfigure aic8800-usb-dkms but no joy. This time was easier and it was just a matter of getting the firmware and usb module directly from radxa's repo. ```wget https://github.com/radxa-pkg/aic8800/releases/download/5.0%2Bgit20260123.5f7be68d-6/aic8800-firmware_5.0+git20260123.5f7be68d-6_all.deb wget https://github.com/radxa-pkg/aic8800/releases/download/5.0%2Bgit20260123.5f7be68d-6/aic8800-usb-dkms_5.0+git20260123.5f7be68d-6_all.deb``` Then install both of them ```sudo dpkg -i aic8800-firmware_*.deb aic8800-usb-dkms_*.deb``` and then remapping the hardware and restarting ```sudo depmod -a sudo reboot``` Leaving this there... for next time I do an update

Much to my chagrin I have had to do the same dance today. I tried

I want to compile a matching build for: https://armbian.com/boards/odroidhc4 Debian 13trixie Minimal (CLI)—current6.18.33 https://dl.armbian.com/odroidhc4/Trixie_current_minimal Matching the img is fine (rather than the img.xz). I haven't compiled a matching build yet. I am doing this to debug my issue with the stock builds. Running: ./compile.sh BOARD=odroidhc4 BRANCH=current RELEASE=trixie BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_CONFIGURE=no Logs forthcoming.

I have the same on my 2 year old HA Supervised install I did once on a Debian Bookworm installation (Aarch64). I actually first did the same as you, not on a real HW Lepotato SBC, but as a KVM QEMU U-Boot. One only needs to change boot.scr in the (Amlogic) image, the kernel runs on virtio devices. I can confirm the 15-min waiting, or longer, I haven't looked at it, is a bit strange, but it magically still works this Supuervised. I did restore a backup from my Debian HA install, so very little effort. But it shows as problem that the OS is unsupported and also unsupported install method. The later is known and on HA Wiki/docs, supervised it not mentioned anymore, only the own HAOS en Container. I think 'Add-ons' are now called 'Apps' and also Container does not seem to support it. So for MQTT I anyhow have mosquito as Debian package installed. But teh Zigbee bridge is then a showstopper I see / I think. But also check yourself. I have no ZigBee HW and also HA is only testing for mee, see it it does things better than my current home automation softwares (mostly Node-RED based). The only option I see then is to put HAOS as KVM on Lepotato. It is 4x Cortex-A53 I see, so it can work. But not sure how RAM will work out. If 1GB RAM, then maybe 512M host and 512M guest. I have done that on RPI3 to run a router instance using VLANs.

But if you haven't run armbian-install to actually install the new boot loader, it is only sitting there waiting to be installed. Armbian does not automatically install new versions of the boot loader when apt pulls the new package, that is a manual step Edit: I should have read all the posts as I see Werner already said this

Results of my testing of prebuilt images with the Nano Pi M6: Armbian vendor kernel image (Gnome/resolute): no HW acceleration, even with Chromium. HDMI sound works but headphone output doesn’t. HDMI sound incorrectly identified as “Analog Output”. Armbian mainline kernel image (Gnome/resolute): HW acceleration works with Chromium but not with mpv. No sound, period. An audio device is identified and VU meter is active in the mixer, but both HDMI and headphones are silent. Official Friendlyelec image (Gnome/trixie): HW accel works with every media player I tested. Sound works perfectly, with devices correctly identified. System appears to be stable, with no crashes so far. Results of my testing of prebuilt images with the Rock Pi 5B: Armbian vendor kernel image (Gnome/resolute): no HW acceleration, even with Chromium. HDMI and headphone sound both work. HDMI sound incorrectly identified as “Analog Output”. Armbian mainline kernel image (Gnome/noble): HW acceleration works with Chromium. No sound. Clicking on the sound icon on the taskbar crashed the system and corrupted the filesystem, making the image unbootable. Official Radxa image (KDE/bookworm): HW accel and sound work for all media players I tested. There are issues with the ethernet driver and occasional video crashes when switching to fullscreen mode. Otherwise, the system appears to be stable. Verdict: if you want a usable RK3588-based workstation, use the images provided by the manufacturers. Armbian isn't quite there yet.

Oh well, that's quite some time ago. The patchset used back then has been removed/renamed already to move on. Look at 6df6d0d607abfd59169a0ef2fddbed5fcd5b58f9 The question is has this introduced upstream or with one of the patches Armbian puts on top. Quite a journey to dig through that.

@robertoj: Yes, it truly is the vanilla mpv. The package is from debian.org, not Friendlyelec. $ apt list mpv mpv/stable,now 0.40.0-3+deb13u1 arm64 [installed] $ apt list ffmpeg ffmpeg/stable,now 7:7.1.5-0+deb13u1 arm64 [installed,automatic] $ mpv --version mpp[949]: mpp_platform: client 18 driver is not ready! mpv v0.40.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects libplacebo version: v7.349.0 FFmpeg version: 7.1.2-0+deb13u1 (runtime 7.1.3-3rockchip) FFmpeg library versions: libavcodec 61.19.101 libavdevice 61.3.100 libavfilter 10.4.100 libavformat 61.7.100 (runtime 61.7.103) libavutil 59.39.100 libswresample 5.3.100 libswscale 8.3.100 $ cat /etc/issue Debian GNU/Linux 13 \n \l $ uname -a Linux NanoPi-M6 6.1.141 #16 SMP Thu Dec 4 14:51:28 CST 2025 aarch64 GNU/Linux $ apt-cache show mpv Package: mpv Version: 0.40.0-3+deb13u1 Maintainer: Debian Multimedia Maintainers <debian-multimedia@lists.debian.org> Architecture: arm64 ... Filename: pool/main/m/mpv/mpv_0.40.0-3+deb13u1_arm64.deb Size: 1270108 SHA256: ab039661c5016d96161fb9649b99cdde34ec4dfc83248ed9e42abb30318ac901

This may be an issue. I know from the past Armbian and petitboot don't work well together. You need to wipe your spi to get rid of it. Then everything should work just fine. Having this package installed means nothing about the actual used boot loader. This package only provides the binaries to rewrite the boot loader if actually necessary. It is updated with package install/upgrade because doing so is rarely necessary. armbian-install can update the boot loader and will use the binaries from the package.

On my version of the ROCK3A, I need to put a jumper across 2 pins so that the clock of the SPI chip is grounded/disabled. So the SoC has to read the bootloader from SD-card (I have no eMMC module). It is very clear that that works as intended and my only way to temporarily switch between old legacy U-Boot in SPI and some latest/newer mainline based. Anyway, as Werner says, that old dated 2015 U-boot is certainly not Armbian, so unsupported by Armbian and you need to figure out yourself. Also the word 'feels' makes no sense; you need to be sure and show proof, else no-one is gonna do anything for you anymore. Armbian specific Amlogic kernel, as installed on images, also runs directly in a ARM64 KVM if loaded by the generic QEMU u-boot.bin you find on standard Debian systems. It just needs a proper set of commandline args of qemu-system-aarch64. I have done that several times for people having trouble with images (Amlogic, Allwinner) although I have none of these 2 64-bit SoC's, only Broadcom and Rockchip. Yes sure, but the binary u-boot.bin or so is not written automatically to your hardware, it only is in the image (as package you show) and in the first sectors of the image. So not used if SPI-flash have another bootloader and if that has higher prio at power-on and has no chainloading mechanism (for loading the one from the image in eMMC or SD-card).

Hi. I'm not sure if this is the right place to ask. I was basically running my Radxa Rock 5 ITX home server on Armbian, on the edge upstream kernel for a long time. Somewhere during the 6.19 release candidate kernel series an instability arised, where the machine would hard lock "at random", so I switched to the current kernel since, which to this day remains on unaffected 6.18. But from time to time I try with edge again, and the instability is still present with the 7.1 upstream kernels. Moreover, with the load the machine has I can consistently trigger the lock up just by ssh-ing into the machine once it's been up for 10 minutes or so. I've since enabled the HW watchdog timer, which helps a bit mitigate the frustration here... I guess at some point current will move past 6.19, and I really would like to have the improved hardware support for newer kernels anyway. I would like to be able to bisect the kernel sources to find out where things broke down. I think I understand enough of the build system to generate edge kernel packages, but I don't know how to do so while bisecting the upstream kernel sources. I also couldn't find documentation about how to trigger the build system to build the kernel at a particular commit. Is there any particular guidance on how to go with this? Thanks.

@Werner I only installed Armbian (written image through BalenaEtcher to emmc card) I reflashed Petitboot on SPIFlash a few weeks ago since I broke it while testing but the kernel update was broken months before that. Don't think they affect each other. I boot PetitBoot through the physical switch on the board itself (So SPIFlash) so it should have it own separate U-Boot. @eselarm I think on my board you can physically switch if SPI-flash or eMMC is used. If I set the switch the eMMC it should take the bootloader on the eMMC? https://wiki.odroid.com/odroid-n2/software/boot_sequence It feels more like the boot format changed from 6.12.xx to 6.18.xx? If I look at my installed packages I do have the latest available u-boot btw linux-u-boot-odroidn2-current: Installed: 26.5.1 Candidate: 26.5.1

This is from Hardkernel, I don't have an Amlogic SBC, but I once saw petitboot is sort of boot-selection and/or OS installer (menu driven) thing. Same as for Rockchips where old RK35xx mostly 2017.09 based U-Boot does not work with newer mainline based kernel, you can expect the same here. So wherever that U-Boot is stored (SPI-flash, eMMC), you need to make sure it is not used, so wipe it or bypass it or overwrite it with the U-Boot binary that comes with the Armbian image you try to boot. In your currently running system, so with old kernel but new userspace, you should be able to use armban-config to flash the current and kernel 6.18 matching U-Boot to the specific storage where petitboot is now stored. But means overwriting, I would first save it, done that for some other ARM boards (also smartphones) at least as you never know if you might need the exact old/vendor firmware/bootloader for fixing some problem many years from now. So make sure you know the right sector numbers for that Amlogic SoC where it look for bootloader at power on. Can be found in docs (Hardkernel) or see /usr/lib/u-boot/platform_install.sh

Update: if I wait long enough, then I finally see the Reboot screen. After reboot, I can go to http://<IP_address_Le_Potato>:8123 and I do see the Home Assistant intro screen. After creating an account, giving the location parameters and so on, I finally get the Home Assistant screen. I see in the command terminal that the following containers are available: hassio_observer hassio_supervisor See attached image. However, when I go to Settings, I don't see the Add-ons section. I admit I'm not a Home Assistant expert yet (first steps into HA) but I thought that the superviisor was just to have the Add-ons section available to the user? That's the reason I tried the Armbian Home Assistant image, hoping the Add-ons section would be available. Do I have to make myself a "supervisor" (again, I'm not a Home Assistant expert yet...)? If so, how can this be done? I need MQTT and Zigbee2MQTT, hence the need for the Add-ons section, which I currently don't have... Best, --Geert

Where did you get this uboot? I strongly believe this is not from Armbian, hence support is impossible.