lanefu

I seem to be running around in circles trying to make a decision about a new SBC to add to the herd.
 
The job is currently being done by an OrangePi PC (H3, 1Gb), and is mostly about generating static web sites, which means rendering static HTML/json/js files and uploading them via SCP to a cheap shared hosting provider (the orange pi does not do the actual hosting).
 
This means daily downloading of data from the web (a few hundred MB) and crunching this data to use it for the site. Currently it downloads my country's official covid cases data and generates per-city-daily-cases-per-capita with rolling averages in HTML graphs, this allows easier comparison across time and across cities, of local covid conditions.
 
The Orange Pi PC does it fine. But then I have other projects and I'd prefer to have a separate "production" SBC, so that I can tinker more freely with the "dev SBC" without fear of breaking things. 
 
And then I think: "well, I might as well get a beefier board, you know? Future-proofing!". 
... Perhaps a beefier CPU? That octacore Nano Fire 3 looks interesting, although might be memory bottlenecked.
... Perhaps more durable storage. The USB Stick will die. My recent PC upgrade just freed a 250Gb Samsung 840 SSD that would likely last longer if used for this. (¿Hopefully trim will work through USB?). I don't really *need* USB3 but it'd be nice to get more juice from the SSD.
... Perhaps 2Gb of RAM will last longer, but then again those boards with 2Gb cost twice as much as the 1Gb boards, without bringing twice the cores nor double the MHz.
 
So I see two things:
 
First there's the cost: prices rise quickly for faster CPUs/USB3, and rather sharply with 2Gb.
 
Then, the faster chips seem to run much hotter. The NanoPi Neo 3 looks attractive at first (1 or 2 Gb, USB3) but reviews and forum posts suggest the RK3328 gets really hot even at idle, and throttles down under load/heat (perhaps failing to get the peak promised performance), with everyone adding active cooling and even huge heatsink-cases. Similar things seem to be going for the Fire 3 SBC, the H6 chip, A9....   It's like the faster SBCs gave up on passive cooling.
 
It can be hot here in the tropics: right now at noon it's 29°C, and the OPi is idle at 42°.
 
I really don't want to add active cooling. The allwinner H3 can be "slow", but they are really cool and draw so little power. Meanwhile I don't like the way my RPi3B (a home nas/minidlna) complained if anything less than 2A was fed to it. And I've seen small house Geckos warm up on the RPi, I kid you not!
 
So I end up going full circle and wondering if all I need is just another H3 OrangePi PC.
 
¿Perhaps you guys know of a "faster" SBC that draws under 1A and doesn't throttle at full load with passive cooling?

@jeyjey For supported SBCs the easiest way to get minimal or server-only images of armbian is to setup a own armbian-buil-system
on a 64bit Ubuntu or a VM:
https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
with the armbian-build-system you will have a menu driven selection if you want to create a image for the type minimal, server or desktop
you can select between ubuntu and debian flavour of armbian and the version of ubuntu or debian...as long your SBC is supported by armbian.
 

Hello.
 
@ Igor
I'm sorry if I wasted your time with my first post. That wasn't my intention. I have great respect for the work you are doing here and I am very grateful for that. I can already find out from the article that there is a problem in the kernel so far. I just wanted to confirm that my Orange Pi 3 is the same. That may have been stupid of me. I'm sorry.
 
@ Werner
Thank you for the info!
I'm switching back to a system with kernel level 5.8, and I'm waiting for development.

Thanks, this did the trick for me. A choose manually a mirror and worked.

Hi sorry for the troubles.   I've added some quick documentation on how to manually choose a mirror.   Hopefully this is an easy workaround for the short-term
 
https://docs.armbian.com/User-Guide_Fine-Tuning/#choosing-an-apt-mirror

Good evening,
 
Is it possible to "re-use" the system on SATA ? And how would I do that.
 
I use a HC4 with SD card, a SSD and a HDD 
I flashed the SD card with Armbian_20.11.1_Odroidhc4_buster_current_5.9.12.img.xz
then used armbian-config to Boot from SD - system on SATA.  (sdb2)
also I installed PiHole, OMV ...
 
Due to an power failure the HC4 was not booting anymore.
With a newly flashed SD card its booting again, but of course its not using the system on sdb2 
When using armbian-config it would erase by sdb2 before 
Could I somehow use the system which still should be on sdb2 instead of starting from beginning?
 
