tkaiser

I don't think so. The log2ram implementation uses /var/log.hdd on disk and syncs the contents to a tmpfs mount /var/log in memory at boot and syncs back at shutdown time (and once every day via cron). There's no activity generated other than 1) sync at boot, 2) sync at shutdown, 3) daily sync from DRAM to 'disk'. Everything else is the result of other daemons/tasks doing what they do (eg. rsyslogd and logrotate). Wrt syncthing running as root... I guess you installed it via armbian-config? If so please file a bug report over at https://github.com/armbian/config/issues

So a good idea is to check whether this software is running with debug/developer options by accident since I can't imagine why a software creates that absurd amount of log data: https://docs.syncthing.net/dev/debugging.html Can you check with which logging/debug switches the software runs by default and report back?

No need to construct theories or to believe in anything. These boards are neither black boxes nor do they run something magic no one is able to understand. They run an OS with a kernel that exposes every information needed. It's usually just some knowledge missing how to access this information. Quoting myself from the aforementioned thread (I referenced the thread for a reason -- since it's time to talk about how processes access the flash layer on SD cards and eMMC and to fight against some 'common SD card knowledge' that is totally misleading in reality): Simply open up two terminal windows, run both commands and let pi-hole/dnsmasq do their job. If you see real activity at the block device layer every few seconds you have to worry, if this happens only every few minutes you're fine. The amount of wear-out on your SD card due to drastically lower write amplification is magnitudes lower if dnsmasq doesn't try to flush its log to disk/card every now and then. If I understood you right, pi-hole does need this log only for parsing information out of it and storing that into a database? If that's really the case you should also focus on how database contents are updated for the very same reason as above: constant writes to card every few seconds lead to a write amplification that can be hundred or even thousand times higher compared to combined writes only every few minutes...

Has anyone the device in his hands and can tell whether this commenter on CNX is right or not? https://www.cnx-software.com/2017/12/05/libre-computer-renegade-sbc-features-rockchip-rk3328-processor-with-up-to-4gb-ddr4-ram-crowdfunding/#comment-552194 If they replaced Micro USB with something reliable there's zero Cons any more

USB2 is AFAIK available on the mPCIe connector.

There's no native SATA on the R2 anyway. It's PCIe attached SATA provided by the cheapest SATA chip available: ASM1061. I'll just reiterate this for the simple reason since there exist differences between 'native SATA' as on all those Marvell boards we support and this type of PCIe attached SATA (with ASM1061 performance is lower though that is only of interest with SSDs and not HDD... and there might be issues with NCQ, especially when combined with SSD and TRIM). Anyway: if 'SATA' is needed and some performance drop is OK and the importance of UAS and good USB-to-SATA bridges are understood there are a lot of opportunities: https://forum.openmediavault.org/index.php/Thread/19871-Which-energy-efficient-ARM-platform-to-choose/?postID=154980#post154980

