TRS-80

Hi,
 
I just had a brief look at the script and I'm still unfamiliar with armbian-config tools and the image building process, but I see 3 options for nand-sata-install:
GPT Capability checked against a hardcoded list of platform that supports it. GPT is preferred if available. An input/option for the script - but as to be validated with 1. The script replicates the partition table type of the running system If the sdcard images are now generated with GPT when it is supported, then I think #3 is a good option. What do you think?

Good for you, you deserve it.
 
No wonder your tone is more calm than usual. 

Good for you, you deserve it.
 
No wonder your tone is more calm than usual. 

You have to wait until Armbian adds support for RK3566/RK3568 processors, only RK3328 & RK3399 are supported at the moment since the new processors are still very new and no one has them except a few people.
They are very different from RK3399 ones used in devices like the Station P1, so won't boot.
Station P2 will get mainline Linux support so in future it should work with most Linux ARM OS's.
Yes, Armbian boots automatically from micro-sd card on Rockchip devices.

IMHO the right option is to buy technical support for your model from Armbian. You will get a ready-made, normally working system and a constant update of your devices, taking into account security and new packages. As a bonus, you will get a wide selection of different Debian\Ubuntu systems with a desktop or server versions.

Ever since I read through THIS POST a while back, I started digging through the cpufrequtils init script, and was a more or less disappointed with what I found. It's largely a product of the CPUs that were available around that time (eg - Pentium 3). Namely that all cores in the system are the same, and there's should be only one master policy that controls everything.
 
Of course ARM big.LITTLE totally breaks these assumptions, and leaves the script with no viable way to specify different schedulers or frequency ranges for each CPU cluster. It still runs, but not really correctly. For example, you can't set the RK3399 little cores above 1.4 GHz, but that's basically what it attempts to do on every boot.
 
Also it needs use "cpufreq-set" to do it's job, which seems too hard when the sysfs interface is already pretty simple. Really, that extra complexity isn't buying you a single thing. Maybe it made more sense 10-15 years ago.
 
So I took a crack at doing a far simpler, stupid version of that script (on perhaps smarter depending on perspective). It can generate it's own config, and I think that it comes across much more readable and accessible.
 
### # CPUFreq policy for CPUs: 0 1 2 3 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY0_GOVERNOR=ondemand # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 POLICY0_MIN_FREQ=408000 POLICY0_MAX_FREQ=1416000 ### # CPUFreq policy for CPUs: 4 5 # # CPU Frequency Governor # Avail: conservative ondemand userspace powersave performance schedutil POLICY4_GOVERNOR=conservative # Min/Max Frequency Selection # Avail: 408000 600000 816000 1008000 1200000 1416000 1608000 1800000 POLICY4_MIN_FREQ=408000 POLICY4_MAX_FREQ=1800000  
And using it isn't too hard ...
 
cp cpufrequtils-bl /etc/init.d/ sudo /etc/init.d/cpufrequtils-bl save sudo vi /etc/default/cpufrequtils-bl sudo systemctl disable cpufrequtils sudo systemctl enable cpufrequtils-bl  
I know that this is probably pretty far down on the list of priorities, but does anyone thing that this would be useful to others?
 
cpufrequtils-bl

I solved it by my own:
 
I had to mount the boot directory of the sd card over the boot directory of the ssd. Therefore I added two lines to the /etc/fstab of my ssd:
 
/dev/mmcblk0p1  /media/mmcboot           ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0       1
/media/mmcboot/boot  /boot           none    bind
 
(had to create the directory /media/mmcboot first)
 
Now the kernel loads in the right version. Kernel update works. Topic can be closed.
 
 
Some information:
 
root@pi-nas:~# uname -a
Linux pi-nas 5.10.34-sunxi #21.05.1 SMP Thu May 6 20:13:21 UTC 2021 armv7l GNU/Linux

root@pi-nas:~# ls /boot
armbianEnv.txt                  boot.scr.bak              System.map-5.10.34-sunxi
armbian_first_run.txt.template  config-5.10.34-sunxi      uInitrd
boot.bmp                        dtb                       uInitrd-5.10.34-sunxi
boot.cmd                        dtb-5.10.34-sunxi         vmlinuz-5.10.34-sunxi
boot.cmd.bak                    dtb-5.4.20-sunxi          zImage
boot-desktop.png                initrd.img-5.10.34-sunxi
boot.scr                        overlay-user

root@pi-nas:~# mount | grep boot
/dev/mmcblk0p1 on /media/mmcboot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,x-gvfs-hide)
/dev/mmcblk0p1 on /boot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)

I just released Armbian Focal Desktop MAINLINE images for Khadas VIM3 Pro. These are individually, pure arm64 and hybrid arm64/armhf variations.
Thanks go to @lanefu for key pointers in understanding how to "re-arm" the firstboot and firstboot-config mechanism in current-state Armbian.
 
Please offer feedback and experiences if you test these. The images are currently hand-built, but if enough interest is generated, and time permitting, I will commit to a git fork for an unsupported standard building process.
 

 
I have more detail on the distribution site at archive.org, and in the corresponding posts to the Khadas forums:
 