thanks for your help
best Regards
Igge

Unfortunately this is not working, 
I changed the rootdev UUID from the current one of mmcblk1p1 to the one of my sdb2 in /boot/armbianEnv.txt using nano.
When I reboot, board is not booting at all now.
 
I will flash the SD card again.

Hi Nico,
thanks for your help. Sorry to answer only now, I needed to wait 24 hours to be able to write again.
 
What you describe is what I did 
blkid showed for /dev/mmcblk1p1: UUID="719e2259-339c-4a64-8012-cdd30ffc7dfc"
 
This UUID was the one mentioned in /boot/armbianEnv.txt
 
And I changed it to the UUID of /dev/sdb2: UUID="bd07f3d4-1caa-443d-b91a-07e4057b41f6"
 
didnt work
 

Name pkg:
linux-image-current-sunxi64_21.02.0-trunk_arm64.deb
What kernel version does this package contain?
Name img:
Armbian_21.02.0-trunk_Orangepipc2_focal_current_5.9.14_minimal.img
In this title you can see everything.
 
I was just asking. I was hoping that someone would remember the reason why they chose this particular style of name.
These package names have been around for quite some time.
@5kft  I assume this is due to reinstalling the package to a new one.
Easy installation instead of the same name. And there is always only one core in the system.
If this is indeed the case, then the best option is to leave the naming as it exists.
For a source package, it doesn't matter.
 
Yesterday I tested the collected images of a minimal system with different cores. All images are working.
The linux-source-5.*.deb, linux-libc-dev-*.deb packages are installed and uninstalled. The problem occurred with linux-headers -*. deb.
I did a clean build on the master. Tomorrow I will watch and make a comparison.

Woohoo, seems like I am one of the winners

@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.
 
 

In the future we hope to maintain releases by branch, and only apply hot-fixes and cherry pick needed enhancements.  I think that will also minimize risk of unexpected breakages.

In the future we hope to maintain releases by branch, and only apply hot-fixes and cherry pick needed enhancements.  I think that will also minimize risk of unexpected breakages.

Blerg.  The error is telling the truth.  Most likely mirror sync.     Mirror validation is something for us to work on next.

Thanks for your response. I'm only allowed to answer after 24 hours, for some reason.
 
I disabled the log2ram but the log files are still not showing anything interesting. Crash happened on 15th of December around 16:00 and restart was around 19:50.
Here's the relevant section from /var/log/syslog:
 
/var/log/kern.log:
 
Nothing interesting found in /var/log/dmesg.
 
Do you mean connecting via COM/USB? I lose connection if it happens, but I can try.
 
 
Anything else I can do to investigate this? Do you think my device is broken?

