Jump to content

axeleroy

  • Posts

    19
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Applications

Everything posted by axeleroy

  1. Hello, My NAS becomes unresponsive every time I run a somewhat CPU-intensive task: indexing photos in photoprism, importing followings in Mastodon… or just browsing Mastodon. Is it expected of the Rockchip RK3399 or can I improve the situation with the right CPUfreq config ? For context, here is my CPUfreq config and kernel (I have yet to update): axel@helios64:~$ cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR=performance MAX_SPEED=1200000 MIN_SPEED=1200000 axel@helios64:~$ uname -a Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux Thanks!
  2. Hello, I have been holding onto kernel 5.10 (5.10.21-rockchip64 to be exact) for a while as it has been pretty stable for me and also because I heard bad feedback from newer kernels on the Helios 64. But with the recent discovery of the DirtyPipe exploit (which has been introduced in Linux 5.8), I might be looking to upgrade to the latest Armbian kernel (which contains a fix to the vulnerability). So, my question to fellow Helios64 users is: have you encountered any issue with kernel 5.15, especially when using OpenMediaVault 5, Docker, MergerFS and NFS?
  3. I'm using the 2.5Gbps NIC exclusively with a 2.5Gbps switch for a month with no issues so far.
  4. My Helios is stable, running LUKS, MergerFS, SnapRAID, OMV and 9 Docker containers from SD Card and with 3 HDDs. Although in order to get a stable system I had to lock CPU frequency at 1.2GHz, otherwise CPU intensive tasks (like SnapRAID's scrub) would cause my Helios to reboot. ================================================================================ = System information ================================================================================ Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux ================================================================================ = Uptime ================================================================================ 12:25:17 up 8 days, 1:18, 0 users, load average: 0.01, 0.10, 0.15 ================================================================================ = openmediavault information ================================================================================ Release: 5.6.2-1 Codename: Usul ================================================================================ = openmediavault plugins ================================================================================ ii openmediavault-backup 5.2.4 all backup plugin for OpenMediaVault. ii openmediavault-flashmemory 5.0.8 all folder2ram plugin for OpenMediaVault ii openmediavault-keyring 1.0 all GnuPG archive keys of the OpenMediaVault archive ii openmediavault-luksencryption 5.0.2 all OpenMediaVault LUKS encryption plugin ii openmediavault-minidlna 5.0.5 all OpenMediaVault miniDLNA (DLNA server) plugin ii openmediavault-omvextrasorg 5.6 all OMV-Extras.org Package Repositories for OpenMediaVault ii openmediavault-snapraid 5.0.7 all snapraid plugin for OpenMediaVault. ii openmediavault-unionfilesystems 5.1.2 all Union filesystems plugin for OpenMediaVault. ii openmediavault-wol 3.4.2 all OpenMediaVault WOL plugin PS: don't mind the uptime, I had to reboot to apply an update. Otherwise no problem since mid-February.
  5. axeleroy

    Random reboots

    Hi, quick update: no reboots in the two weeks following the frequency tweak. Reboot still happened shortly after my February 11 post (but before I applied gprovost's advice).
  6. axeleroy

    Random reboots

    Updating to the latest Armbian seems to have improved stability, though it has only been 72 hours since the update, I might be talking too quickly. @gprovost Do I need rebooting after applying this configuration? Out of curiosity: how does it improve stability?
  7. axeleroy

    Random reboots

    It happened again. Should I try updating to the Armbian version that jiust came out? When should I run armbianmonitor (whenever I can or just after a reboot?) and what should I be looking for (because nothing seems odd to me, but I'm not that of an advanced user) Thanks !
  8. axeleroy

    Random reboots

    Oh, I didn't know about this utility. Here are the logs: http://ix.io/2Ok2
  9. axeleroy

    Random reboots

    Hi, I'm very pleased with my Helios 64, but since I updated to Armbian 20.11.6 (from 20.08.11 or 21, not really sure) it reboots at random times: it can run fine for over two weeks and reboot twice in 36 hours, always when idling. It's running OMV as well a multiple Docker containers: PiHole, Wireguard, Nginx, Transmission, restic-server and n8n. Is it a common issue? What fixes do you recommend? What should I look for to diagnose the issue? Thank you. Edit: forgot to mention that I'm using SnapRAID and mergerFS, as well as NFS shares.
  10. That what I thought as I read on the forums that the logs were in ramdisk, but I am confused since syslog had entries from before the reboot, as if there was an exception for this file (though I guess I'm probably wrong). How can I make the logs persistent, at least temporarily? I also had reboots when trying to backup OMV using openmediavault-backup and dd, I would like to diagnose those too (though I stop using dd in favor of borgbackup).
  11. Hello there, My board had just rebooted with no notice, so I wanted to take a look at /var/log/syslog in order to diagnose the issue, but for some reason, there are no logs between Dec 30 and the moment my board rebooted. Why are logs missing? What do I need to do in order to keep them the next time my board reboots? Also, am I looking at the right place to diagnose reboots? Thanks for you help! PS1: My board is the Helios64 and I'm running Armbian 20.11.4 Buster with OMV 5. PS2: I know there is an Helios64 Club, though I did not choose to post there as I'm not sure if this issue is specific to that board.
  12. Since OMV alters so much of Debian/Armbian, I would recommend deploying the Docker container. Docker also has the benefit of using any port you want. If you want an easy to use GUI, you can install Portainer using OMV-Extras (in the left menu, then under the Docker tab of OMV-Extras).
  13. axeleroy

    Helios64 Support

    Welp, I removed the SD card and it did not boot to eMMC.
  14. axeleroy

    Helios64 Support

    Hello, I just tried to copy my Armbian install from the SD Card to the eMMC, but I'm not sure it has been successful, how can I be sure? For information, I also encrypted my HDDs using LUKS and I use MergerFS to pool their data. Boot sequence from serial console Output from df /etc/fstab
  15. axeleroy

    Helios64 Support

    I switched to eth1 to install it, then switched back to eth0 and ran arp-scan. There are lots of reference to my decommissioned Raspberry Pi on 192.168.0.110. Turns out I forgot to delete the ARP binding on my router to make sure my old Pi was given 192.168.0.110. PEBKAC… Thanks a lot anyway!
  16. axeleroy

    Helios64 Support

    Forgot to add ifconfig output, it might be useful root@helios64:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.110 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::5550:854d:6ad0:b6d7 prefixlen 64 scopeid 0x20<link> ether 64:62:66:d0:03:7c txqueuelen 1000 (Ethernet) RX packets 390 bytes 60863 (59.4 KiB) RX errors 0 dropped 1 overruns 0 frame 0 TX packets 384 bytes 35588 (34.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 27 eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 64:62:66:d0:03:7d txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 32 bytes 2640 (2.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 32 bytes 2640 (2.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 I also did further testing: When pinging from my router, I get a timeout (set to 2000ms) When pinging my desktop and laptop computers from the Helios64, I get a response. When pinging its IP (192.168.0.110) from the Helios64, I get a response. When pinging the Helios from my desktop and laptop, I get a response.
  17. axeleroy

    Helios64 Support

    Hello, After I had issues with DNS resolution on my Helios64, I flashed a brand new Armbian image and now I cannot seem to connect to any devices on the network. I tried pinging my computer, router and 8.8.8.8 without success (which I can from my computers or router). I literally just I set root's password. I literally have no idea why this is happening. Every other computer in the network are working fine and the Helios64 has no problem the first few days I used it. Big thanks to anyone willing to help me! --- Version: Armbian 20.08.13 Debian 10 Buster (Kernel 5.8.16) DHCP config: Default gateway: 192.168.0.1 (my router's IP) Primary DNS: 80.67.169.12 (DNS from https://en.wikipedia.org/wiki/French_Data_Network) Secondary DNS: 192.168.1.1 (my ISP's router) My router's DHCP is set to give 192.168.0.110 to my Helio64's MAC address.
  18. axeleroy

    Helios64 Support

    Hi, Not sure if this is the right place, but I cannot seem to boot Armbian 20.08.10 Kernel 5.8 from SD. After I unsuccessfully installed on a Samsung EVO SD Card, I tried once again on a Sandisk Ultra (this exact model) but it has been stuck on "Starting Kernel..." for more than 5 minutes. I'm not sure if it's just the first boot that takes a while or if I botched something. Also probably not helping is that the provided USB C to A cable is a bit loose and can easily be pulled from the board. Thanks!
×
×
  • Create New...