armhf Hybrid
LightDM will NOT work as display manager in this configuration, and I've chromed-up lxdm as a replacement. Autologin may be a work still in progress.
Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - 32-bit Userspace - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro With 32-bit Userspace  
arm64 Native
UPDATED INFO
HDMI audio out is non-functional with the 64-bit userspace, which is true for all Debian and Ubuntu systems, including Khadas Fenix builds.
This capability may be a user's deciding factor in chosing between builds.
With further testing, HDMI AUDIO NOW WORKS in arm64 image build!
Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - arm64 - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro arm64 Native  

So, here's the problem, and its resolution:
 
Comparing the decompiled DTBs for the SOPine for 21.02.1 and 21.02.3, diff gives me 
565d564 < non-removable; 600c599 < max-frequency = <0xbebc200>; --- > max-frequency = <0x8f0d180>; 681a681,682 > phys = <0x2d 0x00>; > phy-names = "usb"; 691a693,694 > phys = <0x2d 0x00>; > phy-names = "usb";  
Working through these show that only the first of these seems to make a difference. The definition for mmc@1c0f000 no longer contained the 'non-removable' entry. 
 
Therefore, inserting "non-removable;" at line 565 of sun50i-a64-sopine-baseboard.dts and compiling to /boot/dtb/allwinner/sun50i-a64-sopine-baseboard.dtb resolves this issue.
 
I can supply a patched focal image if requested.
 
 

You know, at one point I thought "maybe I should just try" (exactly as you say). 
 
I dunno, I prefer to actually try to read/research and know what I am doing beforehand as much as possible.  But I know, some times you have to just go for it.
 
EDIT:  I figured it out, simple instructions now here: ZFS "just works" now on Armbian (2 step instructions if you are thick like me)!

Following the @lanefu School of Systems Administration ("here, hold my beer!"), I decided to just give it a go.  And IT VEERRRRRKS!   
 
Here are step by step instructions for my fellow nervous, trepidatious sorts out there:
 
1. Install kernel headers.  I did this through armbian-config (Software -> Headers_install), rather than dicker around trying to figure out which exact package I needed for my board and architecture.
 
2. Issue the following command:
 
$ sudo apt -t buster-backports install zfs-dkms zfsutils-linux  
Note: I did not have to enable backports, as apparently they already are "out of the box" in Armbian; however, follow instructions at link if this is not the case for you.
 
Result:
 
 
It took "a little while" to build the module(s).  Just be patient, go grab $BEVERAGE or whatever, take a break...
 
I don't know how to express how happy I am about this.  I have wanted to do ZFS on some ARM based device for literally years now.  RK3399 was very exciting when it came out, but took years to finally get stable.
 
A special thanks to all RK3399 devs, here and elsewhere, for making this a reality.  Beers are on me if/when we ever get around to having ArmbianCon!     
 

Following the @lanefu School of Systems Administration ("here, hold my beer!"), I decided to just give it a go.  And IT VEERRRRRKS!   
 
Here are step by step instructions for my fellow nervous, trepidatious sorts out there:
 
1. Install kernel headers.  I did this through armbian-config (Software -> Headers_install), rather than dicker around trying to figure out which exact package I needed for my board and architecture.
 
2. Issue the following command:
 
$ sudo apt -t buster-backports install zfs-dkms zfsutils-linux  
Note: I did not have to enable backports, as apparently they already are "out of the box" in Armbian; however, follow instructions at link if this is not the case for you.
 
Result:
 
 
It took "a little while" to build the module(s).  Just be patient, go grab $BEVERAGE or whatever, take a break...
 
I don't know how to express how happy I am about this.  I have wanted to do ZFS on some ARM based device for literally years now.  RK3399 was very exciting when it came out, but took years to finally get stable.
 
A special thanks to all RK3399 devs, here and elsewhere, for making this a reality.  Beers are on me if/when we ever get around to having ArmbianCon!     
 

That's how it done my friend.  nice work!

I'm just starting to get into the specifics of Allwinner, so my interests in this area are limited to H6 and H5 (in the future, H616). A year ago, I was interested in the possibility of acquiring PinePhone and PinebucPro, but due to the peculiarities of delivery in my area, Pine64 politely explained that this is not possible (I have no complaints about them, this is their business, they decide how to run it).

After having the NanoPi Neo 3 in use for some time, I can say the white case shipped by FriendlyElec is a little problematic seen from the site of cooling down the CPU.
The colocation room has full AC with 15 *C room temp but under high load, the CPU temp goes up to 61-62 *C.
I think something like this might be a better choise because the air flow is much higher:
 
https://www.ebay.at/itm/333921941529
 
The producer of this case told me another case with the possibility to add a 40 cm fan gets addet soon. Might even be better!

