TRS-80

Looks like you asked awhile ago, hopefully this is still relevant.
 
I've been successfully running Armbian off of EMMC on my Pinebook Pro. Before installing Armbian I actually flashed Tow-boot onto the PBP's SPI (replacing the built-in boot loader). Then I was able to run the Armbian installer and installed directly to the EMMC.

This set up seems to work fine for me. Hope this helps, good luck!

You are not using Armbian.  You have downloaded software from a site that is a fork of Armbian and uses the Armbian name without permission.  They do not participate in Armbian development, nor do they participate in these forums.  We can't help you here as we don't produce the code you are running.  You need to log your question with those you downloaded your software from.

#!/bin/bash TOP=/home/share/video/music if [ -n "$1" ]; then TOP=$1 fi OLDIFS=$IFS IFS=$'\n' find $TOP -name "*.[maowf][povgklm][gvim]" -print | shuf -n 100 > randomplaylist mpv -fs -vf=pp=de --playlist=randomplaylist rm randomplaylist IFS=$OLDIFS This will play 100 randomly selected files from /home/share/video/music and subdirectories or whatever directory you pass on the command line.

Please don't take it personal.  It only takes a few people pestering, looking for (free, immediate, personalized) support to get on the nerves of some people around here.  There are very few of us, against a sea of them, so that is how we decided to deal with it, to stem the tide.
 
Further, some threads move extremely slow.  Maybe not this one, but I have seen many times where someone replies months, maybe even years later.  Different people come along, move some issue forward by inches, and on it goes.  Such is the way of progress some times.
 
Welcome to the forums.

I can only imagine how happy @rpardini will be not needing to re-base any more. 
 
Jokes aside, kudos to you, you must be thrilled all your hard work will be seeing the light of day, finally.  Thanks for sticking with it all that time.

I have been building this project for a long time.
And at the moment, I don't see an alternative for the ARM architecture for real-time core operation with short response times.
@Igor The Xenomai4 project is already working well for sunxi today.
 
 
 
lsdiff patch-6.2-rc3-rt1.patch These are some basic changes. I don't see the necessary changes specific to rockchip, meson or sunxi files here.
In order for this patch to work, you need to add a lot of additional changes yourself.
 
And this is for working only in user space.
In any case, you will have to reassemble the entire chain for industrial production. kernel -> lib & modules -> linuxcnc

Hello community,
 
I have just been successful building my own image of Ubuntu focal + preempt_rt (kernel 5.15.76-rt53) for my Rock64 board for the first time (a bit of additional background at the end of my post). Exciting! I had a few hiccups along the way, and I need to figure out a few more things. So far I'm happy and impressed with the project.
 
However, given I want to share my work (and the resulting image(s)) I would like to ask for some pointers on what is the best way to go in regards of forking armbian/build and the changes I found myself doing.
 
I have added my kernel compilation flags to config/kernel/linux-rockchip64-current.config but I feel like maybe I should create a new file, something like 'linux-rockchip64-current-rt.config' but I do not know if the compile.sh will find it (or how to make it find it) if I do so. What would be the best way to go about it? I added the PREEMPT_RT patches to patch/kernel/rockchip64-current , but again, there should probably be a folder for RT maybe? (I wonder how to make compile.sh find it). I created userpatches/lib.config with the content 'KERNELBRANCH='tag:v5.15.76'' to use the latest PREEMPT_RT compatible kernel, ideally this could be scripted to use the latest closest to 'current', which also would avoid needing to modify the patch/kernel/BOARD_NAME folder. I also needed to remove the box64 package cause it would stop building my image (GPG key outdated?) is this package necessary for a minimal installation? I don't think I found I needed it so far. I left a comment about it in this github issue: https://github.com/armbian/build/issues/3968#issuecomment-1310390875 I needed to add a couple of additional cmdline flags, I edited by hand (after booting the board) the resulting /boot/armbianEnv.txt with 'extraargs=nohz_full=3 isolcpus=3' and that worked, but I'd like to create the image with that already done. What would be the best place to do that? userpatches/customize-image.sh ? If I place anything in userpatches/customize-image.sh am I able to run the build just from there?  
Thank you very much for any pointers you can give me about best practices to go about it, anything I did wrong, or templates to follow.
 
