Igor

Not an Armbian problem. https://wiki.x2go.org/doku.php/doc:installation:x2goserver

Temperature is absent on this particular board because the driver for the sensor for Allwinner A83T, which is on this board, is not developed, ported yet. Kernel does not supply temperature to the application. Any application. Any operating system: Debian, Ubuntu, ArchLinux, WhateverLinuxDistributionOuthere, ... Edit: perhaps this temp sensor works on Android/stock 3.4.y kernel which you want to avoid on all cost. Great to hear! Now you can play, test, wait for this to be solved or help.

There is nothing to install. It has to be developed. Something like this has to be added to the kernel code, recompile, test, adjust, test ... For you/end user it will just show up one day after a kernel upgrade that this will be fixed.

I usually buy on Ebay & Aliexpress but this time in the year is not the best time For an experiment, improvisations as such might help. I assume you have plenty of coins?

Which you can use until they provide ARM binaries. This goes on the advanced level, far away from Armbian. Check this: https://www.howtoforge.com/tutorial/how-to-install-php-7-on-debian/ I am not sure anyone can help you here. Better try here: https://www.ispconfig.org/support/

I am not sure this part of the script - rebuilding packages - were tested in anything that native environment. Not sure for Vagrant, but for Docker this is disabled out of the box: [ warn ] EXTERNAL_NEW=compile is not available when running in container, setting to prebuilt It works for me on KVM host. If there are no issues, sure, why not. I hope all our patches also apply?

We provide minimal (and optimised for boards with low resources) XFCE based desktop out of the box. If there are no images, you need to enable/install this desktop from armbian-config. Since situation with ARM and with single board computers is special, userspace and the desktop is last thing that matters. If you don't heavily deal with the kernel, your board function will be very poor. Mainstream distribution doesn't deal with boards like Bananapi M3. They rely on www.kernel.org which is up to one year behind our kernel. Some functions might never be accepted and some default board settings are off by default. IMO one 20x20x** on the CPU should do ... but when proper thermal throttling is implemented, this will be needed only for getting better performance since CPU will drop frequency automatically when certain temp is reached. This is not working ATM ... and desktop environment is pretty irrelevant if things as such doesn't work. For power supply, do some measurement how is the with the voltage under the load. Sometimes there are problems with Bananapi company recommendations.

Implemented on the build level, but for updating the repository ... we don't update boot scripts via packages updating, at least not out of the box. This part has to be done manually atm by replacing the boot script. Thanks!

This is the best what exists and we are aware its not done yet. That's why there is still only a DEV version, labelled testing and it does not receive support. The only other option is kernel 3.4.x based stock images which other problems. It probably hangs due to power related problems - make sure you have a solid power supply, heat sink. If that doesn't help, limit max. cpu frequency to 1400000 in/etc/default/cpufrequtils and reboot or restart the cpufrequtils service. No other OS out there will give you better results.

Manuals are a bit poor in this area and we also have a few different ways to cope with this problem. Check this: https://github.com/armbian/build/tree/master/packages/extras-buildpkgs It was developed by @zador.blood.stained so my assistance is on basic level. Old dirty (deprecated to be) way: https://github.com/armbian/build/blob/master/packages/extras/mt7601.sh I am reworking basic packaging system (in this branch) to be able to have per board or per family compile/scripting/packing and to solve some of the problems present in a current situation. If you get the problem compilable on the board and make a human readable bash script out of this it's already a big step.

At least 10000A will not solve the problem. Start reading here: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ to understand the problem and proceed to @Seasalt advice/hack.

I am running ISPconfig on Armbian for almost a decade and would never 1 2 ... think to use Dietpi for anything like this. Stock Debian or Ubuntu on x86 or Armbian on ARM based hardware. On Armbian you have ISPconfig installer integrated in armbian-config with fairly recent test install. This one could also work, but I didn't try it. When you get an idea to run many complex suites at once (ISPconfig + OMV for example), you need to use some virtualisation or you will get crazy.

