As a moderator having watched this thread, I'm going to close it down, as I don't think anything else productive will be said at this point. However I do want to thank both @bedna and @eselarm for their time and effort to help. Armbian appreciates all the volunteers who make these forums possible.

And the email system for is emailing with me erroneos info about bedno report 2x a day, so call off the quard dogs, it been solved without any help from this forum. you've been yelling about dhcp w/out once offering me a single clue as to how I should configure it even when I showed you the results. FYI I have been doing odd things with little machines for a lot longer that most of you have been breathing on your own starting with an rca 1802 in 1978. Do any of you have a track record that long? That bit of production tooling for a medium market tv station was still in use 20+ times a day when the station burned to the ground in the late 90's. I prefer to call it efficiency since most production equipment at a tv station is so heavily used & long since worn out before the IRS lets them amortize the cost. I am also a CET, a test 95% of the EE's out there cannot pass. I call a backup server that draws 19 watts at full song in the middle of backing up 8 machines here, efficient. Took me a while to figure it out the hardware and around $1500 in hardware. But it works as fast as my cat6 wired local net can run.

@Nick A I tried it — I installed everything and created a secure boot image, but it doesn’t even attempt to boot from it. It just goes straight back into Android. Any idea what I might be missing?

I used it once as test. Good thing is it does verification. Hopefully that will help kill the counterfeit SD-card sales and various rubbish SD-card adapters. Bad thing (for me at least) is that there is some image caching option on by default. Good for saving excessive re-downloads, but I did not look how it works and where it is stored. I use differential backups, also via slow/expensive mobile links potentially, so don't want to wast bandwidth and volume on some cache image or chunk of data. To help people with images on this forum, I did run/boot various images as container, can be done with sudo systemd-nspawn -b -i <imagefile> (if rootfs in image is just 1 partition ) You need some working ARM64 computer of course, but that can be the old/running version of the one you want to upgrade. So I suggest you do that, or maybe the build environment cache cleaning fails (your setup). Also you involve an SD-card already. What if that card internal firmware messes up blocks. If you anyhow build image yourself, maybe use Btrfs as rootfs, also make sure U-Boot has option enabled, than you have much better ways to pin-point where the problem is. But you already did bold text for file dates I see, so I guess some caching issue somewhere.

/dev/mmcblk0p1 is a partition that contains the filesystem, not a drive. The drive is /dev/mmcblk0 and because you did a low-level sector by sector (or block by block) copy with dd, it also just has the exact same partition table (MBR-table or GPT). Now in modern Linux and various pre-installed images there are methods (possible) to expand the partition and the filesystem to occupy the whole remaining space. It is easier with MBR-table. If GPT, there is a backup GPT at the end of the disk, so in your case 64G. On the 128G SD-card the space after 64G is then hidden. I usually manage all this manually before first boot, with gdisk, not fdisk. As it is text based, it also works via remote ssh and serial console cable. I also deliberately added a dummy partition (number 3) to RPi images in the past so that the auto-expander could not claim the whole SD-card. If no GUI, a Linux install fits within a few GB, especially if you use Btrfs as filesystem for root and use on-the-fly compression (mount option compress-force=zstd). Then it is about 1GB needed, not 100x more.