My first goal is to provide a reproducible build of ubuntu focal + preempt_rt for the rock64 board (which I'm very close!), but I'd be happy to extend the work to be able to apply the PREEMPT_RT patches to any board saving people a bit of the guess work I needed to do (at least for as long the patches are not part of the kernel by default!).
 
Additional background: I need to use Ubuntu as my plan is to use ROS 2 on it, and the officially supported distro is Ubuntu (and focal happens to be the most useful for my use-case). I am aiming, in conjunction with some members of the ROS real-time working group, to ease the entry barrier of learning to make real-time apps for robotics. I am using a Rock64 board because it's similar to a Raspberry Pi 4, as I am unable to source a Raspi4 and I believe it is the same for everyone.
 
Bonus: a quick test (running 10min) of cyclictest with stress on the system provided the following plot on latency (74us max, 15us min, about 20ish us average):

 
 

Since I've no slides, a terrible sense of humor, and nothing else to post, here's a git shortlog of the changes since last week.
 
Ricardo Pardini <ricardo@pardini.net> (99): armbian-next: `CLEAN_LEVEL=make-kernel` now does `git clean -xfd` instead, faster and 100% clean armbian-next: better logging for early apt installs during `prepare_host_basic()` armbian-oleg: handle error during host deps installation (Oleg has a mangled sources.list?) armbian-oleg: introduce `DOCKER_SIMULATE_CLEAN=yes` so I can pretend to be Oleg, but using Docker armbian-oleg: split hostdeps again, full of ifs, and reduce the minimum set of pkgs for Oleg-conditions while trying to keep Docker full armbian-next: `apt-cacher-ng` is now optional and activated via `MANAGE_ACNG=yes`; drop `NO_APT_CACHER` armbian-next: remove old template Dockerfile, -next does not use this at all armbian-oleg: `junk`: drastically reduce host-side dependencies / "remove junk" armbian-next: curb down wget logging for ORAS tooling download armbian-next: curb down `git fetch` logging; be verbose if user on terminal & not logging armbian-next: curb `aria2c`'s complaining a bit armbian-next: curb `free_loop_device_retried()`'s logging on first try armbian-next: long overdue split of `logging.sh` armbian-oleg: logging: new logfile format; `SHOW_LOG=yes` default; introduce `DEBUG=yes` armbian-next: fix quoting of retry var (cosmetic) armbian-oleg: better logs; only include non-empty .log files armbian-oleg: curb `apt-get`'s logging with `-q` / `-qq` armbian-oleg: curb Python launcher logs armbian-oleg: curb `rsync` logging during bsp armbian-oleg: drastically curb `update-initramfs` logging, unless SHOW_DEBUG=yes armbian-oleg: drastically curb `boot_logo()` logging armbian-oleg: drastically curb `apt-get` logging when running in chroot armbian-oleg: make `chroot_sdcard_apt_get_install_dry_run()` logging more useful by filtering the noise out armbian-oleg: if commands fail, write to log in bright red armbian-next: split `compilation/debs.sh`; `compile_xilinx_bootgen()` moved to family armbian-oleg: curb logging from building `armbian-firmware` armbian-oleg: curb logging from building `armbian-plymouth-theme`; do it in a logging section, like the others armbian-next: logging: reinit logging after processing cmdline parameters armbian-next: cli: half-assed, legacy based, `kernel` and `u-boot` cli commands armbian-next: `odroidxu4` vs kernel: move firmware hack to family using extension hook armbian-oleg: logging: drastically curb / make more useful kernel packaging logging armbian-oleg: logging: disable debugging (set -x) of generated postinst/etc kernel scripts (board-side, but also chroot logging) armbian-next: kernel: deterministic `.config` mtime handling; kernel build logging sections reorg armbian-next: remove `REPO_STORAGE` and `REPO_CONFIG` -- unused armbian-next: consider "Provided" installed packages when determining what is missing from host-side dependencies armbian-next: completely remove `acl` (which provided `getfacl`) and it's usages (basic deps) armbian-next: don't copy the host's `keyrings` to image armbian-next: Python tooling: use consolidated+hashed+cached pip base/pycache; don't pip during Dockerfile build, nor cli-requirements armbian-next: add core extension `c-plus-plus-compiler` which hostdeps on `g++-aarch64-linux-gnu` and enable it in JetHub family armbian-next: core extensions for `xfs` / `f2fs` / `brtfs` / `LUKS/cryptroot` hostdeps; enable in main-config armbian-next: Docker: abstract away and only run "docker info" once, it's very expensive armbian-next: `rootfs`: bunch'o'fixes, introduce `disable_systemd_service_sdcard()` to stop repeating incantantion armbian-next: don't warn about using extlinux armbian-next: a bunch of checks for Darwin; use brew's GNU coreutils first in PATH, so we get the correct utils; give instructions armbian-next: better logging for `kernel_prepare_bare_repo_from_oras_gitball()`; remove dead code armbian-next: fix re-launching of CLI commands under sudo (Docker was ok) armbian-next: `patching`: don't complain about missing files when the patch parsed OK and file was actually deleted armbian-next: `patching`: don't rewrite empty desc as "None" armbian-next: `patching`: remove quotes from author name during parsing armbian-next: `patching`: avoid mangling valid utf-8 from mbox'es armbian-next: `patching`: parse renamed source files, don't swallow them during rewrite armbian-next: optimize `config_source_board_file()`, now 600x faster by not reusing (slow) code from interactive armbian-next: optimize for `CONFIG_DEFS_ONLY=yes`, skipping stacktraces/git info armbian-next: introduce `POOR_MAN_PROFILER=yes` (under `ANSI_COLOR=none`) armbian-next: `docker`: fix Dockerfile output indentation & warning msgs about generation armbian-next: make sure temporary `kernel` and `u-boot` CLI commands always build a kernel/u-boot even if cached `risc-v`: correctly include `debian-ports-archive-keyring` in Risc-V CLI packages `risc-v`/`starfive`: use mainline kernel 6.1.y, with StarFive's rebased patches against `v6.1.5` `risc-v`/`starfive`: update kernel config, sans changes `risc-v`/`starfive`: `CONFIG_MOTORCOMM_PHY=m` for the onboard Ethernet `risc-v`/`starfive`: switch kernel config to `savedefconfig`'s output, cos that's what it should be `odroidm1`: enable working userland `fw_setenv`, so users can go back to Petitboot & otherwise tweak u-boot env from Armbian `odroidm1`: bump to 6.2-rc3; look ma, no patches. `odroidhc4`: pre-configure `fancontrol` so fans work right out of the box armbian-next: debug note about fstab with tmpfs in chroot armbian-next: mark Vagrant CLI as unimplemented armbian-next: `docker`: use dash-lines before/after launching docker; set `ARMBIAN_INSIDE_DOCKERFILE_BUILD=yes` when it is so armbian-next: `traps`: allow for cleanup handlers with arguments; unify around `run_one_cleanup_handler()` armbian-next: `ccache`: show more in ccache debugging armbian-next: make superglobals readonly (`DEST/WORKDIR/LOGDIR/SDCARD/MOUNT` and others) armbian-next: introduce `tmpfs-utils.sh`; put `LOGDIR` and `WORKDIR` under tmpfs; set `CCACHE_TEMPDIR` under `WORKDIR` armbian-next: split `prepare_host()`, fix `.tmp` reset trap armbian-next: do basic host checks before config if interactive, or during prepare-host if not armbian-next: tmpfs-utils: last-resort debugging, to stderr, of failed tmpfs unmount armbian-next: logging: squash nasty leaking file descriptor bug due to "tee" armbian-next: bring back `swig` hostdep -- needed for some u-boot's armbian-next: severe bug, countdown counted up armbian-next: kernel: cleanup bundle after patching succeeded, not after build success armbian-next: firmware: don't build `-full` firmware if not on CI/noninteractive and board's not going to use it armbian-next: `chroot_sdcard_apt_get_update()` to replace and better log `chroot_sdcard_apt_get update` armbian-next: extensions: rename `kernel-localmodconfig` to just `lsmod` armbian-next: docker: remove old code armbian-next: try harder to get `en_US.UTF-8` logging armbian-next: drop dead/duplicated code for bootsplash and mark kernel-drivers.sh (which includes bootsplash) as dead code armbian-next: extract `move_images_to_final_destination()` and optimize for fast-move when src/dst on same filesystem armbian-next: tune logging: unmounting, u-boot prep/source/install; traps; extensions armbian-next: don't leak `.raw` image if failure before move; show rootfs-tmpfs info armbian-next: `mktemp` and `tmpfs` related utility functions with automatic cleanup handlers armbian-next: small cleanups: squash typos / add function keyword / add types / mark dead code armbian-next: small cleanups: squash typos / add function keyword / add types / mark dead code armbian-next: add logging with size of actual built rootfs in MiB; debug tmpfs in trap & after pkgs done armbian-next: still fighting `tee` leaking under duress, and I think I won armbian-next: `compile_firmware()`: use new temp dir helpers (saves 2Gb+ in WORKDIR), fix typos armbian-next: severe bug, there was no prefix-emoji for Windows armbian-next: allow shortcut `EXT=` to the overly-long and plural `ENABLE_EXTENSIONS=` armbian-next: use retries for downloading ORAS tooling WiP: aggregation.py vs create-cache.sh: better hashing, much desktop WiP: patching.py vs decent logging: better, but not there yet ------------------------ armbian-next END marker ----------------------------- Richard Neese <r.neese@gmail.com> (1): `risc-v`: switch from `grub` to `extlinux`; add Debian Ports keyring hostdep to strap Debian riscv64 from ports Tony <tonymckahan@gmail.com> (1): armbian-next: officially support WSL2; pester user for UTF-8 terminal  

That was very infomative.
Can't add much to the discussion. I agree that forum used to be a lot better and more important. Because of the use of Discord, irc, Jira... there is more fragmentation.

We used to use the forum also to chat between devs/users/mederators. Now that is done on discord, irc or github. So the fun is out of the forum.
Nothing of what is said on discord is of value in the future. While what is said on the forum keeps its value and is easy to find.

Github is good for bugreports and discussion on how to go ahead. But it is a developers tool and not for regular users.
Discord is good to chat. It added features we didn't have on the forum like being able to do voice chats or video chat. But it takes away the focus from the forum for many.

I don't check the forum as much as I used to. Only see if there is anything interesting in the notifications. But I miss a lot because I'm not present as much. And what happens on the forum isn't communicated much about on discord.

Maybe a discord/irc room where forum posts can be seen. Just the titles would be enough to sparkle curiosity.

For me there is too much to have to keep up with. I've got my YT channel, reddit, facebook groups, forum, discord, twitter, ...
Quality decreases when too much is going on. Nobody can keep up with it maybe except Igor. (he seems to see it al )

Watched at 1.25x.

Added alpha version of image build support for RISC-V.
So far, this is an early version and some of the functions do not work in it.
Currently, support has been added for the StarFive model.
 
https://rvspace.org/
 
Details can be seen in this topic.
 
https://forum.rvspace.org/t/armbian-for-starfive-build-system-ubuntu-debian/468
 
 
Added support for Nezha D1 and Lichee RV (Dock) with Allwinner D1 RISC-V chip. To start the system. Download the image, unpack it, burn it to the SD card.  Connect the SD card to the device and turn on the power. Further steps for initial setup are similar for all Armbian systems.
 
For the Nezha D1 model, HDMI, LAN, USB, analog audio via 3.5 jack works.
For Lichee RV Dock  works HDMI WiFi USB USB-LAN
 
Link to download images.
https://disk.yandex.ru/d/da8qJ8wyE1hhcQ
 
https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/
 
forum MangoPI
https://forum.mangopi.org/

Hi,
 
I'm a SW developer with experience in:
linux, bash, systemd java, c, c++, python, spring-boot, spring-data, jpa openapi Virtualbox, Vagrant cryptography: openssl, X509, publik-key (rsa, ec) IAM: keycloak, spring security, JWT, spring cloud  
I would like to help.
 
BR,
Sandor
 

Hello,
I would like to help out. I have never been involved in open source community and this has been a dream of mine to collaborate.
 
Little bit about me.
1. I have 3 years of working in Yocto projects. During this time I have supported and developed on NXP chips and Raspberry pi.
2. I have written device side divers for them.
3. I have a masters in Electrical engineering and have been working in embedded Industry for 6 years.
4. I have a very good understanding of the Linux system been working and supporting one for more than 4 years.
5. And I am not afraid of VIM (I have a list of cheat sheets in front of my desk )
 
I am more comfortable in supporting and collaborating for Linux but open to learn and help in whatever way I can
 
Thanks
 
 
 
 

Nice chart!  So nice, in fact, that I will spare you the rms sermon. 
 

For background, this is part of our project to bring an Armbian-based TV Box to market.  See our home page at https://www.inovato.com.

For anyone wanting to build from mainline, we have posted an article with our patches.  These include AC200 Ethernet and XR819 wifi support in kernel 5.15.y.  For edge builds, AC200 Ethernet is supported.  To support the XR819, we'll have to create more patches for the changes in kernel 5.19.  The link is https://www.inovato.com/article/building-armbian.

NVMe cannot be booted. (It cannot contain u-boot or tow-boot or ANY boot code.) It's not in the boot path.
 
See the Pine64 wiki at https://wiki.pine64.org/index.php/Pinebook_Pro#Using_as_OS_root_drive
 
The SoC does not include the NVMe boot code, so the NVMe is not in the SoC's boot order. However, using the U-Boot update script from the mrfixit2001 Debian or Arglebargle's modified script, and the modified u-boot images provided by forum user pcm720, you can now add support to boot from an NVMe drive.
 
and quoted from https://wiki.pine64.org/index.php/Pinebook_Pro#Boot_devices
 
Please note that PCIe, the interface used for NVMe SSD on the Pinebook Pro, is not bootable on the RK3399 and therefore is not a part of the boot hierarchy. It is possible to run the desired OS from NVMe by pointing extlinux on the eMMC to rootfs on the SSD. This requires uboot, the Kernel image, DTB, and extlinux.conf in a /boot partition on the eMMC.
 
Also, wherever you put this boot code, the target kernel and /boot files must support it too and the subsequent boot priority that it provides is at the whim and discretion of its author!
 
So, if you want to ditch both eMMC and SD memory as part of the boot chain and boot a system on NVMe (/ and boot), you must use SPI. Sadly, it might not work for all operating systems due to bugs or lack of kernel support:
 
https://wiki.pine64.org/index.php/Pinebook_Pro#Using_the_SPI_flash_device
 
Here is some information on using the SPI flash device:
You need the kernel built with SPI flash device support, which will supply a device similar to: code>/dev/mtd0
 
Unfortunately, at this time, Armbian seems to have problems when the Armbian system resides on media other than the SD card! I don't know if the problem occurs when Armbian relies on a non-Armbian u-boot (eMMC u-boot) and/or even if the Armbian supplied u-boot doesn't work when it and the Armbian system are flashed to eMMC.
 
I also don't know if Armbian would work with u-boot or tow-boot or something else flashed to the SPI NOR memory. My guess is it's a poor wager!
 
I think I might try to copy the Armbian / system (copy files--not an image) from my Armbian SD card to my eMMC (or maybe try using my NVMe SSD too, which has been proven to be accessible when booting Armbian from the SD card). The Armbian /boot files don't look anything like the /boot files I've seen in other distros. I have "armbianENV.txt":
 
verbosity=1 bootlogo=true extraargs=systemd.unified_cgroup_hierarchy=0 overlay_prefix=rockchip fdtfile=rockchip/rk3399-pinebook-pro.dtb rootdev=UUID=f57dd6bf-3737-40f9-95b0-376895bc2055 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u  
I wonder if it (the Armbian SD card /boot code) would load and run the system from eMMC or NVMe, if I simply change the rootdev=UUID entry to match the desired target. (and also change the fstab entry in the target).
 
Again, I don't know how this file works. What does "usbstoragequirks" do? That's a scary label!
 
The Slackware PBP aarch64 distro only supports booting a system on NVMe from an SD card. (Slackware devs don't even officially support eMMC, which they freely admit they don't trust as reliable hardware, because it's cheap NAND memory.)  This usage model would be fine with me with my Armbian system! Once booted, the SD card can be unmounted and removed.

I might find time to work on this. I'm loving my latest SD install of Armbian Jammy KDE Fusion and I'd like to copy it from my SD card to on my PBP NVMe drive (or at least my eMMC). I've done this sort of thing with my PBP in the past and even had Manjaro running with / and /boot on my NVMe drive. I also wrote a crude dual boot script to toggle the boot between systems on NVMe and eMMC.
 
I installed PCM720's Uboot code but stopped short of risking its install to SPI.
 
I've always had strange boot problems from time to time with my PBP though. When I had Manjaro installed to NVMe (/boot and /), I had two occasions when a Manjaro apt-get upgrade killed the boot with the system entirely on NVMe. Luckily I had backups. I think both boot failures happened when a kernel update was included in the upgrade. Stritt (Manjaro forum mod) and I never got to the bottom of it though. Once I recovered the system by building a new kernel package from source and installing it to the broken system. Then it worked from NVMe again so I came to the conclusion that it wasn't actually a kernel change that caused it but, rather, something else associated with it.
 
Here's the PCM720 thread and one of my posts. PCM720 provides links to his code earlier in the thread. It's difficult to find his most recent code so I'll try to find it and provide a link here.
https://forum.pine64.org/showthread.php?tid=8439&page=13
 
I don't post on the Pine64 forum anymore though. Pine64 forum mod, Arwen, was far too aggressive in the censorship of posts right after COVID broke. Geesh--II was a DivX forum mod for years back when it was a nearly unique and very popular forum (as was doom9 :))  and, I never needed to censored anyone--especially for a general off-hand comment that wasn't even directly associated with an event like COVID.

Yep, by now they are available in the store!
 
Too bad I had to move and been spending money like a drunken sailor buying things for the new place.  I might not have enough left now for a PBP. 

Sorry for again disappearing.  It took up much more time and energy than I thought to find a new place (very tough market here) and get moved.
 
On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)!
 
Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now!
 
 

Sorry for again disappearing.  It took up much more time and energy than I thought to find a new place (very tough market here) and get moved.
 
On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)!
 
Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now!
 
 

