Search the Community

The nice dashboard screenshot above is used by @Fourdee to explain why DietPi is superiour to Armbian: 'With #DietPi, logs and DietPi scripts are mounted to RAM , this reduces SD card write operations vastly' -- while I don't understand the purpose to 'mount scripts to RAM' of course the idea to cache logs into RAM is great! That's why Armbian does it since 2014 already. While the above 'proof' is somewhat questionable (watching a 5 min period in a dashboard and once there's activity in one graph taking a screenshot with numbers without meaning) let's look into what makes DietPi that superiour compared to Armbian since it's always a great idea to improve even if that means taking over other project's USPs. For whatever reasons DietPi dropped support for all Orange and Banana Pis recently (seems this started with a conversation between @Igor and @Fourdee on Twitter, then continued here and ended up there) so I had to take another board to do a direct comparison. The only boards that are supported by both projects are now Pine64, Rock64, Tinkerboard, some NanoPi and the ODROIDs. I chose Rock64 mostly to ensure that we use same kernel and almost same settings (Armbian's philosophy is to fix as much as possible upstream so our usual performance fixes went into ayufan's Rock64 build scripts DietPi in this case is relying on by accident so even DietPi users can continue to benefit from our work ) I took latest official DietPi image for Rock64 and the first surprise was the rootfs being pretty small and entirely full so no way to proceed: /dev/mmcblk1p7 466M 453M 0 100% / For whatever reasons DietPi chose to overtake ayufan's partition layout (for users new to DietPi: this is always just someone else's Debian image processed manually and by some scripts until it becames 'DietPi') but their 'dietpi-drive_manager' responsible to resize the rootfs seems not to be able to cope with this (I wanted to report it to DietPi but there's already a report that gets ignored and it seems I can't comment there). Edit: Ah, it seems @Fourdee blocked me from helping them entirely. I wanted to assist DietPi folks over at https://github.com/Fourdee/DietPi/issues/1550 but can't point them to fix the thermal issues they're running into again or why it's a bit weird to reintroduce the 'rootmydevice' issue again or why the new Allwinner BSP code is not such a great idea due to non-existing dvfs/thermal support Fortunately our scripts below /usr/local/sbin/ were not deleted by DietPi so I simply called /usr/local/sbin/resize_rootfs.sh which instantly resized the rootfs partition and was then able to continue. For whatever reasons it took 3 whole reboots to get DietPi upgraded to their latest version v6.2 but then I was able to do so some measurements: I then downloaded our Rock64 nightly image (based on Ubuntu Xenial but that doesn't matter that much -- as we all know the userland stuff is close to irrelevant since kernel and settings matter) and did the same thing. But no reboot needed since for whatever reasons DietPi remained on pretty outdated 4.4.77 kernel so I chose to not update Armbian's kernel to our 4.4.115 but to remain at 4.4.77 too: Let's look at the results leaving aside the various performance and security issues DietPi suffers from since not relevant if we want to look at stuff where DietPi outperforms Armbian. First 'idle behaviour': DietPi Armbian DRAM used: 39 MB (2%) 44 MB (2%) processes: 120 134 cpufreq lowest: 97.5% 99.8% cpufreq highest: 2.0% 0.1% idle temp: 46°C 43.5°C %idle percent: 99.95% 99.98% So we're talking more or less about identical numbers. 'Used' memory after booting is 2% of the available 2GB (anyone thinking 'free' RAM would be desirable on Linux... please try to educate yourself: https://www.linuxatemyram.com), the count of processes reported by ps is almost the same, cpufreq behaviour, %idle percentage and temperatures are also the same (DietPi temperature readout is somewhat flawed since their 'cpu' tool affects system behaviour negatively). Even if Armbian ships with almost twice as much packages installed by default the process count doesn't differ that much (and idling processes really don't hurt anyway) and used memory after booting also doesn't differ significantly. But this 'boot and sit there in idle' use case isn't that relevant anyway and in situations when RAM is really needed I would assume Armbian users are in a much better position since we ship with zram active allowed to use half of the physical DRAM (see here for a brief introduction to zram). So far I don't see that much advantages (none to be honest) but most probably I missed something? Anyway: let's continue focussing on storage utilization and 'use': DietPi Armbian size img.7z: 104 MB 223 MB (x 2.1) size img: 668 MB 1.6 GB (x 2.5) rootfs size: 457 MB 1.2 GB (x 2.7) packages: 229 436 (x 1.9) commit interval: 5 s 600 s kB_wrtn: 156 KB 448 KB (x 2.9) kB_read: 1008 KB 5912 KB (x 5.9) So both compressed and uncompressed image sizes are much larger with Armbian, same goes for used space on the rootfs which is understandable given that Armbian does not try to be as minimalistic as possible (see the count of pre-installed packages). I don't think going minimalistic is something desirable though we could think about removing development related packages from default installations as @zador.blood.stained suggested already. Maybe it's worth to adjust the rootfs partition size calculation to use slightly less so the uncompressed image size can be a little bit smaller? Anyway: for people being concerned about smallest image size possible even without leaving out packages from default install simply building an own image and then switching from ext4 to btrfs does the job since reducing image size to around ~60% (one of Armbian's advantages is that our images are not hand-crafted unique 'gems' but the fully automated result of our build system so everyone on this earth can simply build his own Armbian images suiting his own needs). And besides that I really see no benefit in trying to get the rootfs size smaller since we surely don't want to start to encourage users to write Armbian images to old and crappy SD cards with less than 4GB size (though I already consider 4GB cards nothing anyone should use these days since almost all those cards are insanely slow). Let's better continue to educate our users about the importance to choose good and reliable SD cards! Now looking at the last 3 lines above. I executed an 'iostat -y 3600' to query the kernel about the total amount of data read and written at the block device layer. within one whole hour With DietPi/Stretch 156KB/1008KB (write/read) were reported and with Armbian/Xenial 448KB/5912KB (write/read). All numbers are too low for further investigations though something is worth a look: that's the default rootfs 'commit interval.' DietPi seems to use ext4 defaults (sync every 5 seconds to SD card) while in Armbian we choose a somewhat high 10 minute value (commit=600). So while with Armbian and 448 KB written in one hour almost three times as much data has been written at the block device layer it might be possible that the 156 KB written by the DietPi installation caused more wear at the flash layer below due to a phenomenon called Write Amplification (TL;DR version: writes at the flash layer happen at 'page sizes', usually 8K, and by using a high commit interval somewhat larger data chunks will be written only every few minutes which can result in significantly less page writes at the flash layer compared to writing every few seconds smaller chunks of data. Adding to the problem once a card is 'full' now we're talking about much higher Write Amplification since now not just pages are written but usually whole Erase Blocks are affected that are much larger. So please choose your SD card wisely and always use a much larger capacity than needed since there's no TRIM with SD cards in Linux!) It would need a lot of more detailled analysis about this write behaviour but IMO it's not worth the efforts and Armbian's 10 min commit interval does a great job reducing further SD card wearout (anyone with too much spare time? Grab 'iostat 5' and 'iotop -o -b -d5 -q -t -k | grep -v Total' and start to analyse what's happening at the block device and application layer forgetting about the filesystem layer in between!) So where's some room for improvement when comparing our defaults with DietPi's? Maybe removing development related packages from default package list? Maybe tuning rootfs partition creation to use slightly less space? Mostly unrelated but an issue: improving our log2ram behaviour as already discussed?

