TDCroPower

After several weeks of testing and trying I finally put my Helios64 into production. With the 20.08.10 and the possibility to run the firmware over the eMMC I can finally sleep more calmly again. The front view mounted: The back view connected: And to prevent my wife from killing me because there is a lighting party going on in the hallway I taped the front LEDs with insulating tape... And for all who have problems with the included USB-C cable at the USB-C port of the Helios64. You have to remove the plastic so that the connector looks like this... The black plastic of the USB-C cable must NOT touch the backside of the Helios64, this ensures that the Cable is 100% plugged in.

yes I have. I started it via armbian-config >>> System >>> Install >>> "2 Boot from eMMC - system on eMMC", but it is the same script that is behind it. Before that I installed OMV and Docker natively on the system and pihole, unifi controller, iobroker and emby server as container. @antsu you are probably right, because under /srv I cant't find my OMV -> SMB Shared Folders... root@helios64:~# ll /srv/ total 0 root@helios64:~# i try to boot from the microSD again to save the 2 directories. You should tell the armbian team or the dev of the nand-sata-install script. I think you can do this via their Jira ticket system? edit: unfortunately I did not manage to boot from the microSD again. Does anyone know how to switch from eMMC boot to microSD boot? Solution: with this mount command... mount /dev/mmcblk0p1 /mnt ... you can have access to the microsd files under /mnt... root@helios64:~# ll /mnt/ total 96 lrwxrwxrwx 1 root root 7 Aug 30 20:55 bin -> usr/bin drwxr-xr-x 3 root root 4096 Oct 15 16:47 boot drwxr-xr-x 2 root root 4096 Oct 5 16:04 dev drwxr-xr-x 108 root root 12288 Oct 15 16:49 etc drwxr-xr-x 2 root root 4096 Sep 22 02:38 export drwxr-xr-x 3 root root 4096 Oct 6 02:24 home lrwxrwxrwx 1 root root 7 Aug 30 20:55 lib -> usr/lib drwx------ 2 root root 16384 Oct 5 16:17 lost+found drwxr-xr-x 2 root root 4096 Aug 30 20:55 media drwxr-xr-x 4 root root 4096 Oct 15 16:48 mnt drwxr-xr-x 4 root root 4096 Oct 14 01:18 opt drwxr-xr-x 2 root root 4096 Jul 10 23:04 proc drwx------ 5 root root 4096 Oct 14 01:39 root drwxr-xr-x 2 root root 4096 Oct 5 16:13 run lrwxrwxrwx 1 root root 8 Aug 30 20:55 sbin -> usr/sbin drwxrwxr-x 2 root root 4096 Oct 5 16:05 selinux drwxr-xr-x 2 root root 4096 Sep 22 02:38 sharedfolders drwxr-xr-x 6 root root 4096 Oct 15 16:39 srv drwxr-xr-x 2 root root 4096 Jul 10 23:04 sys drwxrwxrwt 2 root root 4096 Oct 5 16:17 tmp drwxr-xr-x 11 root root 4096 Oct 6 03:22 usr drwxr-xr-x 14 root root 4096 Oct 6 03:12 var root@helios64:~# and to copy the two directories back into the /srv directory just use the following two commands... cp -r /mnt/srv/pillar /srv cp -r /mnt/srv/salt /srv ... and after an reboot its back... root@helios64:~# ll /srv/ total 16 drwxr-xr-x 10 root root 4096 Oct 15 16:40 dev-disk-by-label-nas drwxr-xr-x 2 ftp nogroup 4096 Oct 6 03:06 ftp drwxr-xr-x 3 root root 4096 Oct 6 03:05 pillar drwxr-xr-x 5 root root 4096 Oct 6 03:05 salt root@helios64:~#

