eselarm

see what is /etc/exports on the nfs-server something like *(rw,no_root_squash,no_subtree_check) should give more or less unrestricted access. And not to forget id-mappening for non-root, unless you manually made sure same uid gid for users

Long time since I really did run wine, but I still have it installed on Opensuse Tumbleweed (x86_64). That is a rolling release with latest Linux and in the past years I found out udev are less and less needed. For network devices, you can for example use a systemd network .link file to rename and have nice static names (based on MAC-address). For serial ports via USB, you can use existing unique serial device name, e.g. in my ser2net.yaml file: connector: serialdev,/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AC2YVFHY-if00-port0,115200n81,local Works great and rather critical as this is my energy measurement thing. It should be possible to create another symlink named COM<x> to those names. Around 2 years ago there was once a Debian systemd problem and then this build-in method failed, but was fixed rather quick. What the difference is between other Linux computer and this one, I don't know. The original topic is 2 years old and other board. So no-one really can reproduce you problem, that is why I just write a working methodology and forget about this topic I guess.

This image: 5b7b6e973a920094a91297e1b8f07a2352bb67da48e925652a75c58c185a576e Armbian_26.2.1_Orangepi4-lts_trixie_current_6.18.8_minimal.img.xz uses U-Boot version: U-Boot 2025.10-rc5_armbian-2025.10-rc5-S2f2a-P4b2d-H8e96-V50db-B2eb2-R448a (Feb 01 2026 - 04:45:24 +0000) BUT, it seems your board has an older U-Boot version stored somewhere, and the one form vendor is again a different version. For Rockchip SoC's, it is known that old U-Boot (from the vendor) does not work with new Armbian mainline based kernels. That 2025.10-rc5 version should work with 6.18 kernels, but if the board will likely start with that old U-Boot, skipping what is on the SD-card. You need to wipe SPI-flash and/or eMMC, so the only option is load the U-Boot from SD-card. You can use the working vendor image to do wipe operations. Make sure you know how dd works. Use sudo lsblk to see what devices are there.

Maybe on you Bookworm installation, you have something in /etc/sysctl.d/ or so (once added by yourself) which is not there by default on standard/new/fresh Debian. It is about a decade ago I did that as well when manual iptables actions for WiFi AP's etc. If using NM or systemd-networkd config files, it is done there. And I see in Debian Trixie some old files are not there anymore, maybe read /etc/sysctl.d/README.sysctl

