Werner

I meant the devfreq hack: https://armbian.atlassian.net/browse/AR-374

If you have switched the sd card as well as the power source and cable and somebody else with the same board can boot the same image flawless....then well the board might be broken.

Which one???

Your board is way outdated and will not receive support. Please upgrade to a more recent kernel.

Hm odd. Maybe someone else has an OPi3 laying around and test if hostapd is broken for some reason. I don't have an H6 board with WiFi to test... A few month ago I tested this with my OPi0 which worked flawless.

I cannot tell you how exactly to implement this but I can tell you where to put things to get them into your ready-to-burn image: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script

I never had issues with mine. Though this might be related to the high temperature issue which seem to have v1.4 and v1.5 LTS boards while mine is v1.1 I created a patch for this Needs to be tested against H5 since I dont have any board with this SoC and see if this has bad side effects there. From 94f434f28f1d468dfc895f4a1f7e2d807537a78f Mon Sep 17 00:00:00 2001 From: EvilOlaf <werner@armbian.de> Date: Thu, 6 Aug 2020 07:53:14 +0200 Subject: [PATCH] fix higher clocks for H3 Signed-off-by: EvilOlaf <werner@armbian.de> --- arch/arm/boot/dts/sunxi-h3-h5.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi b/arch/arm/boot/dts/sunxi-h3-h5.dtsi index b5dea77d4..fb5af20fa 100644 --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi @@ -135,25 +135,25 @@ opp-1104000000 { opp-hz = /bits/ 64 <1104000000>; - opp-microvolt = <1320000 1320000 1320000>; + opp-microvolt = <1300000 1300000 1300000>; clock-latency-ns = <244144>; /* 8 32k periods */ }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>; - opp-microvolt = <1320000 1320000 1320000>; + opp-microvolt = <1300000 1300000 1300000>; clock-latency-ns = <244144>; /* 8 32k periods */ }; opp-1296000000 { opp-hz = /bits/ 64 <1296000000>; - opp-microvolt = <1340000 1340000 1340000>; + opp-microvolt = <1300000 1300000 1300000>; clock-latency-ns = <244144>; /* 8 32k periods */ }; opp-1368000000 { opp-hz = /bits/ 64 <1368000000>; - opp-microvolt = <1400000 1400000 1400000>; + opp-microvolt = <1300000 1300000 1300000>; clock-latency-ns = <244144>; /* 8 32k periods */ }; }; -- Created with Armbian build tools https://github.com/armbian/build

That is awesome. Will test on my OPi One. Works. Let's burn it!

There are no plans for that AFAIK. If you want to speed things up make yourself familiar with the build tools and start tinkering. Armbian is relying heavily on community and manufacturer contributions for new board support. At least it is a known SoC which should not be that bad...

Because probably noone ever took care about that Feel free to test stability (and heat) on higher clocks and then either fix it to make it work or remove them from the dts and make a PR.

Did you apply the GPU clock fix?

Afaik there is no proper support for the regulator and that is why it is capped. It is the same for the OrangePi One. And most likelie for other H3 boards too.

Sleep well, friend. Armbian is trying to mostly provide "vanila" OS feeling when deployed on a board. So you get the same experience like if you install Debian or ubuntu to a regular computer. armbian-config is an optional tool for beginners or lazy people to install stuff which also can break sometimes if there are major changes upstream.

Well It gets a bit complicated at this point. See both Pihole and nextcloud need a webserver to serve their webinterface. Without manual configuration they cannot be used at the same time. What I'd do so it is pretty: Install pihole first and make sure it works. When you open "pi.hole/admin" in your browser and you see the webinterface then everything is good. Do not proceed until this is achieved. Now add "nextcloudpi.local" as a custom domain via pihole interface and point it to the ip of your SBC (192.168.20.100 to say if this your board). When you open a command prompt and ping nextcloudpi.local then it should respond from the given IP address. Create a folder where you want nextcloud to be run in (like /var/www/cloud) and edit your lighttpd config (lighttpd has been installed by pihole before). create a virtualhost besides pi.hole for the server name nextcloudpi.local and point to the working directory mentioned above. Then install nextcloud (btw. using armbian-config to install any software is not mandatory ;)) and tell the installer to use the domain mentioned above. If everything is setup properly you can simply enter nextcloudpi.local in your browser to get to your nextcloud or pi.hole to get to its equivalent webinterface. Once all this stuff works nicely in your local network then I'd start taking care about the VPN stuff. Btw. I never created vhosts within lighttpd by myself, mostly apache and nginx only so that part you have to figure out by yourself. Tutorials should be easy to find in the web though.

Welcome How should your operating system know to which IP address it should to when calling "nextcloudpi.local"? You have to create that DNS entry first or make pihole work beforehand to add this dns entry there. Disable your VPN and try again. Maybe it does not allow packages outside the VPN to be routed back to your PC.

So hostapd does not work on OPi3?

Years ago Xulong published an OS image for the OrangePi One Plus that generated 100% load on 3 out of 4 cores because their implementation was crappy hacked together and called that "supported"... You be the judge...

Well you can grab the sources and the needed patch dirs and simply loop through the patch dir to apply the patches to the sources to get the patched sources.

Thanks, fixed. I also adjusted your answer in the sheet (H5)

https://docs.google.com/spreadsheets/d/11iid35ZGlTws1XOqSMJIw0y7nK6bNdpqVq6I4JFihuo/edit?usp=sharing

https://github.com/armbian/config/pull/110 Thx

...and adding firefox or better firefox-esr (since it is in both Ubuntu and Debian AFAIK) to the list of desktop packages?

We have multiple kernel branches available. Always provide armbianmonitor -u

Since we have some more fundamental questions about snap to clarify I'd say do this:

I'd say depends. If you like the challenge of scripting this which for sure should be possible then do that. On the other hand though the easier setup is by following @xwiggen's advice, not lastly because WiFi dongles have become very cheap...