Helios64 LAN2 is completely disable thanks to the following commit : https://github.com/armbian/build/commit/6bb68d7ff787614bf0798b2d3fad9883144a9c2d
The mainline kernel r8153 driver doesn't support the vendor ID and product ID used in Helios64, so the interface is completely disable, it's not just losing 2.5Gb speed :-(
 
We didn't see at all this commit, and personally I wasn't aware of the publication of 20.11.3 release, because most probably I'm not following the right thread. Can someone point me out what thread I'm supposed to follow before a new minor release is being pushed ?

You can use armbian-config for this. Check the Freeze option.

I've gotten my Station P1. 
It looks great. I love the metal case. 
There seems to be PCIe GPIO's. Also RTC battery. 

It is sweet. Thank you for informing me about this. 

 

Or is it the other way around?

This is an adaptation of something @SteeMan wrote in this post, but we need to refer to it often enough that I thought I would make it into a sticky.
 
Amlogic (S9xx) Android based TV Boxes

1. They are not supported.
2. A single developer (@balbes150) had worked years on getting things to the state they are.
3. As of October 14th, 2020 balbes150 removed support for Amlogic CPUs, so that is the last build that will maybe work on your box.
4. There is a very small number of people on this forum/club that are able to provide any guidance.
5. Most likely no one on this forum/club has ever seen your specific box.
6. Expectations should be set low (i.e. don't expect anything to work) but if you do get the box to boot, get HDMI and wired ethernet to work, you are doing good.
7. You really shouldn't expect things like Wi-Fi, bluetooth, remote control, etc. to work.
8. If you get this working on your box, it will likely only be useful for server type tasks, maybe a little light graphical desktop usage, but certainly not video/multimedia.
 
Other RockChip (rk3399, rk3328, rk3288) and Allwinner (H5, H6) based TV Boxes
 
9. These will continue to be supported within the limits that are possible for the equipment the devs possess.
10. They are (in fact, have always been) CSC which means Community Support only!  In other words, not officially supported by the Armbian project!
 
So, why even have these forums?
 
As a place for people to try and get together and help one another.  At least it is something.
 
Also, there used to be a lot more (better supported) activity here while balbes150 was still releasing his fork of Armbian.
 
What other options do I have?
 
I (@TRS-80) recommend cutting your losses and starting over, and this time around using the list of Armbian Supported Devices as a starting point for researching purchasing some other device.  Taking this approach will result in a much easier time, less hassle, better support, and usually for a much longer period of time (assuming things for your device get mainlined into Linux kernel).
 
Even using that list as a starting point, do your homework.  As any particular device can have some little quirks / gotcha(s).  There are a lot of resources available on the (wider Armbian) forums already, please use them!
 
@SteeMan however takes a different view.  He lay out his arguments in favor of trying anyway (see below) in spite of all the above.
 
If you choose to go that route, at least we can say we warned you now. 
 
Why is situation like this?
 
Source of following quote was Armbian official Twitter, on 2020-12-02 11:23 EST:
 
 
SteeMan also touch on this in his excellent post, below.
 
Now hopefully you at least understand why most people may not wish to spend their own valuable free time to help someone who chose an unsupported box, mostly because it was cheap (and possibly without even doing much research beforehand).  SteeMan (and a few other guys in here like jock and some others) being the rare exceptions who relish a challenge.
 
Good luck!

I fully agree with @TRS-80 comments above directing most users towards officially supported SBC hardware options.  However, I do want to add my own personal thoughts on why I choose to continue to use these Android TV boxes with unsupported armbian running on them:
 
1) It is a challenge and therefore a learning opportunity.  I would never have learnt to build my own linux kernels from source if I was still exclusively using x86 hardware.  If you want a challenge you will find it here.
 
2) Price vs specs.  The Android TV boxes are built to be cheap consumer devices.  They are produced in larger quantities which drives down the per unit price.  You will generally not be able to get the same level of hardware for the same price with a standard SBC.  But that cheapness with - no support by the manufacturers and potentially sub-standard components.  If the manufacturers goal is to sell the lowest price box they are likely cutting corners somewhere to make that happen.
 
3) emmc is standard.  TV boxes always come with internal storage while most SBCs do not.  Again from a price/performance standpoint having internal emmc storage vs running off an SD card is a plus.  emmc storage *should* be faster and longer lasting than storage on an sd card.  The caveats here being that this is one of the areas that the manufacturers may cut corners.  For example I have two TX3 mini boxes that are supposed to have 16GB of emmc memory (like the other TX3 mini boxes I have), but they were instead manufactured with cheaper nand memory for which there is no mainline kernel support.  There is no visible difference between the identically packaged boxes that had emmc vs those that came with nand, other than opening the case and looking at the physical chips on the boards.
 
4) cases come standard.  TV boxes always come with cases, whereas for SBCs that is an extra cost.  For my uses having a case is a big improvement vs not having one.  A downside if that these cases are not necessarily well designed to provide adequate cooling.  So depending on your use case, overheating might be a problem.
 
While I own both SBCs and TV boxes, I personally find the TV boxes work best for my needs (running server based software) and I enjoy the challenge of getting them running and keeping them running with the great underlying work that the armbian project is doing to build on top of.
 
I feel that if someone wants to use *unsupported* armbian on TV boxes and has the correct expectations (set your expectations low) and is looking to learn and is up for a challenge these are fun things to work with.  And I look forward to working with you on these forums.

tl;dr. The 500€ subscription has been removed. No one took the generosity challenge
 
As a replacement we added a 20€ monthly subscription to attract people who would like to give more than 5€ but 50€ would be too much.
Existing Small business subscriptions have been "upgraded" to Angel color-wise.
 

Forums, apt and downloads will be off-line for approximately 30 minutes for system maintenance.   Thanks your understanding.

Forums, apt and downloads will be off-line for approximately 30 minutes for system maintenance.   Thanks your understanding.

Forums, apt and downloads will be off-line for approximately 30 minutes for system maintenance.   Thanks your understanding.