Werner

Yes. In the early days, about linux 4.17 when the first initial support for Allwinner H6 from Armbian came, it was limited to 1,5GHz but I remember a patch for 4.18 which rised the max frequency to 1810MHz and it ran well. I did benchmark without cooling whatsoever and it survived. Over a longer period of time on heavy load I would think about some kind a cooling though,

@martinayotte May you take a look here: https://github.com/EvilOlaf/build/commit/eb4a36885bc63199bbc5aadb2bd220c560af0109#commitcomment-32007637 Is this something known or worth trying?

It is the same SoC so yes, it may suffer from all these issues as well.

Maybe because no one had a need for it yet. You can build your own kernel and edit the config using the build script: https://github.com/armbian/build If you think this might be useful for others feel free to send a PR with the changes to the kernel config so all future builds include this.

Looking decent. Nothing odd so far. As from my experience topics usually are bumped actively during the first days till maybe weeks, but not over month. The situation here might be different though.

Are there that many older topics that getting exhumed? Not sure if possible with Invision without addon, I know that worked in vB years ago but what about simply limiting the number of visible topics by age up to 90 days as default?

I am torn about this. For various you may not be able to generate such a link. Like network issues (you still get the output but not the special link), I/O issues or boot issues.

I think we should not take take that with a pinch of salt just because it says "Issues". Don't get me wrong, I totally get your point, but if the mix of issues with discussions is either here in the forums (just take a look over there) or at Github issues does not make a big difference. At github discussions can be labeled as those at least as every new topic there needs a review in first place. What about this as a compromise between both: - Rename "Armbian build framework" to "Armbian build framework - Discussions" and - create another subforums Armbian build framework - Issues" which redirects to Github At the bottom line there is no perfect solution for this because there are always and always will be users which are either inexperienced, creating topics at the wrong place by accident or are just trolls. Unfortunately there is no other way than cleaning up behind. That's the curse of all forum operators.

Well I'd guess that using prefixes can also be enforced by the system. So you have to choose on topic creation. Agreed. Annoying work. I already did stuff like that many years ago... What about simply redirecting "Armbian build framework" to https://github.com/armbian/build as all stuff regarding the building process, script and so on is discussed (or should be at least) discussed there?

Like. As an alternating suggestion is to merge mainline and legacy kernel forums and use pre-defined thread prefixes like [Legacy] or [Mainline]. Though two problems: I do not know if possible technically as I never managed Invision forums. vBulletin and WBB only. The second issue I see is more generic as especially new users may not know the difference between legacy and mainline. I did not know by myself a year or two before. At the moment no idea how to solve this. Maybe this is not even a problem as big as I may think. Are A64 and H5 stable enough to be removed from development?

active = powered by external power source, to say wall adapter

You can send a PR with your changes to the kernel config here: https://github.com/armbian/build

I have an OrangePi zero as DNS server utilizing Pihole and Armbian, Dietpi earlier until they dropped their support for OrangePi boards, as base for almost two years now and running great. Also this board is dirt cheap and way enough for this application. The WiFi on board is crappy but as long as you wire it with copper it runs fine.

Either get an USB TTL adapter which is very useful anyways and is very cheap or put the SD card in your pc, chroot into the fs and fix it there like for example as suggested by downgrading particular packages.

Could be difficult with legacy kernel. Assuming it is 3.4.113...

I bought one of these, looking exactly the same, from a different dealer on Amazon, however I did not come with MT7601U but an unsupported Realtek chip. You can take the risk buying this and maybe you even get what it is advertised. Edit: Related:

Yes, I think this is the way to go. armbian-config has nothing to do with the build system. It is a independent tool to set various system values, switch/freeze kernel version, and so on within a running Armbian system. Sorry for confusion.

Why not simply switching to 4.14..81?

Use armbian-config and switch to dev (or beta, not sure) branch. This ships 4.19 kernel. Do you miss anything special within 4.14? This is a maintained long term kernel btw.

After you run compile.sh the first time a userpatches directory is created where you can place own patches. Until now the only kernel known to work is 4.18.0-rc7. I do not know if pure Debian packages with this specific kernel image still existing somewhere, but AFAIK are the latest precompiled images for OPi 1+ and Lite2 are still shipped with this kernel. So if you have one of these boards you may start over and freeze the kernel from being upgraded using armbian-config

Images [edit: for boards with Allwinner H6 SoC] with kernel versions above 4.18.0-rc7 are unbootable anyways AFAIK. But feel free to update your kernel within the OS like Igor said. Please let me know if it still boots.

I suggest to not bother too much with the onboard WiFi as it is not very good. A better and more reliable solution would be to get a supported USB WiFi dongle.

Disconnect power

Known issue. Go back to 4.18.0-rc7 and freeze kernel until solved or build your own kernel with all the stuff needed and disable on board Ethernet and use USB-Ethernet adapter. Interesting to know though that other boards are affected too.

The reason for this seems to be a regression or a missing commit from @Icenowy sources (https://github.com/Icenowy/linux/commits/h6-integrate-2-ugly) which has not made the jump into mainline (yet). Therefore you either have to use the 4.18.0-rc7 kernel image (which I run two OPi 1+ perfectly fine on right now) or temporarily disable dwmac like @martinayotte did as workaround to successfully boot up the board with a kernel built from newer sources (and use a USB-Ethernet adapter). For confirmation you can utilize a UART serial adapter to check the kernel boot for errors like "sun8i_dwmac_probe+0x164/0x518". As stated mainline support has still a long way to go to better support the H6 SoC. Do not just discard the board. Just put it on the shelf and it may run fine in a couple of month.