The new firmware 20.08.10 is finally available via apt-get... root@helios64:~# apt list --upgradable Listing... Done armbian-config/buster,buster 20.08.10 all [upgradable from: 20.08.8] armbian-firmware/buster,buster 20.08.10 all [upgradable from: 20.08.8] linux-buster-root-current-helios64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-dtb-current-rockchip64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-image-current-rockchip64/buster 20.08.10 arm64 [upgradable from: 20.08.8] linux-u-boot-helios64-current/buster 20.08.10 arm64 [upgradable from: 20.08.8] openmediavault-omvextrasorg/buster,buster 5.4.1 all [upgradable from: 5.4] root@helios64:~# As soon as my copy of my backup to my new RAID5 is finished I will update and test the part with the eMMC right away! edit: Perfect, the update went through cleanly and installing/booting from eMMC now works without problems. _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 20.08.10 Buster with Linux 5.8.14-rockchip64 No end-user support: work in progress System load: 28% Up time: 1 min Memory usage: 8% of 3.71G IP: 192.168.180.5 CPU temp: 41°C Usage of /: 45% of 15G Last login: Thu Oct 15 16:47:49 2020 from 192.168.180.83 root@helios64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.8G 0 1.8G 0% /dev tmpfs 381M 11M 370M 3% /run /dev/mmcblk1p1 15G 6.1G 7.4G 45% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /tmp folder2ram 1.9G 11M 1.9G 1% /var/log folder2ram 1.9G 0 1.9G 0% /var/tmp folder2ram 1.9G 268K 1.9G 1% /var/lib/openmediavault/rrd folder2ram 1.9G 724K 1.9G 1% /var/spool folder2ram 1.9G 14M 1.9G 1% /var/lib/rrdcached folder2ram 1.9G 12K 1.9G 1% /var/lib/monit folder2ram 1.9G 1.3M 1.9G 1% /var/cache/samba tmpfs 381M 0 381M 0% /run/user/0 root@helios64:~#

thanks for the feedback. Will be available again after about 24h via apt-get. Currently the 20.08.9 is still offered... root@helios64:~# apt list --upgradable Listing... Done armbian-config/buster,buster 20.08.9 all [upgradable from: 20.08.8] armbian-firmware/buster,buster 20.08.9 all [upgradable from: 20.08.8] linux-buster-root-current-helios64/buster 20.08.9 arm64 [upgradable from: 20.08.8] root@helios64:~# edit: the new wikis are even already online ... https://wiki.kobol.io/helios64/install/emmc/

Cool, very good news! Is a fresh install from "20.08.8" also urgently necessary or can we also upgrade to "20.08.10" with an apt-get upgrade?

i checked today and saw a new 20.08.9 in the updates. Has anything new been implemented or fixed in the new 20.08.9 that might interest us as Helios64 owners? root@helios64:~# apt list --upgradable Listing... Done armbian-config/buster,buster 20.08.9 all [upgradable from: 20.08.8] armbian-firmware/buster,buster 20.08.9 all [upgradable from: 20.08.8] linux-buster-root-current-helios64/buster 20.08.9 arm64 [upgradable from: 20.08.8] root@helios64:~# edit1: I have found 2 commits from aprayoga, have they perhaps already been implemented in 20.08.9? If so, the first one should be seen as fix for the eMMC problem, right? https://github.com/armbian/build/commit/d909a4ea723f5e3e1d1b3e7bb07a2215793725b1 (Verified) https://github.com/armbian/build/commit/bc66f9d835cb8303eb65ea55ac02da69920284f7 (???) edit2: Unfortunately there is nothing to find in the changelog about 20.08.9 yet. Is it perhaps still so fresh? https://docs.armbian.com/Release_Changelog/

I had the same problem on my Mac. But with Windows and PuTTY it works perfectly.

very good, just these 2 features are for many probably the most important to be able to set it up quickly and neatly.

because my first microSD has a satisfying image i got a second microSD today to test it. I will try to reproduce my steps to copy + boot from the eMMC. I have here still the 20.08.4 image for reference. Tomorrow I have to set up my test setup to test more effective/faster and give feedback again. @aprayoga is it true what @gprovost has written here that you have already fixed the eMMC problem and are working on a suitable Wiki? If that's true then theoretically I can save myself the test run and just wait for your update. Unless you would like to get further feedback on it.

@aprayoga Oh sorry I think there is an understanding problem. The system can always boot from the microSD! When i install everything on the eMMC with nand-sata-install and reboot it has booted from the eMMC... the microSD stays plugged in! If I shut down the system, removed the microSD and rebooted it did not boot anymore. When I plugged in the microSD and booted it again it showed me that it has mounted from the eMMC. See my post early Topic 2

Thanks for the answer. As shown in my previous posts I somehow managed to get the eMMC partition loaded and in some places this was displayed correctly. The only problem was that the microSD had to stay connected, which surprised me a bit. I'm happy to share my feedback with everyone so that we can all benefit from it. If I annoy you with this I am sorry.