So I have this working on bullseye by using the Armbian edge kernel (linux-image-edge-meson64, 5.17.5-meson64 in my case) with zfs from bullseye-backports. The important part was the new kernel headers I think, as the previous kernel (linux-image-current-meson64, 5.10.123-meson64) appears to be missing module.lds needed to build any out of tree module. I think the same problem would occur with jammy because the kernel package is the same.
 
This looks like it was fixed in January 2021 in https://github.com/armbian/build/pull/2545, but meson64 still has an unfixed 5.10 kernel as current in 22.05.3, while some other boards have 5.15 (and some have earlier versions) which has the fix, and so does the meson64 edge kernel 5.17.5.

Who's that weird guy in the woods

Sorry for again disappearing.  It took up much more time and energy than I thought to find a new place (very tough market here) and get moved.
 
On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)!
 
Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now!
 
 

It has been diabolically difficult to identify this issue.   Good news is that it is not a build issue, and it's not a reversion of the lan0 bug.   I have flashed around 100 images and done countless power-downs and reboots.  Each time I thought that I was making progress, more testing disproved it.    The initial workaround did seem to resolve the issues, but they still occur if enough reboots are done.   Even older builds have the issue if enough reboots are done.  It seems that newer builds are just more sensitive to the issue.

At one point I thought that there were two different issues for Debian and Ubuntu builds because the fixes were different, but more testing proved that the fixes didn't stick permanently.  Symptoms are also variable, from the more common intermittent drop-outs and slow-downs to the less common total loss of lan0 NIC or total loss of networking. 
 
In my environment, the issues can be completely eliminated by disabling IPv6.  Using armbian-config to do this does not work!  
The armbian-config method adds lines to /etc/sysctl.conf but unfortunately this does not disable IPv6.
Ipv6 must be disabled by adding extraargs="ipv6.disable=1" to armbianEnv.txt.

The cause seems like it might be related to the resolvconf-pull-resolved.service and NetworkManager and RTL8153B, and is intermittent, but once it has stopped working correctly, it is problematic to get it working again without a power-down (on Ubuntu, apt-get --reinstall install resolvconf then reboot fixes it temporarily). 

I suspect that my IPv4 NAT environment is sometimes confusing resolvconf or some other networking component on this board and leaving somethings in networking in a corrupt state.  I don't have the same issue with my H5 and H3 boards.

I will change the work-around instructions to reflect my findings.

I have been wanting to buy one for what seems like months (a year?) now and they have not been able to do a production run due to the supply chain shortages (mainly screens, apparently).  I follow them pretty closely, there was some hope maybe after CNY 2022 but then they announced no they could not source screens after all.
 
So your information is really timely @hexdump, thanks a lot for that.