Check the PID of dnsmasq and let iotop report what's going on? You need to differentiate between 'total' and 'actual' writes as per iotop's manual page (one is filesystem activity and only the other is relevant since that's about writing to the layer below) Again: https://forum.armbian.com/topic/6635-learning-from-dietpi/?do=findComment&comment=50489

Sorry, but why is pihole called pihole? Didn't they start on the Raspberry Pi where 'normal storage' is defined as SD card? I'm entirely done with this software after the last try to get a minor security fix applied which took 4 months so I won't look into their code ever again. But if they do not use syslog (so you could simply define your own filter rules and send all the useless crap to /dev/null) and write a logfile directly you should check whether they constantly issue sync calls or not. If the latter then their log contents ends up being bufferend in RAM and will only be written to card every ten minutes which would greatly reduce write amplification and wear on SD card. An explanation here and also how to check for: https://forum.armbian.com/topic/6635-learning-from-dietpi/?do=findComment&comment=50489

Neither know nor care. The last time I looked into an Allwinner BSP was over a year ago for H5. Immediately gave up since such a mess. When dealing with A64 another year before we were all lucky that longsleep did the hard work to turn the BSP mess into something useable and put all the stuff combined with documentation on Github. 2 years ago dealing with 64-bit Allwinner SoCs was fun and exciting, I doubt anyone talented will do the job again with newer BSP like the one we're talking here about. So better become familiar with dtc and editing ugly .dts files with all values in hex...

Well, amperage ratings are pretty much useless if the problem is a voltage drop under load (which is a very common problem BTW). I would try to measure voltage on the board's testpoints to check for this. And also try to rule out the other hardware issues, eg. bad DRAM: https://forum.armbian.com/topic/6667-solved-upgrade-process-is-broken-on-opz2-h5/?do=findComment&comment=50651

Well, I don't think we'll ever drop support for A20 in general. The reason Cubieboard2 went from supported to EOL is simply that without physical samples it's hard to maintain support: https://github.com/armbian/build/commit/3a485f02d8ca3956441c4cb9091415c69f348103 So if you choose a rather conservative update policy (use armbian-config to freeze u-boot/kernel updates, check forum from time to time for issues and then unfreeze/update/freeze -- in an ideal world cloning the SD card prior to that so you've always a backup) you can further have fun with your CB2 as long as the hardware does the job...

And for those still happy to get their hands dirty: http://files.pine64.org/os/sdk/H64-ver1.1/H6-lichee-v1.1.tar.gz (new version but still based on kernel 3.10.65) How to get their 4.9 kernel built: https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/pull/1/commits/9f24623786dd1bd83cac9938f81516e671a1e304 and why it's useless: https://github.com/Allwinner-Homlet/H6-BSP4.9-brandy/issues/2 So everything as expected

Would solving the problem (preventing the 'kernel crash') also be an option? How do you power the board? Micro USB?

I decided to address these reliability issues over there in Hardkernel's forum instead: https://forum.odroid.com/viewtopic.php?f=149&t=30125&p=217733#p217733

