guidol

new release
 
https://github.com/krachlatte/armbian-orangepi3/releases/tag/v0.07
 
please check
 
running on beelink gs1, headless
 
is v0.07 working, please send me the dmesg output after you have changed the /boot/armbianEnv.txt and verbosity=7
 
also could you send
 
tail -n 100 /var/log/syslog
ifconfig -a
ethtool eth0
lsmod
 
 
 
or if you prefer in nmtui clone mac setting ...
 
/etc/network/interfaces to set the mac adress
 
allow-hotplug eth0
iface eth0 inet dhcp
    hwaddress ether 00:11:22:33:44:00
 
 
 

Unlikely. It's a problem with their kernel. We don't use Debian kernel - it's way too old, but I will pay attentions to upstream changes in this area. 

As always the question is what you want to do with it
 
I'm typing this on a Pinebook which is fast enough for what I use it for. My Orange Pi Zero is fast enough for file and network services that I use it for. My RPi Zero is fast enough for running RISC OS. It's all down to your use case.

cnx-software-Link: https://www.cnx-software.com/2019/01/19/orange-pi-3-allwinner-h6-sbc/
 
Quote from cnx-software:
 
...but who want to use a OrangePi with a OrangePi-image?
The H6-support of armbian is very limited - so I wouldnt buy a H6-board now
 
Last year I did buy a NanoPi K1 Plus because the H5 is much better supported.
The H6 is also "only" a QuadCore A53 like the H5 - so only the newer Mali T720 GFX is the difference.
 
The OPi 3 H6 would be nice for the price if the complete hardware is supported by armbian
 
https://aliexpress.com/store/product/Orange-Pi-3-H6-1GB-LPDDR3-8GB-EMMC-Flash-Gigabyte-AP6256-Bluetooth5-0-4-USB3-0/
 
 
 
 

new release v0.05, all changes visible in github now
 
https://github.com/krachlatte/armbian-orangepi3/releases
 

it depends on the angle you look at it, it shows whether this is the first time or a regular writer in the forum. How the individual takes its measure from this information is up to the individual and shouldn't be censored ((I have to smile while writing that) I know I can look it up in his profile, but I am lazy). Other forums have that too, so we shouldn't hide it, I think.
 
 

Hi all. As regular I was looking for news about a new Odroid.
Finally the news arrived. The N2 will have the Amlogic S922X with 4xA73(@1.8Ghz) + 2xA53(@1.9Ghz), a Mali-G52 GPU and 4GB DDR4 RAM. Looks very promising. It should quite a bit faster than the RK3399's.
It does have a giant heatsink, so this thing will get very hot I suppose.
https://forum.odroid.com/viewtopic.php?f=176&t=33781&p=245930&hilit=n2#p245930
 

Please let me know what you all think of this. I find it very interesting.
Greetings, NicoD

Both pictures show the tree lines, but the Banana Pi may have not used a UTF-8 font in his terminal-window?
The tree-view is enabled/toggled in htop with the lowercase Key "t" or F5
If you leave htop with F10 the current view will be saved ( with Ctrl-C it wouldnt saved)
With the uppercase Key "S" (or F2) you could enter the Setup-Mode of htop
 
"man htop" is your friend

you could set a UTF8 language in armbian-config at the SBC-side
and in puTTY terminal you could under configurations you could also set utf8
both together should show you the right screen in htop

Type in the shell:
printf   "This is ASCII representation:\n|\n\`\n\`-\nThis is UTF-8 representation:\n\xe2\x94\x82\n\xe2\x94\x9c\n\xe2\x94\x94\xe2\x94\x80\n"
 
You should see this:
This is ASCII representation:
|
`
`-
This is UTF-8 representation:
│
├
└─
 
If you don't see the above representation, you should set UTF-8 for your language in Terminal.

Double checked, there is nothing wrong on our side. Get proper PSU and connect it properly, not on OTG port and it must work.
http://ix.io/1AuW (latest bionic image from the download page). Bananapi PRO is the same when it comes to SATA port.

Building the image was surprisingly simple and my first impression is that it works just fine. Thank you all so much!
 
I uploaded the image Armbian_5.74_Bananapim2ultra_Debian_stretch_dev_4.20.6 here, in case anyone would need it: http://www.share-online.biz/dl/YQ026FMP1LO (I hope this link is allowed; sorry, if not).

@Mario Schmidt Dont give up
The actual 4.20.6 image for the M2 Ultra does boot fine on the M2 Berry and HDMI/WiFi is working (tested console-server).
But it isnt directly downloadable at this time - you have to compile the image with the armbian-build-system:
https://docs.armbian.com/Developer-Guide_Build-Preparation/
 
