Working Banana M2 Zero on HAT

[vassilis kafetzopoulos]

I am sharing images for the Banana Pi M2 Zero, slots 1 to 4, that work on top of the ClusterHAT :

Banana M2 Zero Images

They have only been tested with ClusterHAT 2.5 and usbboot is left out, so you will need to burn SD cards for normal USB boot. Serial is left out as well.

User name is "pi" and password is "clusterctrl" as with normal clusctrl images.

After logging in, you will need to manually run a command to expand the filesystem:

sudo systemctl start armbian-resize-filesystem.service

Enjoy!

On a more technical note, this is based on the armbian system, a fork of raspbian for boards with a similar form factor as the Raspberry Pi. It features a custom 5.4 kernel with dwc2 and udc-core built-in and g_ether loaded as modules.

The UDC binary was ported from the raspberry pi zero image too, and enabled as a service.

Vassilis

[Peter Cross]

I am sharing images for the Banana Pi M2 Zero, slots 1 to 4, that work on top of the ClusterHAT :

Banana M2 Zero Images

They have only been tested with ClusterHAT 2.5 and usbboot is left out, so you will need to burn SD cards for normal USB boot. Serial is left out as well.

Did you mean normal SD card boot?

User name is "pi" and password is "clusterctrl" as with normal clusctrl images.

After logging in, you will need to manually run a command to expand the filesystem:

sudo systemctl start armbian-resize-filesystem.service

After only initial first boot?

Enjoy!

On a more technical note, this is based on the armbian system, a fork of raspbian for boards with a similar form factor as the Raspberry Pi. It features a custom 5.4 kernel with dwc2 and udc-core built-in and g_ether loaded as modules.

The UDC binary was ported from the raspberry pi zero image too, and enabled as a service.

Vassilis

Cheers!

Peter J. Cross

San Antonio, TX

Saepius Exertus, Semper Fidelis

[Ciprian Manea]

Thank You Vassilis!

If the “serial is out” do we have to use the M2’s WiFi for acces/ssh-ing into it?

Great work! I’ll give a test / spin soon 🖖🏻

--


You received this message because you are subscribed to the Google Groups "ClusterHAT" group.


To unsubscribe from this group and stop receiving emails from it, send an email to clusterhat+...@googlegroups.com.


To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/a7f145f6-ffd2-4f75-820d-ed52a31229abn%40googlegroups.com.

[vassilis kafetzopoulos]

On Sunday, August 30, 2020 at 8:59:28 PM UTC+3 cipria...@gmail.com wrote:

Thank You Vassilis!

If the “serial is out” do we have to use the M2’s WiFi for acces/ssh-ing into it?

 No, it gets recognised by the controller Pi normally and gets an address from your network just as your Raspberry Zero would.

 You just cant login using the ttyp1-4.

The wireless interface is disabled, you can enable it, but that would probably mess up the default routes, so unless you know what you are doing, I would advise against it.

Additionally, Armbian normally uses NetworkManager to configure network intefaces, but I relegated that to ifupdown, so if you need to make any changes just edit /etc/network/intefaces (unlike the clusterctrl images that use dhcpcd).

Vassilis

[vassilis kafetzopoulos]

On Sunday, August 30, 2020 at 8:57:45 PM UTC+3 pjc...@gmail.com wrote:

I am sharing images for the Banana Pi M2 Zero, slots 1 to 4, that work on top of the ClusterHAT :

Banana M2 Zero Images

They have only been tested with ClusterHAT 2.5 and usbboot is left out, so you will need to burn SD cards for normal USB boot. Serial is left out as well.

Did you mean normal SD card boot?

Yeah, sorry, normal SD card boot.

User name is "pi" and password is "clusterctrl" as with normal clusctrl images.

After logging in, you will need to manually run a command to expand the filesystem:

sudo systemctl start armbian-resize-filesystem.service

After only initial first boot?

Yeah just once, it resizes your file system to fir your entire SD card and then you dont need to run it again.

[Ciprian Manea]

oh, ok

>  gets an address from your network

so the controller needs to be in cbridge mode? otherwise cnat won't get IPs from my network from the Zero's

Thanks 😊

--

You received this message because you are subscribed to the Google Groups "ClusterHAT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clusterhat+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/0120d947-4318-4142-801a-f22ff718f22cn%40googlegroups.com.

