I'd like to add my observations. The current version is 7.0.0-rc6-edge-sunxi64. The wireless interface is available, but if Ethernet is connected, it's impossible to connect to either interface via SSH. However, as soon as the Ethernet speed is set to 100, both interfaces become operational. Maybe this will help revive the hardware.

Does it? Does not look like 192.168.71.1 to me... And: That is not correct, that is the global scope, no ip can end with 0. Ehhh... What do you call dnsmasq on your router then?!? If you don't "maintain" that, yes, things like this can happen, especially since you have set the leases to never expire. I have no idea if this is the case, it's for YOU as sysadmin of your network to know. Nobody knows what you did after install. All that is known after all things written in this thread: You have a dhcp server you have a dns server (dnsmasq) you installed Armbian_26.2.1_Bananapim5_noble_current_6.18.15_xfce_desktop.img (that comes with network manager according to documentation) It seems you have systemd-networkd enabled Unless you can prove the default config was with both systemd AND network manager, YOU have made changes that breaks the installation. Nobody can answer what you did, only you. The normal way if having a local dns server (even if it ONLY forwards request to outside dns server) is to configure the resolving for local domains in the dns server and not touch it at device level. For example a consumer grade router, it will set dns to router ip in the dhcp lease and when requests come in, resolve with asking your ISP dns servers. Hence, if looking up what dns server is used on the devices, they will NOT point to your ISP dns servers (or google or cloudflare etc), it will point to your router ip. Lets say you have a pihole on your network that acts as dns server, then you configure the router (dhcp server) to point to THAT ip for dns, hence, the dhcp lease will deliver THAT ip. And then you configure the pihole to resolve local ip:s and what outside dns servers to use. The DEVICES will ONLY see the local ip where the pihole lives in this situation. Resolving domains to local ip:s (/etc/hosts on your device) has nothing to do with your dns detection failing. This is all pretty basic networking... Edit For reference, this is what your /etc/resolve.conf should look like (or similar) if you configure your dhcp server to point at the ip where dnsmaq lives (same ip as the router itself) then propagate those settings via the dhcp lease. Then nothing has to be done on any device except for resolving local ip:s if you refuse to do that with dnsmasq. If you configure dnsmasq to do that, resolving will be done on the router instead of the devices and absolutely nothing has to be done on any device. With systemd: # Generated by resolvconf domain home nameserver 192.168.71.1 With network manager: # Generated by NetworkManager search home nameserver 192.168.71.1 If you don't want to reinstall again, make sure systemd network services are disabled and network manager is enabled and then reboot. But be mindfull you might need physical access if network completely fails at boot. IIRC relevant services are (I could be wrong here, you should read up on documentation) systemd_networkd.service, systemd_resolved.service & networkmanager.service I'm in the middle of moving, so I only have an arch desktop and laptop up and running at the moment, so I can not confirm on any armbian installation that I provide 100% accurate information.

