guidol

v5.90 / 7.7.2019
All images were updated. It mainly goes for a bugfix update, cleanup, adding Debian Buster release. Beware that software maturity with Buster is not just there yet (even it was declared stable) and with some applications (like OMV) you will encounter problems. Kernel/BSP wise, Debian Buster is the same, uses Armbian kernel, as our other builds. Most of the builds were briefly tested, but bugs might be hiding somewhere. This is the best what is out there thanks to greater Debian community, those around boards and of course ours which pushes generic Debian/Linux to the sky . Enjoy the summer time.
 
What's new? -> https://docs.armbian.com/Release_Changelog/

It seems it have been added during April for a specific NanoPi which has this RTC onboard, but by mistake, it has been added to all NanoPi !
We will probably fix that soon ...

https://github.com/armbian/build/commit/76ac54aae381714cee7bf1b03d4bce097b1630de
root@orangepizeroplus2:~# uname -a Linux orangepizeroplus2 5.1.15-sunxi64 #5.90 SMP Thu Jul 4 21:07:22 CEST 2019 aarch64 GNU/Linux root@orangepizeroplus2:~# cat /sys/class/thermal/thermal_zone0/temp 58191  

Hi @Igor, @guidol - in case it is helpful, I took a quick look at this and the fix is pretty straightforward.  Essentially all that needs to be done is to remove the existing "patch/kernel/sunxi-dev/ths-29-sun4i-gpadc-iio-add-h5-thermal-zone.patch" for 5.1, and to port over the 4.19 "patch/kernel/sunxi-next/ths-29-add-correct-h5-thermal-zone.patch" to 5.1 (i.e., bring into "patch/kernel/sunxi-dev/").  The problem is the currently the thermal-zone is defined in the wrong DT location, and the zone definition and tips  and cooling maps are incorrect/incomplete for the 5.1 version.
 
I did a quick test of fixing it this way and the result works:
root@nanopineo2:~# cat /proc/version Linux version 5.1.15-sunxi64 (root@elrond) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.90.190705 SMP Thu Jul 4 14:05:17 UTC 2019 root@nanopineo2:~# cat /sys/class/thermal/thermal_zone0/temp 40936 root@nanopineo2:~# I'd fix this and submit the change myself, but unfortunately I don't have time to be thorough about testing it right now (e.g., verify on some H3 boards and other H5 boards as well), and likely won't be able to until next week...I'm happy to do this then if you don't have time to look into this.

I can confirm that I also have this issue on my Orange Pi Prime (H5).

Thanks! Then there seems to be some thermal_zones mismatch ... needs closer inspection. Can't tell where exactly is the problem and which fix/workaround is best. H5 boars are affected, right? Hope to check this during a week, currently deep in fixing mvebu and imx6 stuff.
 

That's normal. lm-sensors are not reading values at the right place or we all have it on the wrong spot.

@kamma @martinayotte @Igor Thanks - was a nice teamwork

@lanefu
 
Thanks a lot. It worked.

I tried again today (without changing anything) and it worked, I access it now with putty, overwrote the eMMC with the latest version and start again installing everything

we will see how long it does work after a reboot

when you did try different boards - did you also try all of the !three! usb-ports on every board?
specially the single one on the other side of the eth0-port? Because in you first dmesg the USB-Ethernet adapter was recognized as eth1 and then renamed.
And this renamed name wouldnt go in every situation automatically up for ifconfig.
 
So check the other usb-ports and when you will see enx00e04c680046 in dmesg get him up with
ifconfig enx00e04c680046 up
and then he would be displayed in
ifconfig
 
when the port is down (not automatically up or no cable/link connected the interface is in down state) then it wouldnt displayed by
ifconfig
 
The part after enx is the MAC-address of your USB3.0 Ethernet-adapter.
 
I got this model running on my devices without special power supply and from my personal view there is no driver problem with armbian and this device.

in his first dmesg it was recognized:
 
388 [ 5.571663] usbcore: registered new interface driver r8152 413 [ 5.906764] r8152 4-1:1.0 eth1: v1.09.9 414 [ 6.188868] EXT4-fs (zram0): mounted filesystem without journal. Opts: discard 415 [ 6.552250] r8152 4-1:1.0 enx00e04c680046: renamed from eth1 but not in the second one.
@cam2019 did you use another USB-Port? Maybe that has to be enabled in armbian-config -> system -> hardware ?