That is interesting, I would expect the other way around. I use 'btop' to watch clocks and load. On some systems, it also show GPU load and power consumption. Anyway, there is also the edge kernel (7.1.0-edge-rockchip64😞 linux-image-edge-rockchip64/trixie,now 26.5.1 arm64 [installed]

OK great that you got it working now! 2GB RAM works fine for HA, at least when running Supervised. I am not sure if Armbian can improve more when Supervised, as this is not supported anymore from the providers/developers of Home Assistant. I think a reason people go from SBC to Intel NUC is because there are things like VMware that IT pros might know from their profession/company. And RPL very long by default had/advised to use 32-bit also on more capable devices like RPi4 with 2GB RAM or even more. And also running from SD-card, and those wear out under high load and many writes. The whole problem with 'traditional RPi' is that it is unusual 32-bit ARMv6 build and not the standard 32-bit ARMv7 which is the minimum for support from Debian and most other distros. And in addition, 32-bit builds do not support the standard Linux Kernel Virtual Machine HW, standard in all 64-bit capable CPU's. Intel/AMD CPU's have support for HW virtualization also for 32-bit and much more known and commercial (also closed-source) hypervisors like VMware are pushed a lot more then the standard Linux build-in QEMU/libvirtd/KVM. So with 64-bit Linux, especially also on ARM, you get it by 'apt install virt-manager' and then you can run other OSses/images at full HW speed and is separated from the host OS, e.g. Armbian. Because images, many files or bigger databases are a burden for simple SD-card. Also because multiple OSses at the same time, it easily needs more RAM than the usual 1GB on SBC's like RPI3. Via virt-manager GUI and also CLI tool virsh, you can then run the generic UEFI bootable HAOS. For long-term and decent 24/7 operation, you will need SSD for storage. RPi's don't have that, you need adapters and HATs etc. But many other SBC's do have, so if you have an unused NVME for example, it fits perfectly in RK388 boards like ROCK5B for example. It is 4-lane PCI-E v3, so similar speed as Intel miniPC's. And most important, lower power consumption for similar total system price, at least before the RAM+storage prices went sky high. I measured my NanoPi-R6C with Samsung 970 NVME and Armbian Trixie (6.1.115 kernel) and is about 1.5 Watt when idle or doing some light tasks like running simple initial HAOS as Virtual Machine. See also:

A difference between FriendlyElec image and Armbian image is U-Boot ( bootloader/firmware ) variant I think. For my NanoPi-R6C, HDMI audio does not work if I boot from SD-card where an image with a U-Boot from 2026 is written in the boot area (between main GPT and 1st partition). If I wipe that U-Boot by zeroing that area, the OS will take EDK2 UEFI v1.1 that I have written to eMMC. Then there is HDMI sound, on Armbian and Opensuse Tumbleweed. I need to check if I run it in hybrid ACPI+DeviceTree mode or just DeviceTree mode. The setting is anyway 'mainline kernel' DT, which should be about 6.10 or later. If I select 'vendor kernel', it can only run Armbian 6.1.115, but I don't remember if KDE6 Wayland does work then. I only did that to check if I idle power consumption was still < 1.5 Watt, which was the case. Else it is 3 Watt and min clock is 1GHz instead of 480MHz and more differences. I remember I saw some U-Boot version scrolling by when I messed up partitions on eMMC (might just be corrupt 2nd backup GPT), I think the UEFI code did fall back to some build-in U-Boot. Now I did check certain things: # gunzip < rk3588-sd-debian-trixie-gnome-wayland-desktop-6.1-arm64-20260629.img.gz | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g50821b3c8bd-241113 #fa (Jan 02 2025 - 16:53:42) # cat nanopi-r6c_UEFI_Release_v1.1.img | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g5f53abfa1e-221223 #zzz (Dec 26 2022 - 09:10:09) So the EDK2 seems to contain some old base U-Boot and also the FriendlyElec image same U-Boot base, however, it can be different and certainly is incompatible with mainline recent year U-Boot and also likely the vendor tagged one from Armbian. FriendlyElec could do various HW initialization in a different way and on top of that or mixed with it, EDK2 again does things. It needs rebuild EDK2 from source or so in order to gain more know-how and check. I also see the kernel version string in the FriendlyElec image is '6.1.141' (Armbian is '6.1.115-vendor-rk35xx' ), what that means I don't know, kernel.org is at 6.1.177 (2026-07-04). I am using 7.1.3+deb14-arm64-16k #1 SMP PREEMPT Debian 7.1.3-1 (2026-07-04) from Debian Sid repo, userspace is Armbian Trixie. So no HW accel, at least not in KDE6 with FireFox. The added RKMPP libs are 1 thing, the DMA devices are another. Names like 'uncached' and 'dma32' are important hints on how and what is implemented, wrapping tactics etc. The whole issue with those FriendlyElec images is, at a Debian minor update for example, those libav* files get overwritten. In addition, kernel sources w.r.t RKMPP are banned from github. So those images from FriendlyElec are a 1-time shot, works as longs as you don't update. I spent a lot of time to build RPI kernels and their ffmpeg/libav variant. It changed several times, now I don't use it anymore in a generic way, mainly because the HW encoder is fairly limited and does also not work anymore with Jellyfin ffmpeg build (for transcoding on-the-fly). Same for OpenSuse, they are strict on MPEG licensing/royalties, so no MPEG2,H264,HEVC etc, you extra need other repo to make it work. To come back to OP topic title, LibreElec (so dedicated Kodi) worked fine HW accel for HEVC, H264, H265, AV1 and partly for VP9. Was about 9 months ago I ran that dedicated from separate SD-card, so LE's own U-Boot and kernel etc, all mainline based. But is only decoders, so playing video on a usually larger HDMI monitor. So the kernel can do it, it is just many different API's and protocols. FireFox focuses on VAAPI AFAIK, so known to work fine on Intel HW, but needs then tweaks to work with v4l2_m2m AFAIK. Maybe look at RPi's FireFox patches, although I think it is proprietary for their Broadcom tailored kernel, so won't work with mainline Linux nor Rockchips stuff on RK3588.

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

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.

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).

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

