TRS-80

After the better part of a year being unable to use this device, I am pleased to announce my first successful boot into Armbian.
 
   
 
 
I accomplished this by installing tow-boot to the SPI.
 
If you check their instructions for the PineBook Pro, it says to install some 'installer' version first to an SD card, and then boot that, and use it to install to the SPI chip (or other media).  I did not want to do that for a few reasons:
I don't understand why all the faffing about with an indirect installation method via SD card? I don't seem to be able to boot via SD card anyway. I am really not interested in removing all those $#%^# screws from the back case again, just so I can flip a switch, then put them all back (twice, maybe more).[0] So what I did was dig around a little more until I found this issue from last year where people were saying just to do the following, essentially:
 
dd if=Tow-boot.spi.bin of=/dev/mtd0  
So I downloaded latest release of tow-boot, which comes as an xz compressed tar archive.  After opening that up the usual way with:
 
tar -xf pine64-pinebookPro-2021.10-005.tar.xz  
Under the binaries folder I found the Tow-Boot.spi.bin file.  I copied that over to PBP and then executed the above mentioned 'dd' command (via sudo).
 
I powered off and then back on, I knew it was successful because I saw the Tow Boot logo.  So I powered off and then inserted SD card I had prepared a while back with Armbian on it.
 
And yet it still booted into Manjaro on the eMMC.  So once Manjaro finished booting, I powered back down, then back on, this time pressing <ESC> to bring up tow-boot's boot menu.  After selecting 'SD card' I was able to boot into Armbian image on the SD card, which did the normal expansion and first run setup (entering passwords, locale, etc.).
 
Now this is interesting, because I had tried to boot this very same SD card before, without any luck.  Even turning the (previously mentioned) 'eMMC switch' to both positions[0], I could never get it to work.  So maybe there is something to the 'switch is broken on the new batch' theory?
 
Anyway, I guess that's it, as I finally have Armbian running on here.  It's a minimal/CLI image, so I still have my work cut out for me getting this all set up, but hopefully I can just install my preferred desktop packages and we will see how it goes.  But that's another project for another day.
 
[0] Which involves removing quite a number of tiny little screws and removal of the entire back cover.  And then putting them all back.  In the meantime you can't really use the keyboard or anything, so you pretty much have to do the whole %&#@%# process every time.  After doing this a few times, it starts turning into a hassle.

Previous estimate I totally pulled from my rear end, because I have no idea. 
 
But sounds like maybe a little more often than I was thinking.  Probably whatever system default is doing is likely fine, unless you really know what you are doing and/or have some reason for changing it?

Are you sure you need to containerize the WireGuard installation?  Because WireGuard should basically "just work" in recent kernels...

@user-2020-12-7,
 
To be honest this has been bothering me ever since your OP.  FWIW I had put this in my own personal issue tracker to follow up on until now.
 
So when some discussion came up today in IRC about this, and another user confirm that it's working again (I specifically ask him about screen), it made me think about this again.
 
I know it's stated in other thread you linked already, but apparently there was some issue with newer kernel, and therefore PineBook A64 was rolled back to legacy (5.4.y) in the meantime, which works well enough apparently.  As I am sure you are aware by now.
 
However I realize your OP was more about the term "Supported" on the download page.  I think misunderstanding may have come from not understanding what "Supported" means in terms of Armbian, so I will try to expand a bit on what has already been written at that link.
 
Supported is a more general and longer term condition, based on a lot of factors mentioned in linked article above.  And so, just because something breaks (even something so important as display on a laptop) does not mean that device suddenly becomes "not Supported."  If situation were impossible, or constant breakage, etc. then that would be a different story.
 
So I hope I help clear that up a bit and again I thank you for your concern and your report.  Cheers!
 
I am taking the liberty to mark my own post as solution in this case.
 
 

There is https://github.com/vsergeev/python-periphery which is somehow related to https://github.com/sgjava/java-periphery, the developer of the latter (@sgjava) is regular around here and I know at least his software is actively developed.

Userland (apt, packages, etc.) is all Debian (or Ubuntu, depending on what you install).  Armbian is focused on low level stuff particular to these little boards (boot, kernel, dtb, firmware, etc.).
 
So, I imagine you would have to petition some Debian maintainer, or the ksmbd project directly?
 
I am Debian user, but still not to the point of packaging, yet.  I suppose it's only a matter of time...  But I digress.
 
Anyway, that might take a while.  In the meantime you could build it yourself, looks like...

Use regular `shasum` command (here with `--check` option):
 
$ shasum -c Armbian_20.08.1_Odroidxu4_buster_legacy_4.14.195.img.xz.sha Armbian_20.08.1_Odroidxu4_buster_legacy_4.14.195.img.xz: OK  

I think your assessment of that page is pretty spot on.  I started working on improving the docs recently, so I will add this to the list.
 
I could swear I read this somewhere before, but I will try and give a brief summary (and if nothing else, use it as genesis for improving docs):
 
Legacy is the kernel that comes from the mfr at the time the board is released.  Some times it can include certain drivers (particularly multimedia) that can make it better for certain use-cases (i.e., desktop).  Some times, with passage of time, the kernel gets older and older for various reason (some times not receiveing good ongoing support from the mfr, poor documentation so community can not write F/LOSS drivers (and thus get them into mainline kernel), etc.).
 
Current is based on current mainline kernel, and therefore includes whatever is supported in mainline.  This is best for long term support, and things which have good F/LOSS drivers (or even good docs from mfr) will often end up well supported here for a long time.  However until all that is working well there is some period of time where you might be better off on Legacy (and particularly for certain use-cases).
 
Which is better for someone's needs?  Hopefully you can appreciate it's not such a clear cut decision.  It also varies per board and over time.  Hopefully that was at least a little bit helpful, I will work on polishing that up and getting it back into the docs.
 
Whatever is on the download page for a particular device is the currently recommended kernel to use.  This is periodically re-evaluated, but basically it is the current consensus of developers what to recommend at this time.  And so, this is why Werner is recommending that one.  If they are not recommending 5.x current, there is probably some reason for that.  But you would have to go digging through some threads to find out why (FWIW, I also have an ODROID-XU4 and I am not even sure the full reasoning).  Having said that, maybe you try 5.x and it works great for you.  If so, please report back your findings.  Make sure and back up any important data (as always).
 
These Single Board Computers (SBCs) are quite a niche (and complicated) area within the broader GNU/Linux community, and a lot of what is done here at Armbian is quite cutting edge.  I really do not think you will find better support (for SBCs, at least) within the broader community.  Fact is, without Armbian, we would actually even be much worse off (if you can believe that).  I don't think it will probably ever be anything like a MacOS sort of experience, but I agree some things could surely stand improvement.  Which is why (personally) I try and contribute what and where I can.  Because I really enjoy these little devices.  There is no company, no business model, no nothing behind Armbian.  Just a handful of interested hackers and frens spread all over the world.  I'm actually amazed some times we accomplish what we already do on such limited resources.  But that is the reality (to keep things in perspective).

Ahem.  IT VEEEEEERRRRKS! 
 
In the end, I had to dd the u-boot into place (I got the location from sunxi wiki):
 
# dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8  
I got the file from https://apt.armbian.com/pool/main/l/linux-u-boot-cubietruck-current/ (of course, if you are reading later, yours may be different).
 
The advice here was very helpful.  But I still would have never got there without a little help in IRC.
 
Special thanks to @Igor, @lanefu, @TonyMac32, and @archetech, who all helped me in one way or another.  Cheers (I am actually having a cold one right now)!