Right and there the option "2 Boot from eMMC - system on eMMC". The only thing I haven't done this time is to set the jumper P11. Is it possible to do something with the file /boot/armbianEnv.txt and changing the variable "rootdev"? Because in the /boot/boot.scr the default value for "rootdev" -> "/dev/mmcblk0p1" is used and this is the partition of the microSD.

Did the team change anything about the boot variant with the 20.08.8? With the previous version I was able to boot from the eMMC with a detour and now I can't boot anymore, although the image was transferred via nand-sata-install!

Such short feedback on the new 20.08.8... Runs much better/stable so far. Installing OMV and Docker via armbian-config worked fine... perfect! Writing the image from microSD to eMMC with "nand-sata-install" or "armbian-config" >> System >> Install also worked, but I couldn't boot from eMMC anymore.

i will flash later the new fresh image, the image file is ready from armbian download site but not via apt-get. I have updated with „apt-get update && apt-get upgrade“ + „reboot“

I'm looking forward to see how far I notice the changes, I'm already on the "20.08.7". Is it normal that under "uname -a" the used version is not shown? Welcome to Armbian 20.08.7 Buster with Linux 5.8.11-rockchip64 No end-user support: work in progress System load: 2% Up time: 54 min Memory usage: 5% of 3.71G IP: 192.168.180.5 CPU temp: 65°C Usage of /: 16% of 15G [ General system configuration (beta): armbian-config ] Last login: Mon Oct 5 20:21:08 2020 from 192.168.180.83 root@helios64:~# uname -r 5.8.11-rockchip64 root@helios64:~# uname -a Linux helios64 5.8.11-rockchip64 #20.08.4 SMP PREEMPT Wed Sep 23 17:51:13 CEST 2020 aarch64 GNU/Linux root@helios64:~#

And unfortunately already the next problem. I couldn't start Docker successfully so far, so far all attempts to find a solution have failed. Here is the error message when I try to start Docker or the message as not successfully installed... root@helios64:~# apt-get install docker-ce docker-ce-cli containerd.io Reading package lists... Done Building dependency tree Reading state information... Done Recommended packages: cgroupfs-mount | cgroup-lite pigz libltdl7 The following NEW packages will be installed: containerd.io docker-ce docker-ce-cli 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/66.8 MB of archives. After this operation, 338 MB of additional disk space will be used. Selecting previously unselected package containerd.io. (Reading database ... 56237 files and directories currently installed.) Preparing to unpack .../containerd.io_1.3.7-1_arm64.deb ... Unpacking containerd.io (1.3.7-1) ... Selecting previously unselected package docker-ce-cli. Preparing to unpack .../docker-ce-cli_5%3a19.03.13~3-0~debian-buster_arm64.deb ... Unpacking docker-ce-cli (5:19.03.13~3-0~debian-buster) ... Selecting previously unselected package docker-ce. Preparing to unpack .../docker-ce_5%3a19.03.13~3-0~debian-buster_arm64.deb ... Unpacking docker-ce (5:19.03.13~3-0~debian-buster) ... Setting up containerd.io (1.3.7-1) ... Setting up docker-ce-cli (5:19.03.13~3-0~debian-buster) ... Setting up docker-ce (5:19.03.13~3-0~debian-buster) ... Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details. invoke-rc.d: initscript docker, action "start" failed. ● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Mon 2020-10-05 20:43:13 CEST; 41ms ago Docs: https://docs.docker.com Process: 7544 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE) Main PID: 7544 (code=exited, status=1/FAILURE) dpkg: error processing package docker-ce (--configure): installed docker-ce package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.8.5-2) ... Processing triggers for systemd (241-7~deb10u4) ... Errors were encountered while processing: docker-ce E: Sub-process /usr/bin/dpkg returned an error code (1) systemctl status docker.service root@helios64:~# systemctl status docker.service ● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2020-10-05 20:43:28 CEST; 41s ago Docs: https://docs.docker.com Process: 7953 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=1/FAILURE) Main PID: 7953 (code=exited, status=1/FAILURE) Oct 05 20:43:28 helios64 systemd[1]: docker.service: Service RestartSec=2s expired, scheduling restart. Oct 05 20:43:28 helios64 systemd[1]: docker.service: Scheduled restart job, restart counter is at 4. Oct 05 20:43:28 helios64 systemd[1]: Stopped Docker Application Container Engine. Oct 05 20:43:28 helios64 systemd[1]: docker.service: Start request repeated too quickly. Oct 05 20:43:28 helios64 systemd[1]: docker.service: Failed with result 'exit-code'. Oct 05 20:43:28 helios64 systemd[1]: Failed to start Docker Application Container Engine. journalctl -xe root@helios64:~# journalctl -xe -- Subject: A start job for unit docker.socket has begun execution -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit docker.socket has begun execution. -- -- The job identifier is 2085. Oct 05 20:43:28 helios64 systemd[1]: Listening on Docker Socket for the API. -- Subject: A start job for unit docker.socket has finished successfully -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit docker.socket has finished successfully. -- -- The job identifier is 2085. Oct 05 20:43:28 helios64 systemd[1]: docker.service: Start request repeated too quickly. Oct 05 20:43:28 helios64 systemd[1]: docker.service: Failed with result 'exit-code'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The unit docker.service has entered the 'failed' state with result 'exit-code'. Oct 05 20:43:28 helios64 systemd[1]: Failed to start Docker Application Container Engine. -- Subject: A start job for unit docker.service has failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- A start job for unit docker.service has finished with a failure. -- -- The job identifier is 2011 and the job result is failed. Oct 05 20:43:28 helios64 systemd[1]: docker.socket: Failed with result 'service-start-limit-hit'. -- Subject: Unit failed -- Defined-By: systemd -- Support: https://www.debian.org/support -- -- The unit docker.socket has entered the 'failed' state with result 'service-start-limit-hit'. Oct 05 20:43:49 helios64 avahi-daemon[1245]: Record [helios64\032-\032Web\032control\032panel._http._tcp.local IN TXT "path=/index.php" ; ttl=4500] not fitting in le Oct 05 20:43:49 helios64 avahi-daemon[1245]: Record [helios64\032-\032Web\032control\032panel._http._tcp.local IN SRV 0 0 80 helios64.local ; ttl=120] not fitting in Oct 05 20:43:49 helios64 avahi-daemon[1245]: Record [helios64.local IN AAAA 2001:16b8:2874:7500:6662:66ff:fed0:216 ; ttl=120] not fitting in legacy unicast packet, d Oct 05 20:43:49 helios64 avahi-daemon[1245]: Record [helios64.local IN AAAA fd00::6662:66ff:fed0:216 ; ttl=120] not fitting in legacy unicast packet, dropping. Oct 05 20:43:49 helios64 avahi-daemon[1245]: Record [helios64.local IN A 192.168.180.5 ; ttl=120] not fitting in legacy unicast packet, dropping. Oct 05 20:44:01 helios64 CRON[8051]: pam_unix(cron:session): session opened for user root by (uid=0) Oct 05 20:44:01 helios64 CRON[8052]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1) Oct 05 20:44:01 helios64 CRON[8051]: pam_unix(cron:session): session closed for user root