[vassilis kafetzopoulos]

Well, expect a behavior exactly like a raspberry zero when it comes to networking.

Banana pi's are configured to behave as a rpi zero would, and they should get added to the respective bridge on the controller (br0 for cbridge)

As far as the controller is concerned, thats a raspberry pi sitting there.

A cnat image should work, and so will a cbridge one.

That said, I tested it only with a cbridge image and 2 banana pi's

Vassilis

[Ciprian Manea]

for some reason for me seems to work only in cbridge mode

I'll flash tomorrow a new cnat image and test cnate mode again

Thanks! 🖖

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/4e34647e-649a-4e80-8f42-7fb9c3530d28n%40googlegroups.com.

[vassilis kafetzopoulos]

Glad it works, at least partially!

[vassilis kafetzopoulos]

Well, I figure you are right and dhcpcd has a separate profile for bridged mode (which, counterintuitively, is cnat mode)

Ifupdown that we are using has a little trouble using multiple profiles.

I dont use cnat, but that mode uses a static ip for the zero's.

If you have both cbridge and cnat images running, you can run a liitle test:

Append these lines at the end of the file /etc/network/interfaces while in cbridge and you can use the banana pi

Type:

sudo nano /etc/network/interfaces

and copy paste to the end of the file

iface usb0 inet static 

address 172.19.181.X

netmask 255.255.255.0

gateway 172.19.181.254

Substitute the "x" for the number of the slot the pi is in (1 to 4). For example, if your banana pi is in p1 slot, use address 172.19.181.1

Then boot the cnat image and check if the banana pi is recognized.

Thanks!

Vassilis

[Ciprian Manea]

Indeed, with this small IP fix the CNAT image works like magic. Thanks V 🖖

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/b59a4415-781f-4780-9d1a-c80b54cb64cen%40googlegroups.com.

[sgre...@gmail.com]

Wow, thanks so much for this!  I was hoping for a more performant "zero on the hat" kubernetes cluster, as the Pi Zeros are too limited in CPU, and you made it happen.

Cheers!

[vassilis kafetzopoulos]

Please take a look at the folder I shared, I refreshed the images.

BananaPi M2 Zero Images

It now contains a new, minimal Armbian server image with the current kernel (5.8) with GPU deactivated and some modifications for stability, performance and thermals.

CPU temp hovers around 36 degrees C with a small fan (lower than a RPi Zero).

The kernel has been stripped too (no wlan, for example) for the same reasons and to keep size small.

We now have a working serial (minicom p1 works, for example).

We also have both cbridge and cnat support.

It works out of the box, no need to resize the filesystem.

Reminder: username: pi, password: clusterctrl

Armbian has a default root account with a default password 1234 which it might ask you to change on first login, if you login via serial.

I include the modified gadget executable and build script in case anyone is curious.

Vassilis

[Stephen Greszczyszyn]

Those are some really cool improvements to the code image.  I just need to wait until my bananaPis come to test them.  Thank you for sharing!

--

You received this message because you are subscribed to the Google Groups "ClusterHAT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clusterhat+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/f42a658a-ed56-4f26-aabc-26f6863140cfn%40googlegroups.com.

[vassilis kafetzopoulos]

Hello all, i've uploaded an updated version with kernel 5.9 for BananaPi M2 Zero.

There are 3 variants: both (both cnat and cbridge), cbridge and cnat.

If you only plan to use cnat or cbridge i'd recommend using the appropriate image just to avoid the odd potential conflict, but the "both" image is tested and works just fine even in interchangeable setups.

[Samuel Montgomery-Blinn]

This is really fantastic, thank you for doing this. I was unable to even get the recent official Armbian bananapizero images to boot at all (e.g. Armbian_20.11.10, Armbian 20.11.6, tried focal, buster, bionic, etc.). I would ideally like to run the most "vanilla" Armbian possible, can you provide a bit more information on what version you started with, or did you compile from source from the beginning? I tried some simple things like enabling dwc2 and g_ether in /etc/modules but, no luck. My Raspberry Pi clusterctrl host is also running fairly 'vanilla', having only some minimal things added like clusterctrl itself, bridge networking setup. I had no issues with 4 Raspberry Pi 0 devices on there. (Other than the obvious limitation of 1-core boards, which is why I now have some Banana Pi Zero to try to work with instead.)