A  small virtual (or real) Ubuntu-18.04-x64-Mini-Server and some commands and you are up and running for compiling the DEV-image with 4.20.6
 
login as: root root@192.168.6.20's password: ____ ____ _ __ __ ____ ____ | __ )| _ \(_) | \/ |___ \ | __ ) ___ _ __ _ __ _ _ | _ \| |_) | | | |\/| | __) | | _ \ / _ \ '__| '__| | | | | |_) | __/| | | | | |/ __/ | |_) | __/ | | | | |_| | |____/|_| |_| |_| |_|_____| |____/ \___|_| |_| \__, | |___/ Welcome to ARMBIAN 5.74 user-built Debian GNU/Linux 9 (stretch) 4.20.6-sunxi System load: 0.02 0.17 0.09 Up time: 4 min Memory usage: 6 % of 1000MB IP: 192.168.6.20 Usage of /: 7% of 15G [ General system configuration (beta): armbian-config ] Last login: Mon Feb 4 20:49:08 2019 root@bpi-m2-berry(192.168.6.20):~# uname -a Linux bpi-m2-berry 4.20.6-sunxi #5.74 SMP Mon Feb 4 16:30:46 +03 2019 armv7l GNU/Linux root@bpi-m2-berry(192.168.6.20):~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.6.20 netmask 255.255.255.0 broadcast 192.168.6.255 inet6 fe80::53:bcff:fe93:a802 prefixlen 64 scopeid 0x20<link> ether 02:53:bc:93:a8:02 txqueuelen 1000 (Ethernet) RX packets 1337 bytes 111725 (109.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 893 bytes 162240 (158.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 34 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.6.28 netmask 255.255.255.0 broadcast 192.168.6.255 inet6 fe80::b2f1:ecff:fe21:703e prefixlen 64 scopeid 0x20<link> ether b0:f1:ec:21:70:3e txqueuelen 1000 (Ethernet) RX packets 2 bytes 276 (276.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 12 bytes 1276 (1.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 top - 21:10:37 up 22 min, 3 users, load average: 0.07, 0.04, 0.03 Tasks: 110 total, 1 running, 60 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.1 us, 0.2 sy, 0.0 ni, 99.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 1024580 total, 838916 free, 73200 used, 112464 buff/cache KiB Swap: 512288 total, 512288 free, 0 used. 922740 avail Mem Here in this screenshots you will see the M2 Ultra image with some of my optical configurations - so for me its look better at the M2 Berry

https://pi-hole.net/2019/02/03/pi-hole-v4-2-available-with-shared-memory-new-blocking-modes-and-more/
 
v4.2.1 Hotfix
We have released a small hotfix which addresses possible crashes experienced for users without libcap capabilities
(running FTLDNS under root). For most users, this update will not change anything.
 
HIGHLIGHTS
 
New Blocking Mode
We’ve added a new blocking mode (NODATA), where blocked requested are replied with a status code of NOERROR
and A / AAAA records are empty.  
It’s unclear if there are advantages to this mode over others, but you’re welcome to experiment with it.
 
Shared Memory
In preparation of the new API we are working on, FTLDNS will now store its data in a shared-memory space,
so that the API can come in and read from that memory to fulfill requests.  
In short, this means FTLDNS will be even lighter as it doesn’t have to care about sending the statistics to some requester.  
Instead, it will concentrate on generating the statistics and the API can read FTL’s data directly,
resulting in reduced delays in the API.
 
wpad Vulnerability Fix
We previously mentioned how you could work around a vulnerability regarding wpad entries.  
This fix is now in place as suggested by dnsmaq.conf.example.
 
Fixes And Tweaks
We updated SQLite to 3.26.0
We fixed the query status if a forwarded query was partially replied to from the cache
We now prevent multiple static DHCP entries with same IP
And more…
 
Docker Version Also Updated
We heard your feedback and we made sure to coordinate better to release our traditional install and our Docker install together.
The docker image will be released when testing is complete.

https://pi-hole.net/2019/02/03/pi-hole-v4-2-available-with-shared-memory-new-blocking-modes-and-more/
 
v4.2.1 Hotfix
We have released a small hotfix which addresses possible crashes experienced for users without libcap capabilities
(running FTLDNS under root). For most users, this update will not change anything.
 
HIGHLIGHTS
 