So i copy my questions from the comments area: Topic 1 -> write directly to eMMC Yesterday I tried to write directly to the eMMC and wanted to achieve this via the Recovery Mode. In the description there is no reference to the "Jumper" area that you have to set the P13 jumper to use the mode. This was the only way my Windows PC recognized anything at all, after that I had to install the appropriate driver with the help of the "RK_DriverAssitant". The matching files can be found here at github... https://github.com/rockchip-linux/tools/tree/master/windows And exactly up to here I came, now I miss the hint which image files I have to flash. With the RKDevTool you can not flash the offered image file just like that. Can you give a hint how to flash the eMMC? I could write a little instruction for you and all others how it works. Topic 2 -> install/boot from eMMC I managed to transfer my microSD image via "nand-sata-install" to the eMMC and it even boots from it see here... Welcome message with "Usage of /" -> eMMC Welcome to Armbian 20.08.7 Buster with Linux 5.8.11-rockchip64 No end-user support: work in progress System load: 2% Up time: 9 min Memory usage: 4% of 3.71G IP: 192.168.180.5 CPU temp: 52°C Usage of /: 19% of 15G Last login: Mon Oct 5 13:32:05 2020 from 192.168.180.83 my storage an SanDisk Ultra 32GB microSD (mmcblk0) and the eMMC with 16GB (mmcblk1)... root@helios64:~# fdisk -l Disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x8043f398 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 32768 61710591 61677824 29.4G 83 Linux Disk /dev/mmcblk1: 14.6 GiB, 15634268160 bytes, 30535680 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x104810f2 Device Boot Start End Sectors Size Id Type /dev/mmcblk1p1 32768 30230303 30197536 14.4G 83 Linux here you see the selected boot partition ... root@helios64:~# df -h Filesystem Size Used Avail Use% Mounted on udev 1.8G 0 1.8G 0% /dev tmpfs 381M 5.2M 375M 2% /run /dev/mmcblk1p1 15G 2.5G 11G 19% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup tmpfs 1.9G 4.0K 1.9G 1% /tmp folder2ram 1.9G 4.3M 1.9G 1% /var/log folder2ram 1.9G 0 1.9G 0% /var/tmp folder2ram 1.9G 364K 1.9G 1% /var/lib/openmediavault/rrd folder2ram 1.9G 728K 1.9G 1% /var/spool folder2ram 1.9G 13M 1.9G 1% /var/lib/rrdcached folder2ram 1.9G 4.0K 1.9G 1% /var/lib/monit folder2ram 1.9G 1.3M 1.9G 1% /var/cache/samba tmpfs 381M 0 381M 0% /run/user/0 For this I set the jumper P11, which skips the SPI Flash and switches directly to the eMMC. But to boot from the eMMC I have to leave the microSD with the image installed, otherwise the board won't start. Is there a solution to remove the microSD completely? Unfortunately the change of the rootdev variable in /boot/armbianEnv.txt did not work or did not cause anything. Topic 3 -> OMV install via armbian-config ---> FIXED Unfortunately installing OMV via "armbian-config" never works for me and always resulted in a crash of the system, so I had to flash the SD again. In the Helios4 section I read the hint from the team that it should be buggy and you should do the following... sudo apt-get remove chrony wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash with the command "apt-get remove chrony" I had to use my last image installation, because chrony did not start at startup and so the wrong date/time was stored in the system with "date". A "apt-get remove chrony" and "apt-get install chrony" fixed this. But I saw that OMV installed chrony during the installation, so I deleted chrony again as recommended and the OMV installation ran properly for the first time. Solution: Works perfectly with firmware from 20.08.8 on directly via armbian-config. Topic 4 -> USB-C Connector ---> FIXED It is not possible to connect the included USB-C cable to the USB port when the backpanel is on. The panel produces a too wide distance, so the connector does not fit 100%. So I have removed the board from the case and work without the case until the system is ready. You might want to recommend this before assembling the system, there are just too many mistakes/unclearties when you have assembled everything. Solution: You have to remove the black plastic around the USB-C plug on the supplied cable carefully by about 2mm, so that you can still see the silver contacts from the side when you plug the USB-C plug into the USB-C connector.