- added support for V3
- included latest upstream changes
- updated repository

a good start - I think - would be the NanoPi K1 Plus
https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=220
 
has
- 64bit SoC (well supported H5-CPU - also cool running)
- 2GB of RAM
- WiFi
- HDMI (but no 4K)
 
 
Wth 1GB of RAM there is also the OrangePi PC2 - but no WiFi
 

Thanks @guidol, i solved this issue.
 
Apparently for some unknown reason the sdcard bood image was corrupted.
I reflashed it with the latest armbian and the boot log now is as expected.
 
Cheers

First, install the DT compiler : http://ftp.debian.org/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.7-3_arm64.deb
Next, copy the /boot/dtb/allwinner/sun50i-h6-orangepi-one-plus.dtb into /boot/dtb/allwinner/sun50i-h6-orangepi-one-plus.dtb-ORIG as backup.
Third, decompile it into DTS :
dtc -@ -I dtb -O dts -o /root/sun50i-h6-orangepi-one-plus.dts-5.1.0 /boot/dtb/allwinner/sun50i-h6-orangepi-one-plus.dtb Fourth, edit the file /root/sun50i-h6-orangepi-one-plus.dts-5.1.0 by adding this in the aliases node :  ethernet0 = "/soc/ethernet@5020000";
Fifth, recompile the DTB and reboot :
dtc -@ -I dts -O dtb -o /boot/dtb/allwinner/sun50i-h6-orangepi-one-plus.dtb /root/sun50i-h6-orangepi-one-plus.dts-5.1.0 About "cpu-freq", I don't really know, I'm not the expert on this one ...

Yesterday i did install Armbian_5.86_Aml-s905_Debian_buster_default_5.1.0_20190514.img from @balbes150
on my Sunvell T95KPro (S912).
 
While installing Pihole the Installation does break when trying to start lighttpd.

