Igor

Jep And in such cases, support assitance can't do much. We only try to fix our errors, not yours It's not paranoia but switching to "I don't care" mode. We have do draw a line because this technical support is most expensive and most abused part of the project. We can't possibly cover Debian Jessie upstream issues. That's why.

Workaround is by switching to kernel 4.14.y and freeze kernel upgrades. armbian-config -> system

Since you have 8814AU. Is that adaptor working within armbian-config? Can you set AP with it?

That method works if drivers for this chip are capable of running AP. Standard way. No idea if this chip works at all.

I am sorry but I could not find any Debian Jessie image for the download ... Official OMV Stretch image with installed all updates = kernel switching without problems or code modifications Armbian Debian Stretch with installed all updates = kernel switching without problems or code modifications When you switch kernel, you need to freeze it otherwise it will be upgraded at next apt update / upgrade.

They are hidden if there is nothing new in them. This can be set per forum. Probably. I'll try. It's already enabled in Technical support section. Auto-lock will follow - i did testing in recycle bin and it seems to work properly.

ok

- screen must be attached at boot time. - if you use some HDMI2VGA converter you might have problems - images were tested many times and they work fine - NAND is less reliable than a modern SD card and not supported in modern kernel

This is how it will look like when enabled - is there anything odd that has to be changed - beside texts - some native speaker should check that. Tags are limited to one (1), legacy or mainline. We also want to prevent topic bumping. Perhaps this closing time could be longer than 90 days. Let's set it for 1y and adjust in the future.

Agree. It's a step forward if there is a field ... it has to be optional and we have solved this problem.

Plus adding this plugin https://invisioncommunity.com/files/file/9042-auto-lock-topics/ to entire Technical support question with locking everything that older than 90days? This would make sense in a combination with various restriction for creating a new topics (adding armbianmonitor -u).

https://invisioncommunity.com/forums/topic/449714-custom-thread-with-fields-possible https://invisioncommunity.com/files/file/8200-template-system/ + implementation in the template. It looks like this can be used?

Agree. This has to be used very carefully. If at all. That's a good idea. I'll check if that is possible.

Problems are outside user space levels otherwise we would notice such problems on other boards, but we don't. Kernel is the king and the troublemaker

I didn't encounter them by myself, but I think somebody brought up troubles when copying large files via USB3 drives. Check older posts in this subforum.

Most Armbian images do not have this problem as well. It should be fixed, but our fix could also be broken - RK3399 has handull of small troubles which is why we actually don't provide end user support yet. When you are approaching with a problem, you always need to provide logs (armbianmonitor -u).

Yes, prefixes can be optional or enforced. First we need to find out if this is what we need Perhaps. @zador.blood.stained?

Level between development and stable is hard to define. To be more precise, IMO they match H3 levels which also have certain problems and shortcomings. Despite that, those boards can be used in production. Major problem in this sense is actually on the H3 side due to "power-off" problems. Prefixes are supported by the forum software but we don't use them. They are only used here: https://forum.armbian.com/forum/26-research-guides-tutorials/ but also without any proper meanings since all subforum is anyway dedicated for Tutorials/Research. If this feature is not strictly used, it's pointless to have it there. And someone (which is not me ) would have to manually resolve prefixes for at least last two pages of topics. Agree. In this sense it might be worth to think about merging "Armbian build framework" and redirect the rest to the "Technical support area" or "Peer to Peer" if it has nothing to do with Armbian. Another option to limit pressure on support is by enforcing forum payment system. System is here, it's highly integrated in forum ... and it works. Not exactly to charge for support but to return a pressure back.

https://github.com/armbian/documentation/commit/63c02d26ceca64d032696247e7c4657f4656a1ce https://github.com/armbian/build/commit/730c1f6f4d6a5f45418c39e789f63b8da4fb1411 (not yet included in latest images, but included via apt update) 1m from router. RTL8188CUS RTL8188EUS MT7610 at 5G MT7601U

OK, switching sounds as a good idea too.

No need. We don't have capacity to sponsor support for generic Debian problems - use Google, Debian/Ubuntu forums. Pointing you to the right direction is already a premium service which will save you some time. That's is known. This service along with other utilities were made specially for legacy kernel. Most of those functions does not exists and/or will never exists in a modern kernel. Use kernel which suits your needs best.

If you don't have to rush: https://www.ebay.de/itm/10PCS-6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-FT232/401092518807 for 11€ you get 10pcs (or 1pcs < 2EUR) from renown/trusted seller on Ebay with free delivery via HK post. It usually takes 10-14 days to get to the EU.

This could be safe to ignore, but it would be nice to peek into the logs to see which module(s) are not getting loaded. sudo journalctl -u systemd-modules-load.service

I will rebuild those images ASAP.

Clearfog wasn't receiving any updates in last update beside upstream fixes. There were some adjustments to the mvebu-next kernel for Helios4 purposes by @gprovost https://github.com/armbian/build/commits/master/patch/kernel/mvebu-next I doubt they could be behind those troubles.