@bschnei - Yep.. it was modules, via uInitrd. Sadly the legacy config says the kernel bootarg param is 'initrd', so that lost me a good chunk of my life i'll never get back. using RAMDISK_START as the boot arg helped. This did, indeed, load the sata modules, which raised the disk. [EDIT: lol. RAMDISK_START apparently isn't even relevant? grep 'Unknown kernel command line parameters' *.log EspressoBin_Ultra-Bootlog.2026-04-03_001.log:[ 0.000000] Unknown kernel command line parameters "RAMDISK_START=0xa00000 biosdevname=0", will be passed to user space. EspressoBin_Ultra-Bootlog.2026-04-03_003.log:[ 0.000000] Unknown kernel command line parameters "RAMDISK_START=0xa00000 biosdevname=0", will be passed to user space. EspressoBin_Ultra-Bootlog.2026-04-03_004.log:[ 0.000000] Unknown kernel command line parameters "RAMDISK_START=0xa00000 biosdevname=0", will be passed to user space. Not sure why it's working now... ] In case this might help someone later, here's the uboot init config I used for the EspressoBin-Ultra to boot from NVMe / SATA / sda1 / SCSI: => setenv scsi_rootfs "UUID=8045e72d-9d9e-465c-a9ee-95cad5513ec8" => setenv scsi_boot_init 'scsi scan; scsi dev 0' => => setenv scsi_kernel_addr_r '0x7000000' => setenv scsi_kernel_name '/boot/Image' => setenv scsi_kernel_load "ext4load scsi 0:1 $scsi_kernel_addr_r $scsi_kernel_name" => setenv scsi_initrd_name '/boot/uInitrd' => setenv scsi_initrd_addr 0xa00000 => setenv scsi_initrd_load "ext4load scsi 0:1 $scsi_initrd_addr $scsi_initrd_name" => setenv scsi_fdt_name '/boot/dtb/marvell/armada-3720-espressobin-ultra.dtb' => setenv scsi_fdt_addr_r '0x6f00000' => setenv scsi_fdt_load "ext4load scsi 0:1 $fdt_addr_r $scsi_fdt_name" => setenv scsi_setbootargs "setenv bootargs $console root=$scsi_rootfs rw rootwait RAMDISK_START=$scsi_initrd_addr net.ifnames=0 biosdevname=0" => setenv scsi_booti "booti $kernel_addr_r $scsi_initrd_addr $fdt_addr_r" => setenv scsi_boot "$scsi_boot_init; $scsi_kernel_load; $scsi_initrd_load; $scsi_fdt_load; $scsi_setbootargs; $scsi_booti" => printenv scsi_boot scsi_boot=scsi scan; scsi dev 0; ext4load scsi 0:1 0x7000000 /boot/Image; ext4load scsi 0:1 0xa00000 /boot/uInitrd; ext4load scsi 0:1 0x6f00000 /boot/dtb/marvell/armada-3720-espressobin-ultra.dtb; setenv bootargs console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=8045e72d-9d9e-465c-a9ee-95cad5513ec8 rw rootwait RAMDISK_START=0xa00000 net.ifnames=0 biosdevname=0; booti 0x7000000 0xa00000 0x6f00000 => run scsi_boot And there we go: [ 3.783163] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 3.790704] ata1.00: ATA-11: ORICO, Y0908A0, max UDMA/133 [ 3.796101] ata1.00: 2000409264 sectors, multi 1: LBA48 NCQ (depth 32) [ 3.824725] ata1.00: configured for UDMA/133 [ 3.829607] scsi 0:0:0:0: Direct-Access ATA ORICO 8A0 PQ: 0 ANSI: 5 [ 3.839402] sd 0:0:0:0: [sda] 2000409264 512-byte logical blocks: (1.02 TB/954 GiB) [ 3.847435] sd 0:0:0:0: [sda] Write Protect is off [ 3.852470] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.861614] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes [ 3.883685] sda: sda1 [ 3.886538] sd 0:0:0:0: [sda] Attached SCSI disk Sadly, the kernel is still panicing, during load.... which is basically where I started way back when using 2018 uboot version.... below is the summary, but attached are various boot logs. _001 and _004 are probably the only useful ones though. [ 6.518199] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout... [ 6.537048] SError Interrupt on CPU0, code 0x00000000bf000001 -- SError [ 6.537084] CPU: 0 UID: 0 PID: 171 Comm: 9 Tainted: G M 6.12.68-current-mvebu64 #5 [ 6.537096] Tainted: [M]=MACHINE_CHECK [ 6.537099] Hardware name: Globalscale Marvell ESPRESSOBin Ultra Board (DT) [ 6.537104] pstate: 20000000 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 6.537111] pc : 0000ffff9bb2be30 [ 6.537114] lr : 0000ffff9bb2d268 [ 6.537117] sp : 0000ffffea848f80 [ 6.537119] x29: 0000ffffea848f80 x28: 0000ffff9bb51540 x27: 0000ffff9a95b8c8 [ 6.537134] x26: 0000ffff9a880000 x25: 0000ffff9bb5eb70 x24: 0000000000000000 [ 6.537144] x23: 0000000000000000 x22: 0000000000000000 x21: 0000ffff9a9771e0 [ 6.537154] x20: 0000ffff9bb51540 x19: 0000000000000000 x18: 0000000000000fff [ 6.537163] x17: 0000000000000000 x16: 00000000ffffffff x15: 00000000000a6de8 [ 6.537173] x14: 0000000000000000 x13: 0000ffffea849080 x12: 0000ffff9bb4e000 [ 6.537183] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000ffff9a88ae50 [ 6.537192] x8 : 000000000001169a x7 : 0000ffff9a9771e0 x6 : 0000ffff9bb5e000 [ 6.537202] x5 : 0000ffffea849080 x4 : 0000000000000000 x3 : 0000000000000000 [ 6.537211] x2 : 0000000000601588 x1 : 0000ffff9ae62860 x0 : 0000ffff9a95a8c0 [ 6.537223] Kernel panic - not syncing: Asynchronous SError Interrupt [ 6.537228] CPU: 0 UID: 0 PID: 171 Comm: 9 Tainted: G M 6.12.68-current-mvebu64 #5 [ 6.537236] Tainted: [M]=MACHINE_CHECK [ 6.537239] Hardware name: Globalscale Marvell ESPRESSOBin Ultra Board (DT) [ 6.537243] Call trace: [ 6.537248] dump_backtrace+0x98/0xf8 [ 6.537265] show_stack+0x20/0x38 [ 6.537272] dump_stack_lvl+0x34/0x90 [ 6.537283] dump_stack+0x18/0x28 [ 6.537290] panic+0x3a8/0x410 [ 6.537299] nmi_panic+0x48/0xa0 [ 6.537306] arm64_serror_panic+0x78/0x90 [ 6.537313] do_serror+0x44/0x80 [ 6.537320] __el0_error_handler_common+0x3c/0xa0 [ 6.537330] el0t_64_error_handler+0x10/0x20 [ 6.537340] el0t_64_error+0x190/0x198 [ 6.537350] SMP: stopping secondary CPUs [ 6.537373] Kernel Offset: 0x237629600000 from 0xffff800080000000 [ 6.537377] PHYS_OFFSET: 0xffffacdfc0000000 [ 6.537380] CPU features: 0x00,00000090,00200000,4200421b [ 6.537386] Memory Limit: none [ 6.742429] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- EspressoBin_Ultra-Bootlog.2026-04-03_001.log EspressoBin_Ultra-Bootlog.2026-04-03_002.log EspressoBin_Ultra-Bootlog.2026-04-03_003.log EspressoBin_Ultra-Bootlog.2026-04-03_004.log