thank you for the tip you gave me about the docker container. I have successfully run the controller through Docker and it works perfectly. The best thing about the Docker solution, I can quickly delete or renew the "installation". docks@OrangePi:/opt/docker$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES dc14b6ce9fa3 linuxserver/unifi-controller "/init" 20 minutes ago Up 3 minutes 0.0.0.0:6789->6789/tcp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:8443->8443/tcp, 0.0.0.0:8843->8843/tcp, 0.0.0.0:3478->3478/udp, 0.0.0.0:10001->10001/udp, 0.0.0.0:8880->8880/tcp, 8081/tcp unifi docks@OrangePi:/opt/docker$

thank you lanefu for your fast answer! I have never used docker before. Is there anything I need to be aware of? How do I get the docker container, because it is mounted on my OrangePi? Here are the dependecies from unifi... Package: unifi Version: 5.12.35-12979-1 Section: java Priority: optional Architecture: all Depends: binutils, coreutils, adduser, libcap2, curl, mongodb-server (>= 2.4.10) | mongodb-10gen (>= 2.4.14) | mongodb-org-server (>= 2.6.0), mongodb-server (<< 1:3.6.0) | mongodb-10gen (<< 3.6.0) | mongodb-org-server (<< 3.6.0), java8-runtime-headless, jsvc (>=1.0.8) Pre-Depends: debconf (>= 0.5) | debconf-2.0 Conflicts: unifi-controller Provides: unifi-controller Replaces: unifi-controller Installed-Size: 164519 Maintainer: UniFi developers <unifi-dev@ubnt.com> Description: Ubiquiti UniFi server Ubiquiti UniFi server is a centralized management system for UniFi suite of devices. After the UniFi server is installed, the UniFi controller can be accessed on any web browser. The UniFi controller allows the operator to instantly provision thousands of UniFi devices, map out network topology, quickly manage system traffic, and further provision individual UniFi devices. Homepage: http://www.ubnt.com/unifi i have just tried to install unifi without the mongodb dependecies (which is deactivated by most of the instructions anyway) but even this leads to problems... [root@OrangePi:mongodb]$ apt-get download unifi Get:1 https://dl.ubnt.com/unifi/debian stable/ubiquiti armhf unifi all 5.12.35-12979-1 [99.2 MB] Fetched 99.2 MB in 23s (4,309 kB/s) [root@OrangePi:mongodb]$ dpkg --ignore-depends=mongodb-server -i unifi_5.12.35-12979-1_all.deb Selecting previously unselected package unifi. (Reading database ... 85492 files and directories currently installed.) Preparing to unpack unifi_5.12.35-12979-1_all.deb ... Unpacking unifi (5.12.35-12979-1) ... Setting up unifi (5.12.35-12979-1) ... Created symlink /etc/systemd/system/multi-user.target.wants/unifi.service → /lib/systemd/system/unifi.service. Job for unifi.service failed because a timeout was exceeded. See "systemctl status unifi.service" and "journalctl -xe" for details. invoke-rc.d: initscript unifi, action "start" failed. ● unifi.service - unifi Memory: 123.4M CPU: 50.849s CGroup: /system.slice/unifi.service ├─27510 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/java-8-openjdk-armhf -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pid…rt ├─27511 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/java-8-openjdk-armhf -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pid…rt ├─27512 unifi -cwd /usr/lib/unifi -home /usr/lib/jvm/java-8-openjdk-armhf -cp /usr/share/java/commons-daemon.jar:/usr/lib/unifi/lib/ace.jar -pid…rt ├─27546 /usr/lib/jvm/java-8-openjdk-armhf/jre/bin/java -Dfile.encoding=UTF-8 -Djava.awt.headless=true -Dapple.awt.UIElement=true -Xmx1024M -XX:+…rt └─27586 curl -s --connect-timeout 1 -o /dev/null -w %{http_code} http://localhost:8080/status Feb 19 01:40:12 OrangePi systemd[1]: unifi.service: Unit entered failed state. Feb 19 01:40:12 OrangePi systemd[1]: unifi.service: Failed with result 'timeout'. Processing triggers for systemd (232-25+deb9u12) ... [root@OrangePi:mongodb]$

