_r9

I bought this software (https://www.toonly.com/) a few months ago. With it you could make explanation videos. Maybe we can find someone that has a few hours to develop a small video which can tell the people your site of the story. Users must watch this video before they are accepted on the forum. If no one has the time for it than there are cheap offers on Fiverr. There are lots of developers which work in foreign countries were they can make cheap offerings. A customer of mine uses such videos to explain complex processes. Most people doesn't read forum documentation or instructions when they can simply ask. So to communicate this properly I suggest to force them to do a survey, watch a video or take quizzes to learn for what the Armbian Forum really is. Next problem I see is, that administrators or others are searching the web for their work with ARM based SBCs. The more they find topics on the Armbian Forum that help them the more of such people will come to this place. Therefore you should describe this once and anyone has to know this before they use this platform.

Because @guidol mentioned the German saying "Der Ton macht die Musik" I thought for myself why not making this "Bug report" a default gateway for new or even for senior users to get them to the right place. Not only for bugs. Something like "Armbians friendly assisstant", "The gateway to your answers" or more simple "Armbian Helper". I mean this is much more work and I don't know if all of my ideas are even possible to do with the software used for this forum. But I think this would prevent a lot of moderator work in the future. One could at more questions on the front page like: Issue building Issue running Issue with third party hardware (W-Lan adapter, USB soundcard and so forth) Issue with third party software (Questions like: "htop doesn't show a thing", "Messing around with iptables" or "apache2 webserver behaves wrong" I have improvement suggestions for Armbian I have a cool tutorial to show other Armbians what I accomplished with this awesome operating system ^^ I want to sell things... Others If some selects "Others" we could move the user to a forum named "Decision making" or something like that. Moderators get informed about this inquiry and can help the user to get to the right place. Automatic topic creation Another suggestion would be to add all supported or known SBCs to the end of each survey. To get this feature up and running, the form has to have the ability to create a new topic on the forum. The user can choose their board here. When they complete a survey a new topic will be created including multiple tags. SBC Name tag Supported/unsupported tag maybe the user could be enabled to add his own tags like (iptables, apache2, ram issue, ...) or choose from some predefined tags like (Security, Server, Newbie Question, ...) With this feature topics could be created logically inside the right forum and Armbian developers would be able to make fast decisions by looking at the tags and the content the users provide. Help for moderators This catalog of questions could at least serve us moderators on our daily work. New moderators could easily make their decisions about a topic by answering a few questions.

IMO, the import and export functionality is needed to export the current form, its responses and other things so you can easily change from google forms to another plugin. So this is my answer to your request: I didn't know this, so I researched and asked if there's a possibility to do that. After ten minutes of research I asked for it to prevent hours of investigation. So it wasn't really work I did here ; ) Google form is able to export the current survey and you could import all that data to another form plugin. But you can't import any .csv or other files to the plugin I suggested. As far as I can see this, you have to setup the whole form inside the new plugin. I don't know how much data/work this is and therefore I asked if it is possible to import google forms data. I don't know which benefits google forms really has to you, but with this plugin you can do any type of surveys, quizzes, ask for feedback and other things. So for the question: "Is it better or has it the same functionality then google form" my answers are: - It's self-hosted so it's not google which relates to the statement of Werner (We are also aware that using Google forms is everything but ideal but in my opinion it is a good point to start with) for me google isn't an ideal solution because google properly owns the whole Internet and this harms the freedom of the internet. ; ) - I know that the form creation is simple - I think that on this page https://eform.live/examples/ under the section "Other features" the form "Format String on Redirect URL" shows an easy example to redirect the user to the proper solution... but there are others too. - And you can easily analyse the reports (a very simple example of it attached as image) So this is my answer ; ) BTW: I have nothing to do with the development of this plugin. It only came in my mind, because I already used it, it was easy to use, self-hosted and and as far as I can see this, has any functionality that google forms used for the bug report has. Haha still sounds like bad advertising ^^

Okay, it seems to be rocket since ^^ to me it looked like if they encrypt the data that is exported. There's only one way to export the data and you can only import data exported by the plugin. (https://wpquark.com/kb/fsqm/fsqm-other-features/importing-and-exporting-fsqm-forms/) On the other hand, with google forms you can export all your data easily as a .csv file (https://support.google.com/sites/answer/9759608?hl=en) So I asked the developer of the plugin directly for help and received following answer: On my research I found another survey plugin. I'll take a closer look an that too.

I'll take a closer look into that : )

Hi @Werner a good self hosted form plugin I use in Wordpress is this one: https://eform.live/ If this is something you need I would offer you to make an extra $40,- donation to Armbian to buy the plugin.

Moved to Feature Requests because this is more like an enhancement idea then a common issue

Thanks for the solution

Moved to "Common issues/Peer-to-peer technical support"

Hi @mrjpaxton this forum is an opensource project that focuses mainly on the development of Armbian. So maybe you try your luck here https://wiki.archlinux.org/index.php/Working_with_the_serial_console But feel free to write here if you'll solve your issue ; )

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Same here. I had very good times with VNC too.

Maybe you ought to try http://xrdp.org/ A tutorial: https://linuxize.com/post/how-to-install-xrdp-on-debian-10/ VNC isn't secure. A way to secure VNC would be to tunnel the connection through SSH and such configuration is much more frustrating. XRDP on the other hand runs very smoothly on most machines, you shouldn't run into issues when you have no Display jacked in and you're able to secure the connection with SSL/TLS I'm not that experienced with XRDP or VNC but my headaches are decreasing since using XRDP ^^

Yes. But I'm not sure about all dependencies. I already described a few of them above. But if anything goes wrong you still have all configuration files and your data inside the backup. So in a worst case scenario you would need to reinstall the software you're using and simply recover the configuration files from the backup. You can recover your home directory at anytime and if you gather a few insights about the software you're using you'd be able to transfer a single application from one system to another on runtime. A research with: whereis <your-application> an the knowledge about the distribution your using (What is systemd?) gives you that ability. But for this scenario it would be more simple to install the software on the new system and transfer the configuration files from the old one. Okay long story short. If you know what dependencies the installation of Armbian creates (e.g. The UUID= inside the /etc/fstab) you can simply recover all your data with rsync using the --exclude option. It's been a long time I did this so I cannot give you a complete example but if you did the rsync backup first you'll always (in worst case manually) be able to recover your system. Another way I just remembered, if you backup the MBR of your eMMC after installing your system you'd be able to recovery the system like following. Recover the MBR first, create the system partition and recover and overwrite the partition with rsync using your backup data. So you don't need to reinstall the armbian image first. But this one is not for "on runtime" recovery approaches. I have a research project about this. I did this approach on a few banana pis in the past. Maybe you can find a few code snippets in here. Backup https://github.com/rothirschtec/ARM-backup-recovery/blob/master/RTbackup.sh Recovery https://github.com/rothirschtec/ARM-backup-recovery/blob/master/RTrecovery.sh I got lost on this backup projects because the banana pi images made me crazy. But maybe I'll restart the development. So following the projects on github might be interesting. ; )

You can simply backup your device with rsync -> https://wiki.archlinux.org/index.php/Rsync#Full_system_backup Because Armbian is Linux and Linux installs all it software as packages it doesn't depend on a registry like Windows. One big benefit that comes from this is, that you can simply make a "copy" from the whole system. Rsync, in that particular case is able to deal with symlinks and is therefore able to manage a complete image of your system. If the worst case happens and you need to setup your data on a different board you can simply recover it with these steps Write the Armbian image to the emmc disk Overwrite all the data with your rsync data You need to be aware of the /etc/fstab after a fresh installation the UUID might change. If you overwrite it with your old UUID the system might not boot again. On a full recovery you should also not overwrite following partitions "/dev/" "/proc/" "/sys/" "/tmp/" "/run/" "/mnt/" "/media/" "/boot/" To be safe you also need to save the related Armbian image to each backup. If you change, for example, from Armbian-Stretch to Armbian-Buster and you want to recover it you need to dd the image onto the SD card and overwrite it with your backup like described above. If you simply want to test configurations or new software you should in theory add a USB stick to your device and rsync the whole system to a directory on it. Please don't simply use these lines in your environment. Test such things always in a test environment ; ) Backup mount /dev/YOURUSBSTICK/ /media/usb-backups/ rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /media/usb-backups/VERSION/ Recovery rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/boot"} --delete /media/backups/VERSION/ / reboot rsync and SSH Okay now comes the best part. You can combine SSH with rsync to backup and recover your device over the network from another device. Adding this rsync to a cronjob you can create automated backups for your own without buying a backup software. The FLOSS way so to say ; ) If you're interested, I've tried to take some time off to develop a backup recovery environment in the past. It's written in bash and is still somewhat in alpha state but maybe you can find some code pieces that'll help you with your backups. https://github.com/rothirschtec/RT-Blog-SBE In the end, you get the ability to create a backup device with this script and configure it to backup multiple devices automatically.

Tested this on clearfog base, banana pi m64, banana pi m2+ ## Building and providing The elastic team doesn't provide deb packages for ARM devices. But together with docker, we're able to build the main executable for it. We will create a build directory which includes anything to install filebeat on a ARM device. So please stay inside the build directory the whole time you are using this tutorial. mkdir build && cd $_ ## Prepare source code First we will download, check and extract the source code of filebeat. Source: https://www.elastic.co/downloads/past-releases/filebeat-7-6-2 wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.6.0-linux-x86.tar.gz wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.6.0-linux-x86.tar.gz.sha512 sha512sum filebeat-7.6.0-linux-x86.tar.gz Extract and prepare tar xfz filebeat-7.6.0-linux-x86.tar.gz --transform 's/filebeat-7.6.0-linux-x86/filebeat-latest/' ## Using docker Install docker on any machine you want. We use a host with Debian Buster installed. ### Install docker on a Debian Buster x64 machine sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common wget -q -O - https://download.docker.com/linux/debian/gpg | sudo apt-key add - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian stretch stable apt update sudo apt install docker-ce Instantiate a go container for cross-compilation (Debian Buster x64) Using latest docker go image docker run -it --rm -v `pwd`:/build golang:1.14 /bin/bash Inside the "go" docker container create filebeat for arm modules.listand arm64 go get github.com/elastic/beats cd /go/src/github.com/elastic/beats/filebeat/ git checkout v7.6.0 GOARCH=arm go build cp filebeat /build/filebeat-arm GOARCH=arm64 go build cp filebeat /build/filebeat-arm64 exit You can find the filebeat executeable inside your build directory. Leave it there for the moment. ## Download installation scripts I wrote an install script and collected a few files from other filebeat installations and uploaded them to github.com. You can find any information on the github repository itself. So we will clone the repository to the build directory. git clone https://github.com/rothirschtec/RT-Blog-elastic.git ## Filebeat configuration Now you have to copy the filebeat.yml so that that the install.sh we'll use later on can move it to the right place. cp filebeat-latest/filebeat.yml my-filebeat.yml and change it to your needs vi my-filebeat.yml ## Other configurations There are other configurations that might interests you. cp filebeat-latest/modules.d/YOUR_MODULE.yml.disabled my-YOUR_MODULE.yml Change this files too vi my-YOUR_MODULE.yml The install script will loop through all .yml files starting with my- and will copy them to the right direction ## Ready for installation The build directory is ready to use. You are able to upload the build directory to a ARM server of your choice and execute the install.sh there. rsync -av --exclude={".git","*.tar.gz","*.tar.gz.sha512"} ../build/ server-of-your-choice:/opt/build/ ssh server-of-your-choice cd /opt/build/ bash /opt/build/RT-Blog-elastic/install.sh rm -rf /opt/build/ ## Modules You're able to enable modules with the installation script. Create a file called modules.list inside the build directory and write the modules separated by whitespaces like iptables system apache

So I read through this thread and there are a few thoughts that came up. I believe when you want to solve a spam problem efficiently one needs to focus on the spam itself and not on the spammers. I'm dealing with lots of spam on my mailservers and manually blacklisting is the least efficient way to solve this problem. In my case 2000 - 10000 Spam mails a month. The main reasons why this is not a good practice are already described in a few posts inside this thread. Automated mail creation for example. So what are the real problems with spam posts? I think the most potential thread, if we focus on security, is that a user could get mislead to a dangerous URL. There is also the problem that the Armbian Forum could get misrelated to porn pages or other ugly stuff through google searching or other online indexes. Worst case would be if someone types porn stuff into the google search box and gets the Armbian forum as a result or someone finds a post that should help him and this post is full off ads. This would harm the forums image. So IMO the real problem is related to the URLs the spammers uses. So maybe there's a function like "URL registering"? So if a user wants to add a URL which is not known by Armbian he needs to register it with a small form or so and a moderator needs to approve the URL. Another concept could be that posts with unknown URLs needs to be approved even if they are changed after a while. So the system needs to run the approval recognition not only on new posts but on each change to. What's with the existing spam URLs? I don't know if such functions exists but if we could run through all posts with URLs (maybe inside the database) and disapprove all posts with unknown URLs then we have a list we can score. Moderators would need to approve all this posts again and register the URLs if they are valid. Maybe we should do this with a small amount of posts each. So we would need a function like "disapprove the first 100 posts with unknown URLs". May be we could assign each moderator a few posts automatically so he can approve 10 posts a week or so. 11 Moderators would solve 110 posts a week. I don't know how big the problem is but the year has 52 weeks so we could to a lot of work without really doing anything. I'm absolutely new to this forum so maybe this is all nonsense but hiring volunteering spamfilters does not seem to be the smart way.

Hi Igor, it would be an honour to help you on your project. I highly respect this forum and I'm really interested in ARM Technologies and Debian based distributions. My hat's off to the guys at Armbian to manage a huge project like this Besides that I'm using SBCs for server solutions another attempt to get a deeper look into ARM technology was to deal with Banana Pi products on Amazon. This attempt cost me a lot of time and in the end I almost lost my company too. The product line of SinoVoip or Bipai Keji (HK) Limited got messier each month. After they fired my main supporter anything got worse. Since then I'm seeking for a new opportunity for my company to get a footstep into the ARM world. Especially the Armbian Forum. I ceased the Amazon sales last week. Therefore I have a few hours left each week for a new project. So the time would be perfect to support an opensource project. If you're interested, I'd looking forward to get to know each other on the Armbian Forum. What might interests you as well is that I worked as a first level supporter, almost for elder people, for 3 years. So I know my place if something gets out of control and people gets angry or confused. The only problem I may see is if you need moderators with short reaction times or too much hours each day. I think I can handle work like once, maybe twice, a day for something around an hour or so - 12/5. I'm looking forward to read you Best Regards, _r9

@lex yes this file exists on both devices with following content cat /sys/class/hwmon/hwmon0/name f1072004mdiomii00

Hey guys, thanks for helping me out and sorry for the late response. I checked the thermal_zone as @guidoldescriped cat /sys/devices/virtual/thermal/thermal_zone0/temp 84164 I also checked the link inside _/etc/armbianmonitor/datasources_ ls -l total 0 lrwxrwxrwx 1 root root 47 Aug 28 10:40 soctemp -> /sys/devices/virtual/thermal/thermal_zone0/temp It's all the same on the Clearfog pro as it is on the Clearfog base @lex I cannot find a value like *temp[0-9]_label* But maybe this output can help find /sys/devices/ |grep temp[0-9] /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:0f/hwmon/hwmon7/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:04/hwmon/hwmon6/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:02/hwmon/hwmon4/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:00/hwmon/hwmon2/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:03/hwmon/hwmon5/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:04/mdio_bus/mv88e6xxx-0/mv88e6xxx-0:01/hwmon/hwmon3/temp1_input /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_max_alarm /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_crit /sys/devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0/temp1_input /sys/devices/virtual/thermal/thermal_zone0/hwmon1/temp1_input @Igor I have also noticed that the *CpuFreq[1-9]: ... MHz* section is missing in the htop frontend too, on all of my _Clearfog Pro_ devices When I open up the /usr/bin/htop it looks like that there you can see the hardcoded files u: ^@^@^@show processes of a single user^@ H: ^@^@^@hide/show user process threads^@^@ K: ^@^@^@hide/show kernel threads^@^@^@^@ F: ^@^@^@cursor follows process^@^@ F6 + -: ^@^@^@expand/collapse tree^@^@^@^@ P M T: ^@^@^@sort by CPU%, MEM% or TIME^@^@ I: ^@^@^@invert sort order^@^@^@ F6 > .: ^@^@^@select sort column^@^@Environment of process %d - %s^@^@Could not read process environment.^@Refresh^@"^@^@^@/sys/class/thermal/thermal_zone0/temp^@^@^@/sys/devices/virtual/thermal/thermal_zone0/temp^@/sys/class/hwmon/hwmon0/temp1_input^@/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_cur_freq^@^@/sys/devices/platform/soc/7081400.i2c/i2c-0/0-0036/regulator/regulator.1/microvolts^@/sys/devices/platform/soc/1f02400.i2c/i2c-4/4-0065/regulator/regulator.5/microvolts^@/sys/devices/platform/ff3c0000.i2c/i2c-0/0-001b/regulator/regulator.12/microvolts^@^@^@/sys/devices/platform/ff3c0000.i2c/i2c-0/0-0040/regulator/regulator.9/microvolts^@^@^@^@/sys/devices/system/cpu/cpu%d/cpufreq/cpuinfo_max_freq^@^@/proc/uptime^@^@^@^@%64lf^@^@^@/proc/loadavg^@^@^@%32lf %32lf %32lf %32d/%32d %32d^@^@^@^@/proc/sys/kernel/pid_max^@^@^@^@/proc/%d/environ^@^@^@^@ 0 Cancel^@^@^@ 1 SI The following files are available cat /sys/devices/virtual/thermal/thermal_zone0/temp 66548 cat /sys/class/hwmon/hwmon0/temp1_input 62000 cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq cat: /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq: No such file or directory This is all exactly the same on my Clearfog Base. But now I can see that on the Clearfog Base the CpuFreq is 0 Mhz. So the issue changed to Clearfog Base: Shows 0 MHz because the hardcoded files are missing Clerafog Pro: Doesn't show that sections at all. It looks like this htop doesn't have this features at all Aaaaaahhhhhh!!!! Ok inside htop on the Clearfog Pro's I had to configure the Frequency and Temperature. Solution Enter htop Press F2 Another Update On my Clearfog Pro does the file **/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq** exist and its content switches between 800 and 1600 this is shown in htop On the Clearfog Base is the whole directory **/sys/devices/system/cpu/cpufreq/** empty

That's really an open minded extension for htop. Fast and simple! I've recognized an issue with temperature on my clearfog pro with Debian buster and stretch. Clearfog Base (Debian Buster) works htop version buster: 2.2.0-3~armbian5.92+1 bpi-m64 (Debian Buster) works htop version buster: 2.2.0-3~armbian5.92+12.1.2-3 bpi-m2+ (Debian Stretch) works htop version stretch: 2.1.2-3 Clearfog pro (Debian Buster and Stretch) doesn't work on a stretch and a buster installation htop version buster: 2.2.0-3~armbian5.92+1 htop version stretch: 2.1.2-3

Upgrade on a Banana Pi bpi-m2+ and on a Solid-Run Clearfog base also works like a charm I had a problem with my iptables rules. Buster changes the system to use nf_tables or so. I had no time yet to look deeper into this. So for whom that needs the iptables rules, you can switch back to iptables. update-alternatives --set iptables /usr/sbin/iptables-legacy

@Igor Thanks for the work. Struggled around with an Icinga2 installation on a bpi-m64 with stretch. Upgraded to Debian Buster, installed the Icinga2 package from within the Debian repositories and everything works : )

I summarized the content of a few sites and wrote a complete installation guide for Armbian on a Clearfog pro and Clearfog base. You will need a FAT formatted USB Stick where you can store the Armbian image and some bootloader files an USB A to microUSB B cable Clearfog Base or Pro with a power adapter Prepare installation files mkdir -p /opt/clearfog_installation cd /opt/clearfog_installation curl https://wiki.solid-run.com/lib/exe/fetch.php?media=products:a38x:software:debian:clearfog-emmc-v3.tar.gz --output clearfog-emmc-v3.tar.gz tar xfz clearfog-emmc-v3.tar.gz Copy following files to an USB stick mnt <your usb> /mnt/ mv u-boot-clearfog-base-mmc.kwb zImage armada-388-clearfog.dtb /mnt/ Put Armbian to the stick You have to create the _extlinux_ directory and put the _extlinux.conf_ into it. You'll need this do boot a linux image. With it you will be able to write the Armbian image to the eMMC memory mkdir -p /mnt/extlinux mv extlinux.conf /mnt/extlinux/ cd /mnt/extlinux/ Clearfog Pro wget https://dl.armbian.com/clearfogpro/Debian_stretch_next.7z Clearfog Base wget https://dl.armbian.com/clearfogbase/Debian_stretch_next.7z Extract and check integrity 7za e Debian_stretch_next.7z shasum -a 256 -c sha256sum.sha Armbian_*.img STRG+c cd /opt/clearfog_installation umount /mnt Next Steps Plug in USB stick to the Clearfog Plug in USB cable (USB A site) to the PC Plug in USB cable (microUSB B site) to the Clearfog Set Jumper to UART **0 1 0 0 1** PC The maintainer delivers *kwboot* for the installation. With it you can send the u-boot bootloader to the device ./kwboot -t -b u-boot-clearfog-base-uart.kwb /dev/ttyUSB0 Clearfog - Power up the Clearfog - Wait a few minutes of the U-Boot image to download - !! Hit a key to stop autoboot !! - Configure the eMMC to boot from hardware boot partition PC (kwboot terminal) mmc partconf 0 1 1 0 date reset run bootcmd_usb0 login with _root_ mount /dev/sda1 /mnt dd if=/mnt/extlinux/Armbian_5.59_Clearfogpro_Debian_stretch_next_4.14.66.img of=/dev/mmcblk0 bs=1M conv=fsync hdparm -z /dev/mmcblk0 umount /mnt/ mount /dev/mmcblk0p1 /mnt/ echo 0 > /sys/block/mmcblk0boot0/force_ro dd if=/mnt/usr/lib/linux-u-boot-next-clearfogpro_5.59_armhf/u-boot.mmc of=/dev/mmcblk0boot0 sed -i 's/emmc_fix=off/emmc_fix=on/g' /mnt/boot/armbianEnv.txt umount /mnt/ poweroff PC (a second terminal) killall kwboot screen /dev/ttyUSB0 115200 Clearfog Unplug power adapter Set jumpers to **0 0 1 1 1** Plugin power jack Now you should see Armbian booting up in the terminal were you executed the _screen_ command Sources First insights (armbian.com) Maintainers installation guide (wiki.solid-run.com) First hint for armbian bootloader installation (armbian.com) Final Armbian bootloader installation hint