You can try to do research in this direction: https://docs.armbian.com/Hardware_Allwinner/#how-to-reconfigure-video-output Try also beta kernels, DEV branch with latest 4.19.y kernel. In any case it will not be a copy/paste operation. It might require kernel hacking. Cubietruck support is not on the Raspberry Pi3 level. If something works there, especially in video section, its usually completely different and it might not work.

From the download section? Those were tested and confirmed working on a few boards. Can you try again with another SD card and provide your board revision number.

It looks like the problem is with aptly. Do you have updated script? I fixed this last week. https://github.com/armbian/build/commit/a4e4d561680f1e88e399ba4a5587ad186981117b

That script severely cripples the system and security of the system, kill optimisations and install spyware. Once you do that, you lost all of our support. It is worth to do that to be able to install some software from the menu driven utility? Rather type "softy" on a clean Armbian. If your desired app is not there, make use of those superb instructions for installing software they best and cleanest way possible: https://www.digitalocean.com/community/tutorials Your system will run optimally (not "optimally") and without anyone checking on you.

You can skip board makers from this. They would like to give you full blown Linux supported distro, but they can't deliver that. Rockchip is little more to blame if anyone. They were promising 3399 opensourceness and they are trying but they also can't do this alone. Linux is a community project per se. It's too big task for a few engineers which are working on Linux kernel. Their main focus is providing Android which nobody cares if it is not open source. 3399 is actually very well supported if you compare to other chips and it takes time that all boards features works at their maximum performance. Video acceleration is a complex hack and in some/most cases support is done via closed library. Since you are mentioning Nvidia: Without community work, you could only "enjoy" crippled buggy "deploy and forget" images (not a Linux distribution) that come from the board maker's labs and community repackers. FriendlyARM's work support is actually good, one of the best in the industry. They can't support end users - we also can't - except "as is" on forum. If you would send me a technical question an email/PM, you will most likely not get an answer. I stopped doing that, because day has only 24h hours and there is a huge list of people and even bigger list of problems. Most of people mix free software with free work and don't even think that they have to refund for the time wasted ... or risk to receive the same answer as Torvalds gave to Nvidia Board makers can't provide top shit Linux and don't even try. They would close their company very quickly if they would try to do that. Cost of software support is magnitude higher then making hardware. We at least try improving despite its economically unjustifiable. If this take years, so be it. Allwinner case - at the end, this is how things are done - we pay and we done. 3rd party kernel hackers company raising money and putting professionals for certain amount of time on the project to push hardest things forward in truly Opensource way. This is just a help to already vibrant community. You still need to solve all the dependencies and implement the solution. I am not dealing much in this area so I don't know how good or bad the situation is with the RK3399. This is how we done it for older RK's - it's community addition, which is at some point hopefully integrated into Armbian. Even that is hard since we extremely lack people/resources to maintain this project and cope with a 1000+ wishes which are regularly on the list.

That feature is not supported. You need to use u-boot patch to patch the u-boot board config file.

Ahaa, I just noticed it now. This (part of) script was made for our internal purposes and was never planned to be user-configurable. If you want to rework, be my guest - we can't. I don't have intention to risk breaking the whole update system.

With stock images it is certainly not working good. Only with latest kernel, 4.19.y, A64 boards get decent support.

Go to settings -> removable drives and media -> Enable "Mount removable drives when hot-plugged" and it will work as expect. I just did and its working.

Those errors are typical for under voltage. Limit CPU speed and see if that helps - nano etc/default/cpufrequtils and set MAX lower following by service restart or by rebooting.

I forgot a bit how is with this setting but go to the settings and enable it.

You mean by adding another one? That will costs you weeks of work. We have no plans to add anything there in next 6-12 months. Why would you change that key? It is used for installing additional packages via internal temporally generated repository. 1. Is used for parameters that are accepted: GPG_PASS="forsigning_kernel_u_boot_debpackages", MAKE_FULL_FIRMWARE="yes", BOOTBRANCH="v2016.01" , ... 2. no 3. no

It is. With recent kernel which in the development.