Ooh interesting! The PBP in your video is using Manjaro though, can PPSSPP compile on Armbian? Perfect Dark aside, I haven't had any luck compiling other supposedly ARM64 compatible software like 2Ship2Harkinian etc through Armbian. If we can figure it out then maybe GoW will also be more playable on PBP through its own eventual native PC Port.

In this local network, there is only one name to address configured in dd-wrt. dnsmasq The only true dns server is at my ISP and its been that way here since RH5.0 in 1998. I have NO M$ experience in my personal history, coming into modern computing by way of a TRS-80 Color computer running os-9, to amigados, about 10 of them as I drug WDTV-5 into the computer age when I became the Chief Engineer in 1984, but I started computing in 1978 at KRCR-12 in Redding Kalipornia. Writing a utility to prepare an automatic station break machines tapes for air that ran on an RCA-1802 and 4k os static ram that cost $400 back then. But lets get back on topic. What I want for outside names NOT in /etc/hosts: the query gets passed to the router at 192.168.71,1:53 where dnsmasq checks to see if its in its cache, and failing that, fwds the query to the dns server at my ISP for resolution. That address is not known on my side of the router. This typically adds about 1.5ms to the ping time. And nowhere in that chain fails this sequence EXCEPT this new install on a bananapi-m5. And I don't have to screw around maintaining a separate dns server of any kind. That is several times the amount of monkey business of cp-ing a common hosts file around is. But you want to insist on a dns server behind every RJ-45 jack in the house. I don't understand the Why? This is simple, quick and bulletproof until somebody decides to fix a perceived security hole, WHICH DOES NOT EXIST IF the router is reflashed with dd-wrt. I have not been touched since finding out about it in yr 1999-2000. Including a decade of running my own web page right here on this machine, stopped only because the spiders refused to honor my robots.txt. So I was paying bandwidth penalties of $150 or more a month on an SS income with my upload bandwidth filled by the robots from mj12. Whoever the hell they are. M$ spiders were in there too. People interested in my stuff couldn't get a word in edgewise. So please tell me where in the resolv.conf area what to edit to make it work, cuz I'll do it and a chattr +i on it to make it permanent. But the fix for debian bookworm, didn't fix this.