You should check with: grep non-free /etc/apt/sources.list.d/*.sources And remove the non-free components and also remove/purge all packages that belong to non-free. You probably need some 'man apt-get' to figure out how to select those.

I see in your log: [ 15.439789] sun7i-dwmac 1c50000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 15.466497] sun7i-dwmac 1c50000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) [ 15.677165] sun7i-dwmac 1c50000.ethernet end0: Failed to reset the dma [ 15.758481] sun7i-dwmac 1c50000.ethernet end0: stmmac_hw_setup: DMA engine initialization failed [ 15.772254] sun7i-dwmac 1c50000.ethernet end0: __stmmac_open: Hw setup failed If I look at my bpi: root@banlipi:~# dmesg | grep ethernet [ 3.767952] sun7i-dwmac 1c50000.ethernet: IRQ eth_wake_irq not found [ 3.774414] sun7i-dwmac 1c50000.ethernet: IRQ sfty not found [ 3.780287] sun7i-dwmac 1c50000.ethernet: PTP uses main clock [ 3.894850] sun7i-dwmac 1c50000.ethernet: Version ID not available [ 3.902941] sun7i-dwmac 1c50000.ethernet: DWMAC1000 [ 3.907950] sun7i-dwmac 1c50000.ethernet: No HW DMA feature register supported [ 3.915196] sun7i-dwmac 1c50000.ethernet: TX Checksum insertion supported [ 3.922008] sun7i-dwmac 1c50000.ethernet: Normal descriptors [ 3.927689] sun7i-dwmac 1c50000.ethernet: Ring mode enabled [ 5.766296] sun7i-dwmac 1c50000.ethernet end0: renamed from eth0 [ 19.418540] sun7i-dwmac 1c50000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 19.465510] sun7i-dwmac 1c50000.ethernet end0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) [ 19.476982] sun7i-dwmac 1c50000.ethernet end0: No Safety Features support found [ 19.484490] sun7i-dwmac 1c50000.ethernet end0: RX IPC Checksum Offload disabled [ 19.491897] sun7i-dwmac 1c50000.ethernet end0: No MAC Management Counters available [ 19.508289] sun7i-dwmac 1c50000.ethernet end0: PTP not supported by HW [ 19.514967] sun7i-dwmac 1c50000.ethernet end0: configuring for phy/rgmii-id link mode [ 23.717977] sun7i-dwmac 1c50000.ethernet end0: Link is Up - 1Gbps/Full - flow control rx/tx root@banlipi:~# uname -a Linux banlipi 6.18.35-current-sunxi #1 SMP Tue Jun 9 10:28:53 UTC 2026 armv7l GNU/Linux So no DMA related problem. The AI advise is nonsense IMO; There might some (longterm) hidden bug/issue in the sunxi kernel when running on bananapi as mine usually hangs after a few days with a kernel paging issue, root cause I don't now. BUT, now tha I am challenging this with 24/7 kernellogging via serial console, 'it does not wanna crash': root@banlipi:~# uptime 14:32:05 up 7 days, 18:13, 1 user, load average: 0.07, 0.14, 0.12 I must say only thing it does is read out the AXP PMU values every 10s and pushes that into influxDb. Maybe I should hook up a SATA SSD or HDD and see if I can repeat. Maybe doe upgrade, so you get newer kernel (6.18.35): sudo apt update && sudo apt full-upgrade -y

I discovered via an only partly working ssh (I thought was WiFi signal strenght issue or so) that a new version of firewalld was installed and also new conf file that had default set to public instead of trusted (what should be fine for LAN only direct traffic). On a typical generic client-only laptop/computer you probably won't notice. Best is to keep that default and add a zone= statement to the NM profile for a specific connection. I have seen the same for systemd-networkd, but not done anything myself with it. Also should not happen on Debian Stable, but rolling distro is another story.

Yes, I already forgot this and maybe more; Armbian uses this by default now AFAIK, so this is another issue like netplan; I normally do in-place dist-upgrades, so my older SBC's I bought when Buster was the current Debian version, so that is still somewhere in a tag in a image generation file or so, but os-release is 13 and kernel 6.18. But for 1 case, I did take a recent/new Armbian image (Trixie) and it did cost a lot of time as the default settings for that don't work properly in my home network, so after reading freedesktop.org docs and with extra setting in conf file, it worked. But openresolv and a fixed resolv.conf is a simpler base.

So you try routed AP instead of bridged. Trixie might handle 'iptables' in a different way, depends also what alternatives you have for that and/or if it is netfilter underneath. This kind of manual setup (routed, hostapd) I did before Bookworm only a few times, rest is always bridged and basically using only NM. It seems to me that something on IP layer is not accepted by your phone, so it disconnects. You need to dig more and deeper and also still take in to account what is said about that brcmf_psm_watchdog_notify issue. But it seems yest another issues.

There is no proof it is the same problem. As I told you in topic: your Ultra does not have the same SoC as the original/normal OPi5. So this posting in the wrong group and is getting annoying. You should focus on RK3588, not the RK3588S Also the Ultra is community support only, so you are part of that. Make sure you understand installing latest kernels and U-Boot etc yourself manually and also building Armbian yourself. From latest other post here, I conclude that the 7.1 kernel at least can show some sign of life from NVME. Xunlong dumps HW on the market at a high rate, you cannot trust or build on that reliably. Check everything, even their 'official' image, where do the sources come from etc. My perception is that they just clone a certain old version of the Armbian build system, then make it work, likely only boot from SD-card and then they go on the next HW/marketing/vaporware.

The other usual thing is then PSU. So also maybe try a different one. Else I cannot really help you, not being able to find rootfs can have pure software cause, but is unlikely if other people can run it successfully. I wish I had bought this SBC a year ago, but I didn't and now they are sold out where I looked, so cannot see If I can reproduce the problem. You need to look in more detail yourself, like connecting serial debug console and setting loglevel to 7 in armbianEnv.txt. Also post which exact image is (sha256sum), so other people can try the same thing.

If it worked once and now not anymore, it might be the SD-card that is the problem. It might be a as bad that it is a fake SD-card.

Similar quick test here: N100 with PCIe ethernt and wifi HW, already a br0 with enslaved ethernet, I set up a working hostapd.conf, enabled hostapd.service and added /etc/systemd/network/22-wlp2s0.network [Match] Name=wlp2s0 [Network] Bridge=br0 ConfigureWithoutCarrier=yes Then reboot and properly working AP. Is Opensuse Tumbleweed. But it is rather 'static', not as flexible/dynamic as with NM. For example, if I do networkctl down wlp2s0 ; sleep 30 ; networkctl up wlp2s0 the AP still works, but network list shows failed for wlp2s0 I though maybe it has to do with the fact that Tumbleweed has no sysV compatibility anymore (folder /etc/init.d/ is not there), so no option that something goes wrong potentially due to some sync issues, but I think I cannot draw that conclusion. Quick check shows no relation between hostapd.service and systemd-networkd, but it is much more extensive than for debian13 for sure.

This should be specified down to just 2 things: Armbian U-Boot package and kernel package. The DTB package is redundant as the .dtb file is in the kernel package. For more low-level tests, I usually rename boot.scr and use manual extlinux, so easy to select a certain kernel+initrd+dtb(o). This also works for example with Opensuse Tumbleweed as userspace although (Wayland KDE ) GUI not anymore with vendor 6.1.115. For just standard Ext4 rootfs, note that multiple kernels is automatically handled by standard Debian package u-boot-menu (see its config in /etc/default/u-boot).

Then I don't know why it does not work, and I would assume this combination of SBC and NVME just won't work. Such cases exists, although frustrating that is does not work. You could cross check, but I don't know it you have other brands NVME to try with the OPi5 Ultra. I would also be not surprised if there is simply something wrong of missing in the U-Boot or DTB (all versions, even the one from manufacturer/xunlong). You can look at versions history of U-Boot for example, just to see how much your luck is or would be. And/or until someone with the same combination sees this topic. I only have Samsung NVME's. primarily 970+ in a ROCK5B, is also RK3588 4-lane PCIEv3 and older earlier 970 in an ROCK3A (2-lane PCIEv3). The latter one works but only with a very specific set of U-Boot, BTB and kernel (for my use case).

Ultra is not the standard OPi5 nor OPi5Pro, AFAIR it is also RK3588 v.s. RK3588S wich is a major difference w.r.t. PCIE Use a recent kernel/image, see https://armbian.com/boards/orangepi5-ultra And report brand and type of the M.2 NVME SSD. Some people have asked similar question and turned out to be a M.2 SATA SSD

Good that your bpi appears to be stable. My did hang again, no reaction on serial console, no reaction on IP networking. So I enabled the watchdog, uncommented the 'ping 192.168.1.1 line' and made it ping 192.168.1.100 and temporarily added that address to another computer: ip addr add dev br0 192.168.1.100/24 Then removing it: ip addr del dev br0 192.168.1.100/24 and after a minute or so: [ 263.929336] systemd-journald[236]: Received SIGTERM from PID 1071 (watchdog). [ 265.185973] systemd[1]: systemd 257.13-1~deb13u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE) [ 265.221538] systemd[1]: Detected architecture arm. [ 269.100327] systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error [!!!!!!] Failed to start up manager. [ 269.146571] systemd[1]: Freezing execution. This looks like HW watchdog does not work. Same trick on NanoPi-NEO, so also sunxi kernel although 7.0.12-edge-sunxi, it resets. So appears to work although no proof that it is HW reset. I have not checked live dmesg or so, just noticed it went offline and came back later when I also added that .100 IP address again.