Worth trying all of them.

You mix up 2 things: - 'msdos filesystem' which usually means 'FAT' - 'msdos table' which usually means 'MBR partition table' Both can be up to 2 TeraBytes when sector or cluster size is 512 bytes. So no reason to change to GPT. Changing to GPT (with standard 128 entries), will use the same space as where the U-Boot bootloader is located on SD-card for older Arm chips, like Allwinner A20 (original bananapi). So risk is un-bootable. Back to your networking issues: I have not read all, but this BPI-M5 image is Ubuntu based and I see NetworkManager. So that means you also get netplan. I don't want that, so I only use Debian based images as a start. But it seems that if you use 'nmtui' text based tool that you still can quite easily set fixed IP addresses locally. At least that is the case for 'Raspberry Pi OS Trixie' where they also made a dependency between netplan and NetworkManager. Then since this year also Debian by default uses systemd-resolved for their pre-installed (cloud) images for DNS. This means it all won't work out of the box for you. Same was the case for me, I use also my own router and DNS server and that did not work with Armbian (half a year ago). I think now some extra is done, as tests with 26.2 images what Igor asked for, worked OK, but only did boot them via serial console. Look up the forum topic about it if you want to know, I already forgot. So to work with local hosts file on every computer, the whole Linux must prioritize hosts file over DNS resolver. That is determined in /etc/nsswitch.conf I have at least 2 ARM64 computers that need fixed IP (they must work without router) so I have a few entries in hosts file, very limited and dedicated, as rest is all in router. So what I do with new images when some tests or so, is (as root): systemctl disable --now systemd-resolved # this stops the DNS resolver and also makes sure it won't start after reboot rm /etc/resolv.conf # when systemd-resolved is used, this file is a symbolic link to tmpfs in RAM, so if not removed, your next settings are lost after reboot echo nameserver 192.168.71.1 > /etc/resolv.conf Then same as on older (bookworm) Raspberry Pi OS, install openresolv (it handles access to /etc/resolv.conf 😞 apt install openresolv I can not guarantee that it all works the same in Ubuntu when netplan is active, but up to you to figure that out yourself in your network environment.

@rsbuffalo's Feb 18th post worked a treat for me on my Dragon Q6a (Armbian 26.2.1 trixie, xfce 4.20). Thanks so much for sharing your solution.

what is installed to be similar to tcpdump since tcpdump is not installed? the date is off about 11 months in the past which disables net resolution in dd-wrt. Apparently ARP is in play here, as I am seeing lots of this in a tcpdump =ieno1|grep amanda here on this machine but I see no answers: 16:42:20.926695 ARP, Request who-has amanda.coyote.den tell 0.0.0.0, length 46 16:42:20.926695 ARP, Request who-has amanda.coyote.den tell 0.0.0.0, length 46 16:42:20.926695 ARP, Request who-has amanda.coyote.den tell 0.0.0.0, length 46 16:42:20.926695 ARP, Request who-has amanda.coyote.den tell amanda.coyote.den, length 46 16:42:21.470873 ARP, Request who-has amanda.coyote.den tell amanda.coyote.den, length 46 16:42:23.288701 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:24.320147 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:25.344176 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:26.370963 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:27.392224 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:28.416249 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:29.445598 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:30.468289 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:31.488315 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:32.513828 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 16:42:33.536356 ARP, Request who-has router.coyote.den tell amanda.coyote.den, length 46 So the protocol is at least transmitting from amanda. This is evidence of dd-wrt ignoring the wrong timestamp because amanda's date is about 11 months out of sync. there is no settime installed so there's no way for be to manually fix that. I got this bit of info by commenting out the "pool" lines forcing chrony to use the "server 192.168.71.3 iburst" in the chrony subdir servers.d/ file. So I wrote another copy of the latest Armbian_26.2.1_Bananapim5_noble_current_6.18.15_xfce_desktop.img to another new 128G card, and fdisk then id's it as having an msdos partition table, skipping 8k and having a 6.4G ext4 as /dev/sdc1 and undefined for the remainder of the card. So I quit fdisk and ran gparted on /dev/sdc/ and selected data recovery. Which warned that it would take a long time, 6.5 hours later its still scanning. blue bar slowly marching back and forth in the progress line at the bottom of the gparted screen. Hopefully recovering enough data to write a valid ext4 partition table & see if /dev/sdc1 is mountable AND bootable. I have since found a cli reboot won't, but a powerdown will if the card was written with a bs=4096. That is where I am with backups of the whole houses still sitting in a /raid6 I can't rebuild w/o net access to install both gfs2 and mdadm from the repo's. So this is a trail report, not a success story. if this fails. I get a 6 pack of 32Giggers which I know WILL work with an msdos table. But that doesn't give the cards adequate room to do housekeeping meaning they will fail in less then a year. Once working I have not had a failure of a 64G card or a 128G card.

@HenricoLegal can you find the wifi chip on your board?