Why? FAT support is part of Armbian though deprecated. In the past there existed options to create /boot on a small FAT partition -- that's also the way DietPi used Armbian's build system for some time -- but we don't want /boot on a FAT partition since dpkg on FAT is a mess. But asides that I would believe it's as easy as adding this small partition at image creation time.

This is by design on all ARM boards for the simple reason that activating monitoring results in permanent writes to the rootfs and if this is on flash media (SD card) Write Amplification is huge and the card will die way earlier. So if you want nice looking (but pretty useless) graphs simply activate monitoring and be prepared for your SD card failing early. Or move the rootfs to other storage (which has other downsides, eg. a HDD not spinning down any more when idle) I tried to explain the problem wrt Write Amplification already: https://forum.armbian.com/topic/6635-learning-from-dietpi/?tab=comments#comment-50489 https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole/?do=findComment&comment=50833

It is totally broken: Unsafe temp file handling Incompatible to Armbian's recommended way to setup Wi-Fi (nmtui/nmcli) It stores the Wi-Fi credentials in cleartext in a world readable file It's a mystery to me why you ever accepted this code as PR, we agreed on deleting it already (now that DietPi doesn't use Armbian as 'pre-image' any more) and now you start to recommend this stuff to users? Only sane way would be to allow to create a NM profile only readable by root below /etc/NetworkManager/system-connections/ -- since this does not exist users either need to use serial console (easy on OPi Zero since available through Micro USB) or keyboard/display.

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

Please be careful since this is an entirely different workload compared to 'using SD cards for the rootfs' since storing images and video is more ore less only sequential IO coming with a write amplification close to the optimum: 1. This means that the amount of data written at the filesystem layer, the block device layer and the flash layer are almost identical. With our use cases when running a Linux installation on the SD card this looks totally different since the majoritiy of writes are of very small sizes and write amplification with such small chunks of data is way higher which can result in 1 byte changed at the filesystem or block device layer generating a whole 8K write at the flash layer (so we have a worst case 1:8192 ratio of 'data that has changed' vs. 'real writes to flash cells') Please see here for the full details why this is important, how it matters and what it affects: https://en.wikipedia.org/wiki/Write_amplification Our most basic take on that in Armbian happens at the filesystem layer due to mount options since we use 'noatime,nodiratime,commit=600' by default. What do they do? noatime prevents the filesystem generating writes when data is only accessed (default is that access times are logged in filesystem metadata which leads to updated filesystem structures and therefore unnecessary writes all the time filesystem objects are only read) nodiratime is the same for directories (not that relevant though) commit=600 is the most important one since this tells the filesystem to flush changes back to disk/card only every 600 seconds (10 min) Increasing the commit interval from the default 5 to 600 seconds results in the majority of writes waiting in DRAM to be flushed to disk only every 10 minutes. Those changes sit in the Page Cache (see here for the basics) and add as so called 'dirty pages'. So the amount of dirty pages increases every 10 minutes to be set to 0 after flushing the changes to disk. Can be watched nicely with monitoring tools or something simple as: watch -n 5 grep Dirty /proc/meminfo While @Fourdee tries to explain 'dirty pages' would be something bad or even an indication for degraded performance it's exactly the opposite and just how Linux basics work with a tunable set for a specific use case (rootfs on SD card). To elaborate on the effect: let's think about small changes affecting only 20 byte of change every minute. With filesystem defaults (commit interval = 5 seconds) this will result in 80KB written within 10 minutes (each write affects at least a whole flash page and that's AFAIK 8K or 16K on most cards so at least 8K * 10) while with a 10 minute commit interval only 8KB will be written. Ten times less wear. But unfortunately it's even worse with installations where users run off low capacity SD cards. To my knowledge in Linux we still have no TRIM functionality with MMC storage (SD cards, eMMC) so once the total amount of data written to the card exceeds its native capacity the card controller has no clue how to distinguish between free and occupied space and has therefore to start to delete (there's no overwrite with flash storage, see for example this explanation). So all new writes now might even affect not just pages but whole so called 'Erase Blocks' that might be much larger (4MB or 16MB for example on all the cards I use). This is for example explained here. In such a case (amount of writes exceed card's native capacity) we're now talking about writes affecting Erase Blocks that might be 4MB in size. With the above example of changing 20 bytes every minute with the default commit interval of 5 seconds at the flash layer now even 40 MB would be written while with a 10 min commit interval it's 4MB (all with just 200 bytes having changed in reality). So if you really care about the longevity of your card you buy good cards with capacities much 'larger than needed', clone them from time to time to another card and now perform a TRIM operation manually by using your PC or Mac and SD Association's 'SD Formatter' to do a quick erase there. This will send ERASE (CMD38) for all flash pages to the card's controller which now treats all pages as really empty so new writes to the card from now on do NOT generate handling of whole Erase Blocks but happen at the page size level again (until the card's capacity is fully used, then you would need to repeat the process). There's a downside with an increased commit interval as usual and that affects unsafe power-offs / crashes. Everything that sits in the Page Cache and is not already flushed back to disk/card is lost in case a power loss occurs or something similar. On the bright side this higher commit interval makes it less likely that you run into filesystem corruption since filesystem structures are updated on disk also only every 10 minutes. Besides that we try to cache other stuff in RAM as much as possible (eg. browser caches and user profiles using 'profile sync daemon') and same goes for log files which are amongst those candidates that show worst write amplification possible when allowing to update logs every few seconds on 'disk' (unfortunately we can't throw logs just away as for example DietPi does it by default so we have to fiddle around with stuff like our log2ram implementation showing lots of room for improvements)

Oh, I'm also very much interested in reliable operation and one of the key aspects with SBC is reducing wear on flash media like SD cards since at least I (being a low consumption fetishist) want to put the rootfs on energy efficient flash storage and not more 'wasting' SSD or HDD storage. @Fourdee's 'Why DietPi is better' list http://dietpi.com/phpbb/viewtopic.php?f=9&t=2794 shows at least one very dangerous misunderstanding about Linux' VM / page cache implementation but at least that explains his strange conclusions in his Tests 1) and 4). While this is only dangerous for DietPi users it's a bit tough not trying to explain why 'dirty pages' do NOT 'show wait times, before the requested memory data can be written to disk. This generally means bottle-necking has occurred and the overall system performance will be effected until the data is written'. In contrast dirty pages are exactly what we want to reduce wear on flash memory and result of our way larger commit interval at the fs / block device layer. Same with the comparison of the log attempts... once DietPi users switch to full logging (rsyslog + logrotate) their flash media is at risk while it's possible to combine rsyslog + logrotate + logs in RAM. Speaking of that: Do you have an opinion on improving log2ram? https://forum.armbian.com/topic/6626-var-easily-get-full-with-log2ram/?tab=comments#comment-50286

I was more talking about bundling all this compiler stuff with default installations. Just a quick check which packages consume most space as already done a year ago: Edit: This is how it looks like with DietPi on Rock64:

Oh, just found this: http://dietpi.com/phpbb/viewtopic.php?f=9&t=2794 (archived version) -- this is a really funny compilation

No, you're using a crippled Armbian image called DietPi. Support is over there: http://dietpi.com/phpbb/index.php

No, there are a lot more but all of this doesn't really matter especially here in this forum. And the whole issue (people using this crappy tool called sysbench trying to benchmark hardware) is not even related to 32-bit vs. 64-bit but different compiler switches. Raspbian packages are built for the ARMv6 ISA so they can be executed on the horribly outdated single core RPis as well. Normal Debian/Ubuntu armhf packages are built for ARMv7 and you would need to switch to arm64 packages since only these packages are built with support for ARMv8 CPU cores (that's what's inside RPI 3 and 2 in the meantime). So comparing an OPi Win running an arm64 Ubuntu or Debian distro with an RPi 3 running any recent Arch, Gentoo, Fedora, OpenSuSE or even an arm64 Armbian (see my link -- I did this) you will see sysbench numbers that are pretty close. Numbers between the different distros will vary since the distro packages are built with different compiler versions and switches. And this is all the lousy sysbench tool in 'cpu test' mode is able to report since this whole test is just calculating prime numbers inside the CPU caches (and as soon as an ARMv8 CPU is allowed to run ARMv8 code this gets magnitudes faster). I don't know of a single real-world use case that would correlate with this pseudo benchmark (except of course if your job is calculating prime numbers, then you can rely on sysbench and if you're running on a RPi 3 should better stay away from Raspbian, DietPi and the other ARMv6 dinosaurs) But while sysbench is wrongly reporting an RPi 3 (or an OPi Win if you choose Xunlong's Raspbian images!) would be magnitudes slower than any of the recent ARMv8 boards with one specific workload the RPi 3 is really magnitudes slower (AES encryption -- think about VPN and disk encryption). Broadcom forgot to license ARMv8 crypto extensions so any other 64-bit (ARMv8) SBC is a better choice than RPi 3 if it's about AES (except ODROID-C2 and NanoPi K2 since their Amlogic S905 suffers from the same problem). See the numbers here: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 (OPi Win scores the same as Pinebook)

You have been fooled three times the RPi uses the most crappy way to be powered (Micro USB), your board is undervolted (input voltage dropped below 4.63V) and therefore frequency capping happened. While you think you run a board capable of 1200 MHz the RPi 'firmware' decreased the CPU clockspeeds and you run at 600 MHz. If you replace your PSU and/or cable between PSU and board your RPi 3 will need 110 seconds when you repeat the test the RPi 3 when used with an incapable distro (Raspbian or DietPi for example) can not show its full potential. The RPi 3 has an ARMv8 SoC but with those strange distros it has to run ARMv6 code. As soon as you switch to a better distro your RPi 3 will finish the same sysbench 'benchmark' in 7 seconds sysbench is not a general purpose benchmark but a bad joke. It can not be used for any architecture comparisons since it's only a compiler benchmark and it's impossible to benchmark the hardware with it. Depending on which distro you use the 'performance' can vary by 15 times as you already observed. Sysbench is only used by clueless people or marketing guys BTW: you're not alone. The majority of RPi 3 boards doing heavy stuff runs frequency capped (that's the nice thing with Raspberries. As soon as you would need the CPU power it clocks down to 600 MHz). Some more details: https://github.com/bamarni/pi64/issues/4