I tried for some half an hour to compile it, but like @tkaiser said, the tutorials are so outdated Those old tutorials were made for the situation back then half a decade ago (that old is Allwinner's BSP for A20 which the original LeMaker tutorial has been written for). They do not mention for example that you need a more recent Ubuntu build host with more recent BSP drops and they especially don't mention that you need a x64 Ubuntu in the meantime since building on x86 will fail. These old tutorials are simply not worth a look. For people wanting to improve on their skills getting an Allwinner BSP to work it's a great idea to dig through all of this. But since these BSP have never meant to be used by end users or even board makers (usually Allwinner engineers do the job for their customers which are Android device manufacturers and not the users later using those devices!) it's just a mess to deal with.

Somewhat probable due to the reason that the R2 is the only device so far supported by its board vendor. Unlike all the other Bananas for which their users get zero support over at forum.banana-pi.org if you look into http://forum.banana-pi.org/c/Banana-Pi-BPI-R2 there's a really high level of both end user and developer support (@garywang being pretty busy, a couple of MediaTek engineers doing the same and 'frank-w' as a volunteer even providing great documentation ressources -- something Banana folks still are either not willing or able to do). Since MediaTek also actively upstreams code to official u-boot and Linux projects once mainline support is mature enough Armbian might add the board. The situation one year ago was totally differently so this all is a nice surprise (please keep that in mind when reading through old threads dealing with R2) So 'someday' this might happen but I don't think anytime soon since it's an entirely new platform (MediaTek MT7623) and adding new platforms to Armbian requires an enourmous amount of work but we're very low on (developer) ressources. And once we would add R2 immediately people would start to ask about Banana Pi W2 and Banana Pi R64 which again both rely on other entirely different platform so initial software support efforts would be insanely high again (it's not about boards, it's about SoCs/platforms). Let me add some notes since you seem to believe into 'SATA is always better'. The 'native SATA' implementations on SBC differ a lot with Allwinner SATA as present on Cubietruck and other A20 devices being the slowest one. Surprisingly USB3 attached SATA outperforms old 'native SATA' on A20/i.MX6 in every area (even random IO included!) 'Dual SATA' on R2 is not 'native' but PCIe attached which has its own downsides and depends partially on the PCIe adapter being used (the R2 uses a cheap ASM1061 which is not 'wrong' but can result in some problems in some situations, see N1 link below with explanations/references) Armbian currently supports the following boards with SATA implementations worth a look (excluding Allwinner and i.MX6 SATA): Clearfog Base (1 to 5 SATA ports), Clearfog Pro (1 to 9 SATA ports), Helios4 (four SATA ports), EspressoBin (1 to 5 SATA ports). The Clearfogs and EspressoBin have a mPCIe slot where you can add 2 or even 4 SATA ports with an appropriate PCIe controller. On the Clearfogs you can also turn one or even two mPCIe slots into mSATA so with cheap mechanical converters they provide 2 or even 3 'native SATA' ports (that outperform every PCIe attached solution) Armbian in the future will support the RK3399 platform with a ton of new boards arriving in 2018. While RK3399 is also a new platform from a software point of view it's pretty close to RK3288 and RK3328 which we already support. Since RK3399 has PCIe capabilities there will be a bunch of boards with multiple SATA ports soon since adding an ASM1061 to a PCIe lane cost the board makers just a few bucks. In other words: If you want to use Armbian there's already a couple of options for 2 or even more really fast SATA ports. Ok-ish SATA will appear on a lot more boards in 2018 and it's important to understand that especially with HDDs USB3/UAS attached SATA isn't necessarily worse than PCIe attached SATA (but the controller and the firmware matter and this applies to both USB3 and PCIe attached SATA). Both USB3/UAS and PCIe attached SATA outperform old 'native SATA' on A20 and i.MX6. References / Further reading: Storage performance overview also focussed on comparing 'native SATA' and 'USB attached SATA': https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=34192 A lot of individual storage (performance) comparisons for a variety of boards: https://forum.armbian.com/topic/3953-preview-generate-omv-images-for-sbc-with-armbian/ Early steps with ODROID N1 as an explanation why/how 'native SATA' and 'high-speed bus attached SATA' differ and also a comparison of PCIe attached SATA using the same ASM1061 as R2 and good USB3 SATA implementations: https://forum.armbian.com/topic/6496-odroid-n1-not-a-review-yet/ 2 and 4 port SATA controllers and Armbian: https://forum.armbian.com/topic/4845-marvell-based-4-ports-mpci-sata-30/ Reading through all of this will take some time of course but later you know why you most probably don't want a Cubietruck or any other A20 device any more if you're interested in storage (performance). I'm 'sorry' to say that Armbian is not only about throwing out software but is also a research project. Since all supported devices behave more or less the same once Armbian runs on them it's important to understand the hardware differences to be able to pick the board that suits your own needs best.

http://wiki.lemaker.org/BananaPro/Pi:Building_your_own_Android_firmware -- this is where the above has been copied from. I'm not that concerned about people wasting their time following inappropriate 'tutorials' rotting somewhere on the Internet but more why all this off-topic Android talk has to happen here in this thread? Why can't this be moved to 'peer to peer support' where it belongs to? With those 64-bit ARMv8 SoCs there is a lot different (e.g. ARM Trusted firmware). How to deal with a cleaned up BSP is most probably best described here: https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess Wrt mainline I would better look there: https://forum.pine64.org/showthread.php?tid=5790&pid=35873#pid35873 It doesn't really matter which H6 device is in use since all that matters is the SoC. Board specific hardware settings need to be extracted from sys_config.fex files and then adopted (both to other hardware and other u-boot/kernel version -- the Allwinner BSP .dts files use a different structure than proper mainline stuff)

https://github.com/armbian/build/commit/075259c3456c6ef016460be18d3eeddc66e4fed1 There is no problem with this board being added as CSC. But the patch series that was pulled in from SinoVoip contained a stupid and ugly hack and was obviously neither tested nor worked. So I really don't understand what happened. If anyone wants to support this board as CSC (at least a simple test has to happen since everything else is totally weird) then why not adopting Icenowy's DT corrections so that the production batch is able to boot? Now everything fine, we have 4 files in the repo that result in non working images but it's not a real problem any more other than people playing around with the build system getting frustrated, asking unnecessary questions here and generating support efforts... If we could only establish policies all developers feel bound to. Before something will be added a DISCUSSION has to happen...

...is outdated like hell and only suitable for A20 boards that are not available from Xunlong any more since years.

I asked ayufan in the meantime and he pointed me to https://github.com/ayufan-pine64/boot-tools/blob/with-drm/Makefile#L113-L116 for this. No idea about requirements/tools needed and where they can be found. Just had a quick look into https://github.com/Allwinner-Homlet/H6-BSP4.9-tools but immediately ran away after clicking around. It's the usual AW mess...

Nope, that's the wrong one (only suitable for Allwinner's old 3.4 kernel). You need to modify the .dtb file or use the Allwinner BSP/SDK to start with sys_config.fex. All Ethernet related entries for the Orange board have to be taken from Xunlong otherwise it won't work. When dealing with this stuff 2 years ago I was a bit late to game. At that time longsleep already had done an amazing amount of work to cleanup the Allwinner BSP mess and we could deal with a build system that was at least somewhat useable. Back then he switched from sys_config.fex directly to .dts but in the meantime ayufan reverted to sys_config.fex with his builds (I searched for the relevant commits but did not find them. Maybe @Xalius has a clue how the initial conversion works). So you probably find some information here but I've no idea how filesystem structure looks like on those Android builds.

