ebin-dev

Thanks for looking into this. As the docker install does not have access to apps it would be quite restricted and not really usable for many. I would certainly not use it. May be you could try to set up the supervised install (I know it is not supported anymore by HA) ? That would bring a lot of attention to Armbian ...

The installation of Home Assistant through armbian-config ends with a reboot in order to enable AppArmor. No modification. If that installation does not work out of the box I will leave it for now as it would not provide a solid basis for the automation of an entire home.

Same here: Installed Home Assistant using armbian-config on a Rock 5b with Armbian Trixie (v26.2.1 for Rock 5B running Armbian Linux 6.18.32-current-rockchip64). I switched from NetworkManager to systemd-networkd. Reboot to enable AppArmor left a system not accessible via ssh after more than 100s. Do we have to wait somewhat longer, or is there currently an issue with the installation of Home Assistant on Armbian Trixie ?

@iav Thank you very much !

@iav The kobol dtbs (rk3399-kobol-helios64.dtb) linked in the messages before are patched in the following way having the effect that helios64 is finally stable (see here) : The opp-microvolt values in opp-table-1 are just replaced by the ones given below (for all linux kernel versions). opp-table-1 { compatible = "operating-points-v2"; opp-shared; phandle = <0x0d>; opp00 { opp-hz = <0x00 0x18519600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; clock-latency-ns = <0x9c40>; }; opp01 { opp-hz = <0x00 0x23c34600>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp02 { opp-hz = <0x00 0x30a32c00>; opp-microvolt = <0xdbba0 0xdbba0 0x1312d0>; }; opp03 { opp-hz = <0x00 0x3c14dc00>; opp-microvolt = <0xe7ef0 0xe7ef0 0x1312d0>; }; opp04 { opp-hz = <0x00 0x47868c00>; opp-microvolt = <0xfa3e8 0xfa3e8 0x1312d0>; }; opp05 { opp-hz = <0x00 0x54667200>; opp-microvolt = <0x10c8e0 0x10c8e0 0x1312d0>; }; opp06 { opp-hz = <0x00 0x5fd82200>; opp-microvolt = <0x11edd8 0x11edd8 0x1312d0>; }; opp07 { opp-hz = <0x00 0x6b49d200>; opp-microvolt = <0x1312d0 0x1312d0 0x1312d0>; }; };

I have attached both the dtbs for linux 6.6 and 6.12 to this message in the forum.

@SymbiosisSystems To get those changes into the mainline build is currently not the solution preferred by the maintainer of this board, because it is some kind of a hot fix. To boot your helios64 to the command line you could try an image from the archive and boot from sd. A system on emmc could then be manipulated using chroot.

This was discussed some time ago. Everybody has the same problem with the 2.5Gb interface. The best you can do is to switch to linux 6.6.xx, replace the dtb, update the firmware in /lib/firmware/rtl_nic and run a script in /etc/rc.local (see here).

The most current download images for Helios64 are now all provided with linux 6.18.xx. I downloaded a minimal image and checked the dtb: it would not appear to contain the opp-microvolt patch that made Helios64 finally stable. So for the ones who have stability issues again on Helios64, I attached the patched dtb compiled for linux 6.18.xx using the exact same opp-microvolt values as in the previous dtb versions I compiled for linux 6.6 and 6.12. The current linux deb files can be downloaded from beta.armbian.com, the linux 6.18.18 deb files I used can be downloaded from here (to be installed with 'dpkg -i linux*'). In order to install the dtb, simply unzip it, copy it into the proper location, update initramfs and reboot: # install the dtb with the opp-microvolt patch: unzip rk3399-kobol-helios64.dtb-6.18.18-opp.zip cp rk3399-kobol-helios64.dtb-6.18.18-opp /boot/dtb/rockchip/rk3399-kobol-helios64.dtb update-initramfs -u reboot rk3399-kobol-helios64.dtb-6.18.18-opp.zip

Thanks for your comments. I did not touch the regulator@40 values at all - only the opp frequencies in line with suggestions from @prahal and some cache settings. cpufreq sampling_rates were changed to about 40000 (depending on the cluster) for kernels 6.6 by a script in /etc/rc.local. The script does not apply anymore in linux 6.12. Instead of disabling the A72 cluster altogether, reducing the burden on the CPUs during data transfers helps to substantially reduce crashes and avoids triggering the watchdog timer. P.S.: I bought a Rock-5B in October 2022 and I finally migrated everything to it.

The rsync instruction copies the files using an exclude list. However that list does not explain why folders other than /var/log/journal are missing in /var/log. # cat /usr/lib/armbian-install/exclude.txt /boot/* /dev/* /proc/* /sys/* /media/* /mnt/* /run/* /tmp/* /ddbr/* /var/log/journal

You just have to create the nginx folder in /var/log with owner www-data (it is not created automatically): mkdir /var/log/nginx chown -R www-data:www-data /var/log/nginx systemctl restart nginx

With linux 6.12 the optimizations in /etc/rc.local do not apply anymore since some configuration options have vanished. So if you like to have a stable 2.5Gbit/s network connection without timeouts, linux-6.6 is still recommended (bookworm and trixie). You can build it yourself using an Armbian snapshot (from Dec. 2024) or download a recent linux-6.6.100 from here.

To troubleshoot this thing I would just boot from another sd card with a fresh bookworm image leaving your system on emmc or on another sd untouched. In 'sudo ethtool -i <interface>' the name of your 2.5G interface has to be inserted - 'ifconfig' will reveal it (I renamed mine to end1). If the rtl_nic firmware is recognized correctly it will display: root@grid:~# sudo ethtool -i end1 driver: r8152 version: v1.12.13 firmware-version: rtl8156a-2 v2 04/27/23 ...

To troubleshoot that you could boot off a fresh Armbian 24.11.1 Bookworm image (6.6.62) and add rtl_nic firmware, replace dtb, setup rc.local. If transfer rates are still low something may be wrong with your client or with your helios64 or with the network itself. Did you launch 'htop' so that you can see what is going on during the data transfer? Are there any cores fully utilized ? Is nic offloading enabled ? etc. 'systemctl disable armbian-hardware-optimize.service' I am automatically calling that shell script while mounting helios64 as a remote drive on macOS clients (using netatalk). The names of the processes (afpd|cnid|iperf3|netatalk) need to be replaced by the processes involved in the data transfer on your helios (iperf3, smb? etc. ). root@grid:~# chmod +x /usr/local/bin/make_nas_processes_faster.sh root@grid:~# sh /usr/local/bin/make_nas_processes_faster.sh pid 21358's current affinity list: 4 pid 21358's new affinity list: 4 pid 21359's current affinity list: 4 pid 21359's new affinity list: 4 pid 21360's current affinity list: 4 pid 21360's new affinity list: 4 pid 21367's current affinity list: 4 pid 21367's new affinity list: 4 pid 21368's current affinity list: 4 pid 21368's new affinity list: 4 pid 21700's current affinity list: 4 pid 21700's new affinity list: 4