I really hope ArmbianIO spreads widely. And relying alternatively on /proc/device-tree/* might help with user adoption. For example once DietPi users start to use ArmbianIO it could be surprising that ArmbianIO only works on approx half of the boards DietPi 'supports' (since DietPi relies on Debian OS images found somewhere or uses Armbian's build system to create crippled Armbian images with the DietPi menu stuff on top sold then as 'DietPi' to their users -- so if their OS images started as Armbian there will be /var/run/machine.id... otherwise not). BTW: In Armbian for all the Allwinner boards that run legacy kernel we tried to use exactly the same string as /proc/device-tree/model to let this method work regardless of legacy or mainline kernel. Since other projects out there (H3Droid, RetrOrangePi, Lakka) also use our fex files they should become compatible to this 'other fallback' too (at least that was my intention behind these adjustments made a while ago). Some details: https://tech.scargill.net/banana-pi-m2/#comment-27947

BTW: I tested through a variety of other OS images the last weeks/months and since some of those have been recently re-released I gave it a try again today. Just as an example how important appropriate settings are if you want to squeeze out the max out of your hardware. The following is 3 times exactly the same hardware (HC1 with same SSD as /dev/sda1, same SanDisk Extreme Plus with the OS on, same Gigabit network, same MacBook as client). It's even exactly same Debian version (latest Jessie) and also exactly identical Samba version. Why the performance differs that much is explained here in detail. The first distro tested uses an outdated 3.10 kernel, doesn't take care about IRQ affinity or any other relevant settings (except cpufreq scaling) and also uses default (AKA bad) Samba settings. The second distro is the one the first is based on. Same kernel but different cpufreq settings. Obviously also no further optimizations but here OMV has been installed with armbian-config/softy by me which explains the much better SMB write performance The 3rd is latest official OMV 3 image based on Armbian and our next kernel branch so using a rather recent 4.9 LTS kernel soon to be switched to 4.14 (tweaks explained here) Disclaimer: The dietpi and Meveric numbers were made a few weeks ago and I couldn't believe that they were that low. But today I did a quick re-test (only one run since it takes ages due to that low performance) and so I decided to publish results. Please be aware that these Samba tests were made with a MacBook running macOS as client which does not show best possible performance (for reasons see here for example -- it needs a more recent Samba version with special settings to perform optimal with macOS clients) so most probably in real-world scenarios and with Windows as clients performance differences might not be that huge and overall SMB performance higher with the non OMV images. BTW: SMB write performance with dietpi increased by 6-7 times as expected just by adding the usual 4 simple lines with some adjusted settings to smb.conf. Edit: And 'use sendfile = yes' might also make a real difference, see posts below. Won't test with dietpi again since already deleted.

Honestly I really don't trust that much into those internal readouts anyway. But back on topic, you're talking about a case responsible for lower temperatures now. But isn't the main difference now that your NEO2 is wearing FriendlyELEC's heatsink while it had no heatsink before? In case that's different now I would be interested how temperatures look like without case. I just worked on providing clean and performant OMV images for ARM boards relying on Armbian's Debian Jessie flavour [1] since almost all available OMV images I found were more or less horrible (using shitty kernels and crappy settings). Settings matter a lot on those slow ARM boards, if you choose the wrong ones (or rely on distros that 'optimize'/'tune' only irrelevant stuff like DietPi for example) NAS performance might drop drastically. And I posted the links above for a reason: since it's easy to get which settings are important by studying the respective install scripts. [1] since when trying to install OMV on Ubuntu it can't work due to dependency mismatches -- that's why you find so many reports on the net of 'OMV does not work on Armbian' since people don't understand that it's either Debian or Ubuntu what they run.

Just for the record the methods DietPi collected over time here and there (they're not using Network Manager since 'bloated' and replace configuration with their own menu driven tools). At various places this here will be added on all their images: echo -e "options 8192cu rtw_power_mgnt=0" > /etc/modprobe.d/8192cu.conf echo -e "options 8188eu rtw_power_mgnt=0" > /etc/modprobe.d/8188eu.conf echo -e "options 8189es rtw_power_mgnt=0" > /etc/modprobe.d/8189es.conf echo -e "options 8723bs rtw_power_mgnt=0" > /etc/modprobe.d/8723bs.conf Then this will be added to the wlan0 entry in /etc/network/interfaces wireless-power off And finally there's a service /etc/systemd/system/wifi_disable_powersave.service containing this (which is responsible for turning powermanagement off in case of AP6212[A]): [Unit] Description=Disable WiFi power management After=network.target network-online.target [Service] Type=simple RemainAfterExit=yes ExecStart=/bin/bash -c 'sleep 20;iwconfig wlan$(sed -n 2p /DietPi/dietpi/.network) power off [Install] WantedBy=multi-user.target So it's a whole load of attempts to disable powermanagement in any case (which is not what we want since there are use cases where activated powermanagement makes sense), on AP6212[A] equipped boards it's one single iwconfig call that does the job which is essentially what Armbian tries to do too: https://github.com/armbian/build/blob/master/packages/bsp/h3consumption#L255-L273 @CliffB can you please provide output of 'sudo armbianmonitor -u' so that we can get a clue what's going on?

To elaborate a final time on this (and why that's related to improved support situation). Armbian is the only distro around able to provide such a service to users. No vendor OS image can do that (since it's in their interest to hide design flaws like Micro USB for DC-IN that are part of their 'calculation' encouraging users to underestimate device costs since they think they could use their old phone charger) No 'vendor community' derived OS images will do this (since those vendor communities usually behave somewhat strange) No other distro supporting more than a few devices simply don't give a sh*t about low level issues since they only fiddle around in userland and blame the underlying build system if stuff happens (DietPi). Especially people struggling with Micro USB powered boards won't get it immediately that their powering is insufficient (since 'works with my Raspberry Pi' which is almost never true, it's just Raspberry Pi firmware masquerading the problem due to under-voltage detection circuitry there and downclocking everything) but instead of discussing this for no reason over and over again let Armbian simply not boot on such devices. If they're confident that Armbian is at fault... well then they should simply use another distro (and flood the respective vendor forum with instability babbling). Once they learned that there's something wrong with powering after fixing that they'll come back anyway. But in the meantime unnecessary discussions are avoided or happen where they should happen anyway (vendor forum).

You can't and that's fine since no one needs ELAR branded OS images where people manually fiddled around. Armbian's approach is different (creating images ALWAYS from scratch and therefore 'documenting' every necessary step or let's better say every single step done in form of scripts and templates in the build system). @Igorcompare the situation with DietPi here, it's essentially the same but this time the results are 'ELAR images' or something like that.

And all of this just to help someone else push out another DietPi image: https://github.com/Fourdee/DietPi/issues/822 SUSE's Andreas Färber started with an initial combined S500+S900 patchset: http://www.cnx-software.com/2017/03/24/cubieboard6-development-board-powered-by-actions-semi-s500-processor-comes-with-sata-lipo-battery-support/#comment-540618 (at v3 now: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/490420.html) I would neither touch Cubieboard6, any of the 3 other boards or any of those legacy kernel variants and consider these S500 boards broken by design in the meantime. And if there happens something upstream then think about it again...

Forget about /proc/cpuinfo, memory size or any generic attempt. It can only be solved using software and it depends on you flashing the right OS image to the appropriate device (using correct fex or device tree stuff or not altering armbian-release file). With Armbian we took care that devices are 'named' identically regardless of which kernel is running (by adopting machine names in fex file on Allwinner boards to the ones used by upstream kernel maintainers): http://tech.scargill.net/banana-pi-m2/#comment-27947 Please note, that this only works with legacy kernel when Armbian's fex files (script.bin) are used (we did this to allow 'consumers' of our build system to also benefit from this, eg. DietPi OS images for H3 boards or RetrOrangePi and maybe Lakka too). But if Armbian is already a requirement it's also possible to just check a single file: root@orangepiplus2e:~# cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=orangepiplus2e BOARD_NAME="Orange Pi+ 2E" VERSION=5.27 LINUXFAMILY=sun8i BRANCH=dev ARCH=arm IMAGE_TYPE=stable With mainline kernel it's just checking /proc/device-tree/model given the correct DT is used (not always the case even with Armbian since just a few weeks/months ago we shared DT configurations between different boards so when using Armbian relying on contents of /etc/armbian-release is always the best choice). Please see also:

Well, some distro makers like eg. DietPi folks even recommend this ('less hassles' or something like that IIRC) But I somewhat agree especially when having SinoVoip folks in mind (on some of their new OS images they ship with adb 'root backdoor' but since this requires physical access it's not worth that much thoughts anyway). Regarding a fix for the flaw please keep in mind that when your image is not using Armbian's apt repo to update the kernel at least longsleep's update scripts should work (SinoVoip of course put their stuff in a different location so that even if they use longsleep's kernel... updating it won't work -- stupid as usual). And even if you fix this now I wouldn't expect SinoVoip to follow. They're happy to provide OS images for each and every device they have that are vulnerable (numerous well known root exploits available). They don't give a sh*t about security anyway, not even on their 'routerboard' R1 that is supposed to be directly connected to the Internet.

Sure, just use DietPi. WiFi does not work there but at least it's insecure. For details please refer to the comments below: http://tech.scargill.net/the-orange-pi-zero/ If you want working Wi-Fi simply use 'sudo nmtui' with your normal account and in case you want to do everything as root better choose Raspbian or DietPi and forget about Armbian (we won't support totally insecure setups)

Folks, please let's start to use this forum in a productive way. It's not about Armbian but about collecting knowledge and joining development efforts. What about posting a simple tutorial how to create an OpenWRT image based on Armbian? Next step: suggestion how to 'mis-use' Armbian's build system to produce 'foreign' OS Images? We currently support +40 SBC with our build system. And we *CARE* about settings and squeezing the max out of the boards unlike other projects (DietPi as a negative example). And when you look around the wheel gets reinvented every second. OpenWRT is one example, Kali Linux or Volumio are others. So sad.

No, I don't think so at least regarding NEO PCB rev. 1.1 and Air (with NEO 1.0 I experienced deadlocks at 1200 MHz with heatsink but I would assume that was caused by U7 -- for details see https://github.com/Fourdee/DietPi/issues/477). Now with the PCB changes on NEO and Air using the devices with or without heatsink shouldn't be an issue since throttling will work correctly (of course you get lower performance under full load without heatsink applied). Thank you both for the numbers. But I asked also for different stuff before: How a typical sysbench run looks like when Air is set to 1200 MHz