The NanoPi R1 is running in the DC for 17 days now.
But with one port connected (GBit WAN port) its getting ~26 MBits traffic in both directions done. A little bit disappointing as i had high hopes to see another beast like the Neo 3 in it.
I will try to connect the second port and split incomming/outgoing traffic between WAN/LAN port. Maybe this gives some better results. If not, i see no reason for this one to have twice the price of the Neo 3.
We will see...

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

Suddenly it makes sense what I read in the recently published March Update: Status Report:
 
 

We can't say their motivation is bad within this move, but MS loves Linux is still a wolf disguised into a sheep. As bad intention can only be classified as a speculation and it is hard to prove they are actually doing something bad, making it possible or have a direct possibility is bad enough. If folks, one don't trust, have root and if they also control your ignition ... 

Raspberry Pi OS started to secretly (!?) adding Microsoft proprietary package base, access to their servers, by default. 
 
Security consequences? tl;dr; ... Microsoft gained root access to millions of Rpi users without their consent or awareness. From the outside. This is bad, but it is actually much worse since from the inside they already have full control of your Raspberry Pi regardless of operating system of your choice. Linux/BSD/* can't boot without proprietary Microsoft owned real time OS.
 
Most of the RPi users probably just don't care, others are naively assuming they are running FOSS software. Well, a part of it is, a part not. Not as bad as Android, but still. You can peek into the code, but at the end, Google, or lets say corpo world, is/are fully in charge of our mobile devices. Mainly with services.
 
After recent Chromium improvements, this is yet another loss for (Linux) community and FOSS in general.
 
http://techrights.org/2021/02/02/microsoft-pi/
https://en.wikipedia.org/wiki/ThreadX
https://www.infoworld.com/article/3536569/inside-microsofts-latest-os-azure-rtos.html
https://www.zdnet.com/article/linux-distributors-frustrated-by-googles-new-chromium-web-browser-restrictions/

Maybe, maybe not. If their CompaTability nonsense can simply be ignored, and the ARM cores are in control, then yes. If VC6 is running the show, it is the same. :-/

Sent from my Pixel using Tapatalk

An RPi is not

1) reliable
2) the most cost-effective
3) worth $35
4) worth any more discussion.

The position of this project stands, we will not support a failure prone, insecure, underperforming, inefficient, abysmally bandwidth throttled device. If an RPi 4 comes out that uses a sane bootloader and a useful SoC then this can be revisited.

Do not continue your personal argument with Tido; it is not value-added, and your positions add nothing other than conflict. Mostly because you have no facts or reason for your position, and instead of trying to formulate something approaching a case for support resort to ad hominem attacks and downright inaccuracies. This is an unofficial warning to stop harassing the team because you aren't getting your way. The next will be official.

Sent from my Pixel using Tapatalk

Sorry about the bad vibes.   Honestly I think we need to do a better job at lowering expectations.     RPI sets a high standard for general user experience because of the limited scope of targeted devices, volume of developers and community, and defaulting first to out-of-tree drivers, blobs, and resources via NDA's with Broadcom to ship a product that has full software functionality to accompany its hardware.

Alternative SBC vendors often create a false-promise of users having a similar experience with their product by the way marketing hardware capabilities and leaning on the reputation of RPI by selling a similar product.
 
End-result is users buy these alternative SBCs, have a terrible experience, hear Armbian is the best, come to Armbian and have better software, but Armbian still focuses on mainline, so the experience isn't that of RPI and articulating the many nuances as to WHY Armbian can't just work like the Raspian experience on RPi because challenging.    Then the fall-out ensues when newer users treat Armbian like a vendor and share their dissatisfaction that a capability for a piece of hardware they bought from someone else isn't work with community software integrated or provided by Armbian.
 
We could certainly use more tenured technical people to help articulate that message.

You are free to think and believe what you want. As is Armbian free to use or not to use if you don't want to.
There are very good reasons why Armbian does not support Raspberry Pi. There is software available for RPis, so the need for Armbian isn't big.
RPi isn't open source as the other supported SBCs.(ThreadX) 
The installed OS does not control the board. There are things happening without anyone knowing what and why.

RPi can be used for some goals. But it is too buggy to support. Undervoltages, overheating, not showing true details...

And as you say yourself, Armbian is a "community". Not a cult. We have community members, not leaders. I even think the person you talk about hasn't had anything to do with armbian for a long time. And even if I would not agree with that person. I defend his right to talk the way he feels like. 
Not everyone is always as gentle in how they talk. We are all adults, and I think we should be able to handle that. 
Go look at RPi fora and let me know what kind of talk you find their. Even having a light discussion isn't possible their. 
Greetings.

@Igor
run glmark2 on default compositor mode (auto is GLX)
we get glmark results 5-6 times lower than on xpresent mode.
 
to test it:
xfwm4 --vblank=xpresent --replace
 
to replace it by default (this will work after reboot)
xfconf-query -c xfwm4 -p /general/vblank_mode -t string -s "xpresent" --create
 
rerun glmark2... you will see the differences. 
at this point it's quite ridiculous that xfce4 compositor defaults to GLX... mesa devs hate it... his drivers too.