New Blocking Mode
We’ve added a new blocking mode (NODATA), where blocked requested are replied with a status code of NOERROR
and A / AAAA records are empty.  
It’s unclear if there are advantages to this mode over others, but you’re welcome to experiment with it.
 
Shared Memory
In preparation of the new API we are working on, FTLDNS will now store its data in a shared-memory space,
so that the API can come in and read from that memory to fulfill requests.  
In short, this means FTLDNS will be even lighter as it doesn’t have to care about sending the statistics to some requester.  
Instead, it will concentrate on generating the statistics and the API can read FTL’s data directly,
resulting in reduced delays in the API.
 
wpad Vulnerability Fix
We previously mentioned how you could work around a vulnerability regarding wpad entries.  
This fix is now in place as suggested by dnsmaq.conf.example.
 
Fixes And Tweaks
We updated SQLite to 3.26.0
We fixed the query status if a forwarded query was partially replied to from the cache
We now prevent multiple static DHCP entries with same IP
And more…
 
Docker Version Also Updated
We heard your feedback and we made sure to coordinate better to release our traditional install and our Docker install together.
The docker image will be released when testing is complete.

I checked with the author to see if we could really increase the 80x25 terminal size. 
He said at the time he set the 80x25 limit it was due to the limited available ram of the ESP8266 devices
 
My attempts to try 80x30 was not yet successful
 
 
 
 

take a look here
 

WOW  on a OPi Plus2 H5 the time - which was displayed - was gone down from 15 to 4 Minutes with 5.73 for transfering armbian to eMMC

Just a tiny update. Booting from SSD works as expected:
 
It is not completely free of error messages, but it is quite okay'ish.
 
I will try to update my first post in order to gather the most recent information there. 

Hi Guidol ...
 
I have been doing a loooot of things as the ones you are describing for years by now.  However, things are becoming more complex and the solutions are not so crystal clear anymore.
 
When working them with the OPI-Zero, latest Armbian version (no problem in legacy ones), to remove the network managers resulted in so unstable environment that I was forced to reinstall the OS.  And ... as Armbian is oriented to NetworkManager, I preferred to learn how to work it.
 
About the R2, what happens is that it is a "work in progress" unsupported device.  So you have no guarantees about what could happen if you break something.  Also, it is more complex that other machines because it has an exotic networking equipment... in those cases, when it works it is better not to try strange things on it unless it is laboratory hardware (I have other machines for that).
 
The specified instructions work for standard Ubuntu on a very regular machine, but not necessarily will work perfectly in a constrained SBC computer where the OS has been fine-tuned to perform well.
 
---
I would prefer if Armbian let me "choose" what networking method I like to use, and in an orderly way disables all other ones.  However, I understand that such thing would involve a lot of work and it is not a priority.
 

http://wiki.banana-pi.org/Getting_Started_with_R64

...installed the JMS Firmware upgrade to be on the safe side and it seems I did not have the current version. See output of smartctl -a /dev/sdb1 below:
 
=== START OF INFORMATION SECTION === Vendor: JMicron Product: Generic Revision: 3101 Compliance: SPC-4 User Capacity: 4,000,787,030,016 bytes [4.00 TB] Logical block size: 512 bytes Physical block size: 4096 bytes LU is fully provisioned Logical Unit id: 0x3001234567891234 Serial number: 0123456789ABCDEF Device type: disk Local Time is: Tue Jan 29 11:45:38 2019 UTC SMART support is: Unavailable - device lacks SMART capability. Serial Number has changed, still no luck getting through to the HDD...
 
EDIT: solved it! 
 
smartctl -a /dev/sdb1 gives the result pf the JMicron bridge,
smartctl -a /dev/sdb1 -d sat gives the results of the HDD.

little "dumb" idea:
if the part outside the linuxfilesystem is damaged, the non-armbian-image will work because of the vfat partition which is "covering" the error.
years ago I had a old hdd which has bad sectors in the first 1GB.
after adding a 1GB partition ad the start of the hdd and using the rest as the second partition the os could be installed and used from the second partition.
Maybe @rmoriz could use the other partition style for armbian when tranfering armbian manually to emmc.

Doesn't seems to work on Pinebook with Armbian 4.20.y.
I will probably check with an Ayufan image later ...

My last update on this issue in case someone is working to get sound on A64 (>= 4.20).
I tried every patch out there,  triple checked the code , same situation, no sound. 
I must have missed something or overlooked something.
I finally tried Vasily's kernel and for my surprise no sound. Last hope, i tried Vasily ARCH img, no luck, no sound even on Pine64.
Maybe it works on Pinebook,....