UnixOutlaw

When did we do that the last time? Ah, that must have be Stone Age or was it already the Dark Ages?
 
That reminds me to check u-boot's algorithm to generate the MAC address based on sunxi SoC's SID to create dnsmasq entries automagically based on the SID of the board in question. 
 
BTW: One of the many Armbian advantages is the ability to deploy devices headless without crap like connecting a serial console first or fiddle around in configuration files. And static IP addresses can be assigned in a central location and not by editing text files on a bunch of devices. It's 2016 and not 1970 any more!

I was able to upgrade Armbian to 18.04 bionic beaver on my Banana Pi M1, and it's working (almost) fine!
 
I used the command to update the sources.list to bionic:
 
apt update && apt dist-upgrade -y && apt autoremove -y && apt autoclean apt install update-manager-core do-release-upgrade -d Fetched 403 MB in 8min 43s (769 kB/s)
 
I gave "yes to all" to almost everything, except on replacing config files like KEYMAP, sshd and bind
 
All these services I use are working correctly: network, SSH, bind, mail, cups, minidlna, SATA, USB printer, Samba
This is not working: qbittorrent-nox 4.0.4 (misses libboost-system)
 
Don't try to upgrade if you don't know what you are doing and if you can't handle some instability. If you managed to do a successful upgrade, post your thoughts/problems to this topic!

I downloaded 5.20 Jessie Legacy for one of my PineA64+ 2 GB the other night - dumped to SD-card - booted....  and hey presto after apt-get upgrade and reboot - using all of my 64 GB card...  automagically?  I didn't have to do anything...
 
I'm now running it "headless" as a Tomcat server running Apache Guacamole - and it's nice and quick - and I'm getting gigabit from the NIC too...
 
Thanks guys awesome job on Armbian!  Kinda wish I could run it on my RPi3 and NTC  CHIP...  Got it running on one of my Pine boards, my OPi+ 2E and BananaPI...
 
I dropped a paypal Donation in to Igor earlier today...

Hi to all! I'm just here to say thanks for your work with armbian and contribute with some wallpapers. 
 
Pd. Do you think in armbian logo redesign? 
 

Heres my try. Instead of one fixed colorset I chose some different colors too, can be used for alfa-beta-stable, release versions etc.
 

 
Recreation of Tux is under Public Commons.
 
RGB codes for different colors are included. Can be used for branding in general.
 
https://dl.dropboxusercontent.com/u/49778084/armbian.zip

Awesome - I spent the whole morning reading this thread (and it killed my morning - which is a good thing!).
 
I learned more reading this whole 4 page thread - than in five months hanging around the Pine64 forum - I call that "moderator" a couple of nasty names - Pompous Princess - or Merkin777...  Can't believe the amount of bullshit information that "A" hole has steered me wrong with!
 
Thanks for all the insiteful info from contributors on this forum and this thread!

Awesome - I spent the whole morning reading this thread (and it killed my morning - which is a good thing!).
 
I learned more reading this whole 4 page thread - than in five months hanging around the Pine64 forum - I call that "moderator" a couple of nasty names - Pompous Princess - or Merkin777...  Can't believe the amount of bullshit information that "A" hole has steered me wrong with!
 
Thanks for all the insiteful info from contributors on this forum and this thread!

Awesome - I spent the whole morning reading this thread (and it killed my morning - which is a good thing!).
 
I learned more reading this whole 4 page thread - than in five months hanging around the Pine64 forum - I call that "moderator" a couple of nasty names - Pompous Princess - or Merkin777...  Can't believe the amount of bullshit information that "A" hole has steered me wrong with!
 
Thanks for all the insiteful info from contributors on this forum and this thread!

What you're trying to achieve is possible with both Bananian and Armbian. I would still prefer the latter since development happens faster and it's more flexible (think about when you want to switch to a better platform like Marvell Armada 38x to be used as NAS)
 
Regarding backup stuff I would always rely on btrfs these days and already outlined some of the many advantages you get:
 