Just stumbled accross this: https://bbs.archlinux.org/viewtopic.php?id=139141 (only posted to preserve the link)

You don't have to fear contents disappearing since it's all under version control (so you can switch back in time on Github) and for your own needs there's the userpatches directory you might want to use already now: https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-patches

Well, it seems we have internally different views on how board support should look like. In my opinion pulling in the broken patchset from SinoVoip that is just the usual result of the ignorance they're famous for was not a great idea since it's both not working as expected and if Sinovoip's ugly hack would work it would negatively affect all our other sunxi devices. Maybe the CSC config will be removed, maybe someone interested in this device will fix it (definitely not me). Device support should work without that ugly hack by simply following the upstream processes. @Icenowy's patch series to officially support this board in mainline is at v5 in the meantime with the most important change to fix the problem you ran into happened already in v2 many many months ago. The stuff that landed now in Armbian's build system is based on really outdated stuff dating back even prior to Icenowy's v2 patch.

Ahem, that's how open source projects usually work (see Linux kernel or u-boot for example -- @zador.blood.stained already commented on the real issue here) We have no testing branch, we have constant upgrade troubles breaking user installations and interpreting your answer this won't change anytime soon or at all. I can not use Armbian any longer for my own needs without preventing Armbian packages being updated. That's just bizarre and makes me sad. It's not about this specific case with this specific board. I'm talking about how we can prevent this horrible update experience happening again and again and again. Given the patch would've not been broken but really messed up sunxi u-boot... what would've happened? Why has this to happen? Why can't we agree on policies every developer is bound to? Before we add a new device a 'Board bring up' thread will be started where pros/cons and problems are discussed. I have the ugly hack they 'needed' to apply on my list since months but had waited for someone starting a Board Bring Up thread (since instructed to stop starting such threads when the device should NOT be supported by Armbian). If I understand correctly @Icenowy addressed the problem with changed card detect GPIO between pre-production and production boards already back in November last year (see mmc0 definition in her v2 patch series) and then SinoVoip as usual ignored everything and came up three weeks later with their ugly hack instead of relying on her work. Well maybe that's why policies are useful or even mandatory. IMO there's no need to suck in patches sitting in a board vendor's repo (known for having never contributed upstream anything so 'port and forget' code style has to be expected) especially if Armbian does still not provide any means of a sane testing/beta environment. It's all done in master branch which is IMO terrible.