After checking with journalctl -u lighttpd  it turns out that the file /usr/share/lighttpd/create-mime.assign.pl 
is missing, because in the newer lighttpd-version of debian buster the file has be renamed
to /usr/share/lighttpd/create-mime.conf.pl 
(see also https://discourse.pi-hole.net/t/lighttpd-does-not-start/6207/11 )
 
Pihole doesnt know/use the new name with debian buster, so it fails to start the lighttpd
 
So I did find 2 ways to resolve the problem.
 
First (quick and dirty?) way:
cp /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl or ln -s /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl
read also:
Pihole breaks lighttpd on Debian Buster #2557
https://github.com/pi-hole/pi-hole/issues/2557
 
the second way (found it at https://forum.kuketz-blog.de/viewtopic.php?t=3067 ) is to edit /etc/lighttpd/lighttpd.conf 
and search for the 2 following lines and comment them out (found the 2nd one at the end of the file):
 
#include_shell "/usr/share/lighttpd/create-mime.assign.pl" #include_shell "cat external.conf 2>/dev/null" and add the follwoing line to the file:
include_shell "/usr/share/lighttpd/create-mime.conf.pl" After saving the file you should be able to restart lighttpd via
sudo /etc/init.d/lighttpd restart or sudo service lighttpd restart or sudo service lighttpd stop sudo service lighttpd start  
BUT second way does not work good with updating or repair-install of pihole, because I think this will set the config-file to the old state
(also for server.error-handler-404)

So maybe the first way will work better while pihole doenst know the new file-name - or you also can do both ways
 
BTW: If you are experience a 400 Bad Request while  only using the IP for getting to the Pihole-Webpage
(and the redirect should ask you if you want to use the /admin page - but it doenst)
then try the follwing small resolution - edit a line in the file /etc/lighttpd/lighttpd.conf
from: server.error-handler-404 = "pihole/index.php" to: server.error-handler-404 = "/pihole/index.php"  
 
lighttpd.conf

Yesterday i did install Armbian_5.86_Aml-s905_Debian_buster_default_5.1.0_20190514.img from @balbes150
on my Sunvell T95KPro (S912).
 
While installing Pihole the Installation does break when trying to start lighttpd.

After checking with journalctl -u lighttpd  it turns out that the file /usr/share/lighttpd/create-mime.assign.pl 
is missing, because in the newer lighttpd-version of debian buster the file has be renamed
to /usr/share/lighttpd/create-mime.conf.pl 
(see also https://discourse.pi-hole.net/t/lighttpd-does-not-start/6207/11 )
 
Pihole doesnt know/use the new name with debian buster, so it fails to start the lighttpd
 
So I did find 2 ways to resolve the problem.
 
First (quick and dirty?) way:
cp /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl or ln -s /usr/share/lighttpd/create-mime.conf.pl /usr/share/lighttpd/create-mime.assign.pl
read also:
Pihole breaks lighttpd on Debian Buster #2557
https://github.com/pi-hole/pi-hole/issues/2557
 
the second way (found it at https://forum.kuketz-blog.de/viewtopic.php?t=3067 ) is to edit /etc/lighttpd/lighttpd.conf 
and search for the 2 following lines and comment them out (found the 2nd one at the end of the file):
 
#include_shell "/usr/share/lighttpd/create-mime.assign.pl" #include_shell "cat external.conf 2>/dev/null" and add the follwoing line to the file:
include_shell "/usr/share/lighttpd/create-mime.conf.pl" After saving the file you should be able to restart lighttpd via
sudo /etc/init.d/lighttpd restart or sudo service lighttpd restart or sudo service lighttpd stop sudo service lighttpd start  
BUT second way does not work good with updating or repair-install of pihole, because I think this will set the config-file to the old state
(also for server.error-handler-404)

So maybe the first way will work better while pihole doenst know the new file-name - or you also can do both ways
 
BTW: If you are experience a 400 Bad Request while  only using the IP for getting to the Pihole-Webpage
(and the redirect should ask you if you want to use the /admin page - but it doenst)
then try the follwing small resolution - edit a line in the file /etc/lighttpd/lighttpd.conf
from: server.error-handler-404 = "pihole/index.php" to: server.error-handler-404 = "/pihole/index.php"  
 
lighttpd.conf

Cool.  2 different people reached out to HardKernel about a board for me, so I have one coming.

Today I did clone and compile kernel 4.14 from:
https://github.com/Lichee-Pi/linux/tree/zero-4.14.y
with their standard setttings (.config)
 
The resulting zImage ( 4.14.14-licheepi-zero+ ) does also work with Ethernet / Audio-Codec and the Tripple-Status-LED
 
I did put the 4.14.y zImage as zImage_Kernel_414.zip on my GoogleDrive (see above for the link)
 
I do like the small 23MB footprint of this small Linux (would like to see such Linux on a Router which normally do use OpenWRT - many of them have 128MB RAM, but less Mhz)
 

Wow nice. Thank you very much! Menu button saved my saturday.

v5.84
Added CPU speed and governor management Fixed TVheadend install on Ubuntu Improving two-factor authentication: once enabled, token is one for all local users
Added Meson64 overlay config (hardware configuration)

As I don't want to undo the work I've done for 5.1.y, I've decided to download https://dl.armbian.com/orangepioneplus/nightly/Armbian_5.83.190502_Orangepioneplus_Debian_stretch_dev_5.0.10.7z instead.
Effectively, it seems broken, stopping/freezing during boot with the following errors :
[ 6.550967] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 912000 KHz [ 6.558474] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 1080000 KHz This must have been introduced between 5.0.7 and 5.0.10 ... I will investigate a bit more ...
 
EDIT : I found something, replacing the 5.0.10 DTB by the one of 5.0.7 allows booting successfully ! ... I will compare them ...

Cosmetic issues may appear during the procedure and fixing them might take from hours to days.
 
Starting early in the morning, backup late in the evening CET.

Upgrade from v4.3.6 -> 4.4.3

What's new:
https://invisioncommunity.com/release-notes/440-r81/
https://invisioncommunity.com/release-notes/441-r82/
https://invisioncommunity.com/release-notes/442-r83/
https://invisioncommunity.com/release-notes/443-r84/

No problem, as I said the resulting "dmas = <0xa8 0xf 0xa8 0xf>;" is good !
No worries ! But that would be a good opportunity and challenge ...