http://linux-sunxi.org/Sunxi_devices_as_NAS#New_opportunities_with_mainline_kernel
 
Simply forget about rsync and checksumming above the filesystem layer. Let the FS do all the work. It's 2016 and not 2006 any more

https://www.sendspace.com/filegroup/wOi2h%2FyA2aQMRnrr%2BfGNYA
 
for the png and ans files.
 
and to view it:
 
http://imgur.com/aA4LVrP
 

 
 
by me.
 
=)
 
tell me what you guys think.
 
 
 

Clearfog PRO with R1 in the back
 
After a day of playing, I am running full featured Armbian, Debian Wheezy, built with Armbian script from sources. We had to fix few things in U-boot and upgraded kernel to .82 but generally it was easy to boot the board. Of course SolidRun also provide some basic images.
 
Three(3) phys, USB and PCI is detected in kernel 3.10.82 - I don't have much hardware to plug in so I can't do much tests at this point. There is no CPU governor (yet?), so I assume it's running full speed (1.6Ghz) all the time. There are dip switches on the board to set cpu / dram speed ...
____ _ __ / ___| | ___ __ _ _ __ / _| ___ __ _ | | | |/ _ \/ _` | '__| |_ / _ \ / _` | | |___| | __/ (_| | | | _| (_) | (_| | \____|_|\___|\__,_|_| |_| \___/ \__, | |___/ Welcome to ARMBIAN (Debian wheezy 3.10.94-marvell) Last login: Sat Jan 9 10:11:28 2016 from desktop Load: 0.00, 0.01, 0.05 - Board: 64.6°C - Memory: 973Mb root@armada:~# Waiting for:
I decided to drop idea to put an AC card into the board since it's simply too problematic and expensive (66USD). This card doesn't have support in legacy kernel, in 4.4 have no idea if everything else already works + I have only one AC device in the lab. The Wireless card I choose is not fresh new but it's cheap (14USD) and reported working on Linux: Atheros AR5BXB112 AR9380 450Mbps. If I get stability and around real 300Mbps is good enough.
 
M2 drive. I'll put one 128G INSSD128GM.26M2242 TRANSCEND MTS400 128GB SSD SATA3 M.2 2242 TS128GMTS400 which should be big enough for most cases.
 
Mpci2sata for one ordinary SATA. 
 
SFP module. Haven't found the proper one yet.
 
With Armbian tools it's possible to build (I collect and fix all patches) and should be possible to boot kernel 4.3.3 and 4.4 - next.
 
Network performance (over TP link switch). 
Windows desktop -> Clearfog [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec [ 3] 0.0-10.0 sec 1.07 GBytes 922 Mbits/sec [ 3] 0.0-10.0 sec 1.09 GBytes 938 Mbits/sec Clearfog -> Windows desktop [ 4] 0.0-10.0 sec 1.04 GBytes 889 Mbits/sec [ 5] 0.0-10.0 sec 1.02 GBytes 878 Mbits/sec [ 4] 0.0-10.0 sec 1.03 GBytes 882 Mbits/sec To be continued ...
 
Edit #1: Board boots with 4.3.3 / Eth: no, USB: yes, mPci: yes
Edit #2: Jessie image download
Edit #3: Legacy kernel upgraded to 3.10.94
Edit #4: Network performance
Edit #5: If eth0 connected to gigabit, + cca. 2°C more heat on CPU in idle
Edit #6: mSATA is working with patched U-boot
Edit #7: mSATA and mPCI can be enabled in any combination. Tested one wireless card ...
Edit #8: boot time when installed to low performance 32Gb mSATA, power -> Login prompt <= 10s, (-3s waiting at u-boot) = cca. 7sec
Edit #9: I2C working out of the box. Tested with display, communication is slow. Perhaps only the settings
Edit #10: USB somehow buggy on current legacy kernel. I was trying to use Temper to collect temperature ... it worked once, next reading hang the device and I need to unplug / plug. Haven't debug. USB flash memory working normal.
Edit #11: Added cpu freq scalling 800/1600Mhz -> less heat in idle
Edit #12: Kernel 4.3.3 & 4.4 / Eth: yes, USB: yes, mPci: yes, mSata: yes ... and doing preliminary testing with Atheros AR9380 N wireless card // Kernel not ready yet
Edit:#13: Added mSATA to SATA card, patch a driver to unlock cheap - (consumer grade!, 13 USD shipped) AR9380 AR5BXB112 wireless card to operate at 5Ghz. Running STABLE
Edit:#14: Booting from m2 120G SATA drive
Edit:#15: Measuring temperature on the edge of heatsink = 39-42 while ambient is around 20.
Edit:#16: Added external 2.5 inch mechanical SATA drive powered from Clearfog +5V from header

There is a syntax for sources.list to tell which architectures to use for the repository:
deb [arch=armhf] https://dev2day.de/pms/ jessie main

Thanks! Did a purge, re-tried it and now it works flawlessly!

The fun over in pine64 forums continues: @Davey Darko also posted his experiences to the LAN/NIC thread (getting a warning via PM from this one moderator for giving him a bad reputation), the moderator deleted the post and closed the thread. So he perfectly ensures again that no progress can be made. I just wanted to post one final answer to him but since he closed the thread (his usual behaviour according to others) I document here my answer to this:
 
 
Well, again: It seems every product gets the 'supporters' it deserves -- it's fascinating that the Pine64 folks don't care at all what happens there

The out of control moderator just banned me. I PM that tllm or whatever the guys moniker is about the mods temper tantrum before I was banned. He first sent me a warning just because I gave neg rep on 3 of his posts, I hadn't even posted in that thread at that point. He does not have the temper to be a moderator on an Internet forum in my humble opinion.
 
I get better information here anyway, just like with OrangePis. Thanks Armbian!

I'm sorry... I have stop you there... I'm having trouble not bursting out laughing... nope... I did... you've just summed up what I've been shaking my head over for past few months... 
 
lol... settings matter, ignorance hurts... so true... so true... 
 
ok, that makes sense... I'd gathered from what you'd said before that cqufreq played a big part here (which is understandable in the world of ARM, since its all on the one chip, rather than across different chips like on a x86 platform...). It would be interesting to see what they stuffed up in the debian distro though that still bottlenecks the download speed to 9MB/s instead of pushing it up to the 23MB/s that armbian proves the board is easily capable of doing. Don't think I can be really bothered finding out for them since the simple solution is 'use Armbian'... it is well supported and works! 
 
So, I should add iostat 5 to my video display/log/whatever... wildo... more stats the better... harder to argue against documented empirical evidence! 
 
So the iozone results... is that indicating 32.9MB/s write and 33.8MB/s read for 4kb blocks? thus meaning there is something still blocking for network downloads (if at 23MB/s)... which seems understandable since the Pine64 didn't really seem to throttle up for that side...
 
Oh, if you want a real hoot... I initially tried the vanilla image before realising the error of my ways... and since I couldn't seem to mount the usb drive... I instead shared out a folder of the microSD... and got a whopping 3MB/s up and down... needless to say, I decided that wasn't very practical
 
btw, is the wireless module supported (yet? or likely to be?)... Or am I just a bit too slow on working out how to enable it? 

It's 'the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request' and can be used as just another indicator where bottlenecks might exist. If you deal with 'network performance' on any slow ARM board now you need to understand where the bottlenecks are.
CPU clockspeed matters, both storage and network performance depend on that therefore it's essential to have an eye on cpufreq governor used (since the wrong cpufreq governor let the CPU cores remain at low clockspeeds) some stuff is single threaded (eg. iperf/iperf3 or smbd processes) that means cpufreq governor gets even more important since the process gets bottlenecked by a single CPU core running at 480 MHz while the 3 remaining are more or less idle or do just some kernel stuff handling network and IO IRQs behaviour of some tasks depends on the distro used (see top posts here where I explained why iperf/iperf3 numbers with Xenial look better than with Debian) testing a combined workload that includes both network and IO the latter might become a bottleneck on its own (therefore storage has to be tested individually before and monitored later) So it's essential to monitor CPU clockspeed and affinity while testing (armbianmonitor and htop) but these won't tell the whole story since IO bottlenecks can also lead to low 'network performance' numbers. If htop shows an increased average load while CPU is not maxing out then this is already an indication since on Linux (unlike most if not all other Unix based OS) waiting for IO adds to average load. But using a dedicated tool like 'iostat 5' is better.
 
IO bottlenecks can be caused by hardware (using a slow disk, SD card or thumb drive) and by settings (again cpufreq stuff, IO tunables, daemon config -- the smb.conf stuff we were already talking about -- and trivial stuff like the 'wrong' filesystem: NTFS when used on Linux can be such an example, I've no idea whether similar issues might exist when sharing FAT32 or exFAT since I would always use either ext4 or btrfs when kernel version allows it)
 
Thanks for the numbers. So you got 9 MB/s SMB throughput in both directions when using Pine64's Debian Jessie and 34/23 MB/s when using Armbian's Jessie. Settings matter, ignorance hurts.
 
BTW: this whole Pain64 story is somewhat remarkable. With nearly all other SBC the story starts almost always like this: a new board will be sold and the vendor provides crappy OS images. Then community jumps in, fixes the mistakes, improves settings, things evolve (this pretty much describes how and why Armbian has been born )
 
With Pain64 it was different. Pine64 folks provided no OS images at all except Android/RemixOS but were really helpful providing docs/info regarding board and from SoC vendor. Community did all the software work in the beginning and the first OS images that appeared (longsleep's original Arch Linux and Xenial image) were in a very good state. Bugs that have been identified were fixed within hours or days, basic settings were all chosen wisely, even complicated stuff like u-boot/kernel simply upgradeable and improvements like HW accelerated video decoding were immediately made available.
 
But Pine64 folks decided for whatever reasons to not feature good OS images but to use community's work and convert it to crap. The OS images they put online did not contain the already available bug fixes or new features, they used wrong settings and added even more bugs (same MAC address on every board due to /boot/uEnvt.txt containing an address already), they did not even link to the good stuff and did everything to keep users away. And at the same time they also ensured that no progress with the various Pain64 issues could be made due to not providing a real quick start guide, no real FAQ and allowing their forum to be filled with junk and confusion. This was months ago and what now happens there (spreading even more non-sense and now also censoring) seems just entering next level.

Just a small reminder: End users should not use vanilla images on any A64 board now since expectations won't match reality (too much stuff still not working).
 
And you should also keep in mind that support for Armbian releases only happens here in the 'other boards' forum and not in Pine64 forum. For whatever reasons the Pine64 folks enabled a member of team 'Dunning-Kruger' to act there as a moderator who not only actively prevents resolving the long known GbE issue with some Pine64+ boards but who also constantly mis-uses his moderator role.
 
I added the remark 'Armbian support in Armbian forum only (possible). There no moderators are constantly deleting/editing others posts' to my last post over there: http://forum.pine64.org/showthread.php?tid=2078&pid=19019#pid19019
 
Again, the most important part of the post deleted by this person and Pine64 forum account N° 32 banned by N° 1323. It seems every product gets the 'supporters' it deserves

Well there ya go!
 
Fixed it myself...   I'd previously enabled sid and stretch repos - then commented them out.
 
Removed comments, "apt-get update", then "apt-get upgrade" - now I can install the prerequisite / dependencies!
 
-- edit --
 
Only enabled "sid" - not both stretch and sid...

Bingo.

There is no onboard battery controller or PMU on H3 based boards, compared to Pine64 or A20 based Bananas. So you will need external device to safely charge the battery, and possibly something like I2C ADC to read out battery voltage from OS.

MIPSbian ...

Seems we should stop our investigations: http://forum.pine64.org/showthread.php?tid=835&pid=19715#pid19715