-Sam

[Samuel Montgomery-Blinn]

One issue after some fantastic use of these images (plenty of docker swarm and nomad/consul learning!): if I apt update and apt upgrade, a new kernel/settings is installed which prevents the bananapi0 from coming up in USB gadget mode. (ethpi1 doesn't ever re-appear on my clusterhat host). As I do not want to drift terribly far away from security patches, etc.

pi@p1:~$ sudo apt update

Get:1 ... [SNIP]

...

Fetched 12.6 MB in 9s (1,340 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
41 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Version' value from '10.6' to '10.8'

pi@p1:~$ sudo apt list --upgradable
Listing... Done
apt-transport-https/stable,stable 1.8.2.2 all [upgradable from: 1.8.2.1]
apt-utils/stable,stable 1.8.2.2 armhf [upgradable from: 1.8.2.1]
apt/stable,stable 1.8.2.2 armhf [upgradable from: 1.8.2.1]
armbian-firmware/buster 21.02.2 all [upgradable from: 20.11.0-trunk]
base-files/stable 10.3+deb10u8 armhf [upgradable from: 10.3+deb10u6]
ca-certificates/stable,stable-updates 20200601~deb10u2 all [upgradable from: 20200601~deb10u1]
device-tree-compiler/stable 1.4.7-4 armhf [upgradable from: 1.4.7-3]
distro-info-data/stable 0.41+deb10u3 all [upgradable from: 0.41+deb10u2]
file/stable 1:5.35-4+deb10u2 armhf [upgradable from: 1:5.35-4+deb10u1]
iproute2/stable 4.20.0-2+deb10u1 armhf [upgradable from: 4.20.0-2]
libapt-inst2.0/stable,stable 1.8.2.2 armhf [upgradable from: 1.8.2.1]
libapt-pkg5.0/stable,stable 1.8.2.2 armhf [upgradable from: 1.8.2.1]
libgnutls30/stable 3.6.7-4+deb10u6 armhf [upgradable from: 3.6.7-4+deb10u5]
libgssapi-krb5-2/stable,stable 1.17-3+deb10u1 armhf [upgradable from: 1.17-3]
libk5crypto3/stable,stable 1.17-3+deb10u1 armhf [upgradable from: 1.17-3]
libkrb5-3/stable,stable 1.17-3+deb10u1 armhf [upgradable from: 1.17-3]
libkrb5support0/stable,stable 1.17-3+deb10u1 armhf [upgradable from: 1.17-3]
libldap-2.4-2/stable 2.4.47+dfsg-3+deb10u5 armhf [upgradable from: 2.4.47+dfsg-3+deb10u3]
libldap-common/stable 2.4.47+dfsg-3+deb10u5 all [upgradable from: 2.4.47+dfsg-3+deb10u3]
libmagic-mgc/stable 1:5.35-4+deb10u2 armhf [upgradable from: 1:5.35-4+deb10u1]
libmagic1/stable 1:5.35-4+deb10u2 armhf [upgradable from: 1:5.35-4+deb10u1]
libp11-kit0/stable,stable 0.23.15-2+deb10u1 armhf [upgradable from: 0.23.15-2]
libpam-systemd/stable 241-7~deb10u6 armhf [upgradable from: 241-7~deb10u4]
libsqlite3-0/stable 3.27.2-3+deb10u1 armhf [upgradable from: 3.27.2-3]
libssl1.1/stable 1.1.1d-0+deb10u5 armhf [upgradable from: 1.1.1d-0+deb10u3]
libsystemd0/stable 241-7~deb10u6 armhf [upgradable from: 241-7~deb10u4]
libudev1/stable 241-7~deb10u6 armhf [upgradable from: 241-7~deb10u4]
libzstd1/stable 1.3.8+dfsg-3+deb10u1 armhf [upgradable from: 1.3.8+dfsg-3]
linux-buster-root-current-bananapim2zero/buster 21.02.2 armhf [upgradable from: 20.11.0-trunk]
linux-dtb-current-sunxi/buster 21.02.2 armhf [upgradable from: 20.11.0-trunk]
linux-image-current-sunxi/buster 21.02.2 armhf [upgradable from: 20.11.0-trunk]
linux-u-boot-bananapim2zero-current/buster 21.02.1 armhf [upgradable from: 20.11.0-trunk]
openssl/stable 1.1.1d-0+deb10u5 armhf [upgradable from: 1.1.1d-0+deb10u3]
python-apt-common/stable,stable 1.8.4.3 all [upgradable from: 1.8.4.1]
python3-apt/stable,stable 1.8.4.3 armhf [upgradable from: 1.8.4.1]
sudo/stable,stable 1.8.27-1+deb10u3 armhf [upgradable from: 1.8.27-1+deb10u2]
systemd-sysv/stable 241-7~deb10u6 armhf [upgradable from: 241-7~deb10u4]
systemd/stable 241-7~deb10u6 armhf [upgradable from: 241-7~deb10u4]
tzdata/stable,stable-updates 2021a-0+deb10u1 all [upgradable from: 2020d-0+deb10u1]
udev/stable 241-7~deb10u6 armhf [upgradable from: 241-7~deb10u4]
wireguard-tools/buster-backports,buster 1.0.20200827-1~bpo10+1 armhf [upgradable from: 1.0.20200513-1~bpo10+1]

Instead of playing whack-a-mole with various apt-mark holds, do you have some guesses/idea of which packages are over-writing things?

-Sam

[Ciprian Manea]

Or how to put back "all the things" so that after an sudo apt upgrade the M2 Zeros still work? Many thanks in advance 😊

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/65bb744c-51e5-473f-a04e-fb4e9c6ccee0n%40googlegroups.com.

[Ciprian Manea]

Would adding <this below> to your /boot/cmdline.txt and reboot fix the controller and Zeros?

 quiet init=/sbin/reconfig-clusterctrl X

where X is replaced by either cbridge, cnat, p1, p2, p3, p4 

[Samuel Montgomery-Blinn]

I will give these a try when my USB-gadget USB hub arrives so that I can type into the zero. As it turns out, there are two issues:

1. the full system update over-writing the kernel (zero doesn't come up in gadget mode)

2. when cherry-picking the updates -- I did go full whack-a-mole -- discovered an interaction between docker and wireguard-tools causing network issues (if docker is installed first) such that while the zero comes up enough for the pi host to see the usb0 device from the zero, but networking isn't established. that one I'll poke on but that's pretty straight-forward docker configuration issue.

Poking deeper, I would *really* like to see how to do thing like disable the GPU to repeat this on an Orange Pi cluster and other devices. The temperature savings are fantastic from that (and other) streamlining that Vassilis made! I have stable temperatures under load with a simple copper heatsink (thin enough to easily seat between the zeroes) and ambient airflow.

I haven't done any k8s benchmarks, because I've had such unexpectedly good performance with Docker Swarm and Nomad that I haven't wanted to rip it down. 16 cores, 2 GB ram on the hat, running great.

-Sam

[Ciprian Manea]

managed to upgrade everything to latest k3s stable and Armbian 😊

pi@c4nat:~ $ kubectl get node -o wide

NAME    STATUS   ROLES                  AGE   VERSION        INTERNAL-IP       EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION   CONTAINER-RUNTIME

c4nat   Ready    control-plane,master   81m   v1.20.2+k3s1   192.168.100.164   <none>        Raspbian GNU/Linux 10 (buster)   5.10.11-v7l+     containerd://1.4.3-k3s1

p1      Ready    <none>                 76m   v1.20.2+k3s1   172.19.181.1      <none>        Armbian 21.02.2 Buster           5.4.88-sunxi     containerd://1.4.3-k3s1

p2      Ready    <none>                 76m   v1.20.2+k3s1   172.19.181.2      <none>        Armbian 21.02.2 Buster           5.4.88-sunxi     containerd://1.4.3-k3s1

p3      Ready    <none>                 57m   v1.20.2+k3s1   172.19.181.3      <none>        Armbian 21.02.2 Buster           5.4.88-sunxi     containerd://1.4.3-k3s1

p4      Ready    <none>                 27m   v1.20.2+k3s1   172.19.181.4      <none>        Armbian 21.02.2 Buster           5.4.88-sunxi     containerd://1.4.3-k3s1

[Jonathan Padilla]

I want to write a novel here but In short, how did you manage to upgrade everything?

I went through the process to no avail.

[Ciprian Manea]

Hi,

I'm using Vassilis images mentioned at the start of this thread.

I am able to upgrade them without issues with apt/update/upgrade.

Recently I managed to upgrade k3s as well using https://rancher.com/docs/k3s/latest/en/upgrades/automated/

p3      Ready      <none>                 173d   v1.21.3+k3s1   172.19.181.3      <none>        Armbian 21.05.6 Buster           5.4.88-sunxi     containerd://1.4.8-k3s1

c4nat   Ready      control-plane,master   173d   v1.21.3+k3s1   192.168.100.164   <none>        Raspbian GNU/Linux 10 (buster)   5.10.17-v7l+     containerd://1.4.8-k3s1

p4      Ready      <none>                 173d   v1.21.3+k3s1   172.19.181.4      <none>        Armbian 21.05.6 Buster           5.4.88-sunxi     containerd://1.4.8-k3s1

 

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/32ff38aa-2546-4dce-9792-7676f997602dn%40googlegroups.com.

[Jonathan Padilla]

Yes, I am using those images.  I did   "sudo apt-get update" and then "sudo apt-get full-upgrade".  I also just tried "sudo apt-get upgrade.

Everything seems fine until the reboot happens on the Banana Pi Zero.  At that point, it is not communicating with the HAT.  I cant get access to the Banana PI Zeros anymore.

Now, I did read that section about

quiet init=/sbin/reconfig-clusterctrl X

where X is replaced by either cbridge, cnat, p1, p2, p3, p4 

but unclear of the process.  I did try it to no avail.  Do I do them one by one?  Do I put multiple lines in the cmdline.txt such as
quiet init=/sbin/reconfig-clusterctrl cbridge
quiet init=/sbin/reconfig-clusterctrl p1
quiet init=/sbin/reconfig-clusterctrl p2
quiet init=/sbin/reconfig-clusterctrl p3
quiet init=/sbin/reconfig-clusterctrl p4

OR do I need to do them one at a time?  

Thank you for replying back.

[Ciprian Manea]

Hi,

These quiet init= lines are to be prepended only for Raspbian OS

Armbian has different boot scripts than Raspbian. Just flash updated images from V and try again

To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/37f9fae0-c6d7-4a60-8ac6-2626f1d59a6cn%40googlegroups.com.

[Jonathan Padilla]

Yes, I only did quiet init= on PI 4 Controller.

I will Re-Image the Bananas and try to apt/update/upgrade again.  Thanks.

[Jonathan Padilla]

Yeah....Still same issue.  Re-Imaged Banana PI was working just fine after fresh install BUT not after apt/update/upgrade.  

I see someone else here has the same issue.  I will find a clean repeatable process to apt/update/upgrade these Bananas, seeing as just running it, vanilla, does not work.

[hanur13]

Hi, 

I use  the latest Vassilis images (cnat) for my Banana Pi M2 Zero,

For some reason I cannot ssh or connect to p1-p4 from the controller.

So I tried to take a look at the Banana manually, but I noticed from begining of this conversation that the serial is out as well as the wireless interface.

Do you know where I miss something?
FYI, I use BETA 64 bit versions of cnat for the controller.

Nurul

[hanur13]

Hello, 
For some reason cnat images didn't work for me, but worked with both cbridge and cnat support images

How I managed to ssh to p1-p4? (perhaps other have similar problem).
- I flashed on sd card for p1-p4 using both cbridge and cnat support-image from Vassilis
- I append lines (from Vassilis) at /etc/network/interfaces on each of sd card for p1-p4 

- I append lines (from C) at /boot/cmdline.txt for controller

Nurul

[hanur13]

Hello again,

I wanna ask about beginer question, is it normal if from p1 (or p2-p4) under CNAT mode we cannot  doing "sudo apt update" command for the Zeros?

pi@p1:~$ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

       valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host 

       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

    link/ether 02:42:88:a0:48:e8 brd ff:ff:ff:ff:ff:ff

3: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:22:82:ff:ff:01 brd ff:ff:ff:ff:ff:ff

    inet 172.19.181.1/24 scope global usb0:1

       valid_lft forever preferred_lft forever

    inet6 fe80::222:82ff:feff:ff01/64 scope link 

       valid_lft forever preferred_lft forever

pi@p1:~$ ip r

172.19.181.0/24 dev usb0 proto kernel scope link src 172.19.181.1 

172.19.181.0/24 via 172.19.181.254 dev usb0 metric 121 

192.168.3.0/24 via 172.19.181.254 dev usb0 

I added route 192.168.3.0/24 of my home network via controller's IP. I can ping IPs on my home network from p1 terminal but failed to "sudo apt update" .

-I noticed if after trying to install kubernates for my cluster-

My setup:

- Controller image

- Zeros image for p1

- Clusterhat v2.5

Nurul

[hanur13]

I compare /etc/network/interfaces on CNAT, CBRIDGE and Both Images for BPi M2 ZEROs below:

CBRIDGE

source /etc/network/interfaces.d/*

# Network is managed by Network manager

auto lo

iface lo inet loopback

auto usb0

allow-hotplug usb0

iface usb0 inet dhcp

up ip addr add 172.19.181.1/24 dev usb0 label usb0:1

up ip route add 172.19.181.0/24 via 172.19.181.254 dev usb0:1

down ip addr del 172.19.181.1/24 dev usb0 label usb0:1

down ip route del 172.19.181.0/24 via 172.19.181.254 dev usb0:1

iface wlan0 inet manual

iface eth0 inet manual

For CNAT

...

iface usb0 inet static

...

nb: differences in bold

***

I want to use NAT networking environment in my clusterhat.

* When I am using controller RPi CBRIDGE mode & Zero BPi CBRIDGE--> from controller I can ssh-ing inside Zero and from there I can update the Armbian (sudo apt update & sudo apt upgrade) or install any package,

* When using controller CNAT mode & zero CNAT--> from controller I cannot ping neither ssh-ing to Zero.

* When using controller CNAT mode & zero CBRIDGE, but append in last line of etc/network/interfaces below (from previous comment):

...

iface usb0 inet static 

address 172.19.181.1

netmask 255.255.255.0

gateway 172.19.181.254

--> from controller I can ssh-ing inside Zero But I cannot update the Armbian. Does anyone know how/links/hints so I can throubleshoot the problem If I want to update or install any package in Zeros ?

Thanks before
Nurul

[Travis Porter]

I know this may be necroing an old thread but has anyone gotten a stable way of setting up the banana pi's on the cluster hat 2.5? I'm having the same issue as a lot of others where they boot fine initially but any attempt to update/upgrade causes them to no be accessible (and after the upgrade no longer show boot activity light either)

[Travis Porter]

So for anyone else who finds this thread (which seems to really be the ONLY source of info using cluster & banana pi) I have narrowed the boot issues after an apt-get upgrade down to the package linux-image-current-sunxi. And possibly linux-dtb-current-sunxi but I'm not willing to risk trying it since I don't feel like having to reburn the image yet again and redo the update/reboot rigamarole.
I'll try holding both with "sudo apt-mark hold"  and update if there are any unexpected issues.

[Tony Brack]

Thank you Travis! If it helps any, I can confirm correct behavior from a base image (P3 bridged in this case)

root@p3:~# history
    1* sudo
    2  sudo apt-mark hold linux-image-current-sunxi
    3  sudo apt-mark hold linux-dtb-current-sunxi
    4  sudo apt update -y
    5  sudo apt install -y dump
    6  sudo apt install -y armbian-config

   10  sudo apt install rcs
   11  sudo apt install man groff

root@p3:~# ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

    link/ether 02:81:95:44:dd:2b brd ff:ff:ff:ff:ff:ff

3: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:22:82:ff:ff:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.223/24 brd 192.168.1.255 scope global dynamic usb0
       valid_lft 6499sec preferred_lft 6499sec
    inet6 fe80::222:82ff:feff:ff03/64 scope link
       valid_lft forever preferred_lft forever

bracka@p3:~$ history
    2  sudo passwd root
    3  sudo apt list --upgradeable > apt.list
    4  wc -l apt.list
    5  sudo apt update -y
    6  sudo apt upgrade -y
    8  sudo reboot

... and we're up and running. The next question is the effect of having these modules on hold, but at least we have a cluster client running Armbian buster. I think any further work in this area should probably go to a new thread at some point. Any thoughts of raising a web site or separate chat?