Hello everyone, I need some help from the community. I would like to install the Unifi Controller on my OrangePi Plus 2e, but it requires mongodb see here... [root@OrangePi:mongodb]$ apt-get install unifi Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: unifi : Depends: mongodb-server (>= 2.4.10) but it is not installable or mongodb-10gen (>= 2.4.14) but it is not installable or mongodb-org-server (>= 2.6.0) but it is not installable Depends: mongodb-server (< 1:3.6.0) but it is not installable or mongodb-10gen (< 3.6.0) but it is not installable or mongodb-org-server (< 3.6.0) but it is not installable E: Unable to correct problems, you have held broken packages. [root@OrangePi:mongodb]$ ...but mongodb is not present in the armbian repos... [root@OrangePi:~]$ apt-get install mongodb Reading package lists... Done Building dependency tree Reading state information... Done Package mongodb is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'mongodb' has no installation candidate [root@OrangePi:~]$ I was able to install mongodb with the help of THIS manual and THESE binaries and it also starts successfully... [root@OrangePi:mongodb]$ service mongodb start [root@OrangePi:mongodb]$ service mongodb status ● mongodb.service - High-performance, schema-free document-oriented database Loaded: loaded (/lib/systemd/system/mongodb.service; disabled; vendor preset: enabled) Active: active (running) since Tue 2020-02-18 18:03:06 CET; 6s ago Main PID: 7635 (mongod) Tasks: 9 (limit: 4915) Memory: 41.2M CPU: 551ms CGroup: /system.slice/mongodb.service └─7635 /usr/bin/mongod --quiet --config /etc/mongodb.conf Feb 18 18:03:06 OrangePi systemd[1]: Started High-performance, schema-free document-oriented database. Feb 18 18:03:06 OrangePi mongod[7635]: 2020-02-18T18:03:06.187+0100 I CONTROL Feb 18 18:03:06 OrangePi mongod[7635]: 2020-02-18T18:03:06.187+0100 W CONTROL 32-bit servers don't have journaling enabled by default. Please use --journa Feb 18 18:03:06 OrangePi mongod[7635]: 2020-02-18T18:03:06.187+0100 I CONTROL Does anyone know a solution how I can install unifi or explain to the installation that I have installed mongodb? Or is there another better solution to solve the problem?