18 18

About This Club

Dedicated section for talk & support for the Helios4 and Helios64 open source NAS. Lead and moderated by the Kobol Team.
  1. What's new in this club
  2. You are trying to execute a block device as a command which obviously does not work. The device is mounted as your root directory / So Try code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ncdu -x /
  3. Just to add to this I am able to locate the emmc drive through df command but i um unable to access it.. please see below Filesystem 1K-blocks Used Available Use% Mounted on udev 1901936 0 1901936 0% /dev tmpfs 395612 7400 388212 2% /run /dev/mmcblk2p1 14843200 13393004 1268104 92% / tmpfs 1978044 0 1978044 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs 1978044 0 1978044 0% /sys/fs/cgroup tmpfs
  4. Thank you for your suggestion for that have installed ut and tried running it using ncdu -e ncdu -x however cant find anything apart from system files is there any other commands that i should try.
  5. Use a tool like ncdu to figure out which folder(s) are getting so big. Then look into them.
  6. My Helios has been running well for the most part stable for the past few weeks however last night i noticed when looking at my file systems in omv that my 14 GiB eMMC drive which houses my ambian install is at 13.13GiB and looks to be growing. Normally this sits around the 5 GiB. I have checked my docker install for anything suspicious but my plex docker is only taking up about 400mb. looking at my system logs i am getting a repeated this error which is new and might be related however i am not really sure what program is casing it. Jun 10 17:32:27 localhost rsyslogd: [or
  7. To post a positive update on this I've upgraded Armbian to 5.10.23 21.05.2 with OMV 5.6.8-1 and ZFS 2.0.3-1~bpo10+1 and it's now been running for 25 days without becoming unresponsive, memory usage continues to sit at around 33% and system load is low.
  8. One solution to this would be to merge both the old and the new rule into the same file (like I ended up doing above), but I would highly suggest that we package a new version of the bsp with the correct rule in a 21.05.3 version to avoid issues with non-spinning fans. Let me know if I can assist by any means.
  9. It is STILL an issue in the 21.05.2 package in the repo https://armbian.hosthatch.com/apt/pool/focal-utils/a/armbian-bsp-cli-helios64/armbian-bsp-cli-helios64_21.05.2_arm64.deb so anybody upgrading to 21.05.2 will get the old udev rule and the fancontrol issue
  10. I had a similar issue with random reboots. Did DM @axelroy directly and also "tweaked" the system. I am running the helios now for almost 2 weeks without issues with the following settings: Min CPU speed = 400 MHz Max CPU speed = 1400 MHz CPU governor = on demand So it seems that the helios was rebooting when having to deal with intensive tasks - in my case: performing a SnapRAID scrub. Anyhow: Now I am at maximum speed of 1400MHz whereas the helios could perform even on 1800MHz. The question is if this is a problem by design? Or is there a way to fix it
  11. My Helios froze today, no contact with SSH nor USB serial console. Blue heartbeat was off and red led was on, can't remember if it pulsed/blinked... Had to reboot. Now my system has been resilvering since (3 disk zfs mirror pool) with 2 of the disks being resilvered. I'll copy zfs status output here: root@helios64:~# zpool status pool: export state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Fri
  12. So with a new PSU (30€ on amazon) my HELIOS4 NAS is working again.
  13. Random behaviour is because there is no more per branch BSP. Decisions has to be refactored for runtime. I keep forgetting we still have legacy stuff here ... so this will complicate a bit https://armbian.atlassian.net/browse/AR-779
  14. To confirm I checked with https://armbian.systemonachip.net/apt/pool/focal-utils/a/armbian-bsp-cli-helios64/ Which really shows that there is a wrong file in 21.05.2 (/etc/udev/rules.d/90-helios64-hwmon...), interestingly the nightly build from beta.armbian.com does have it right... @Igor pinging you here, as I am not familiar with the new packaging. Was this only an issue in one version and will be fixed automatically with next release/minor version? Or do we have to fix some packaging somewhere...?
  15. Just to clarify, was this a problem with 21.05.1 or IS it still a problem with 21.05.2? If it is still active problem, we should seek to do a Pullrequest to fully fix it in the buildsystem. EDIT: Seems to be correct in the buildsystem: https://github.com/armbian/build/blob/3b3d85e25c2ecde30df7b5274fc6f1b9c0299ea2/config/sources/families/include/rockchip64_common.inc#L395-L401
  16. For anybody passing by, the issue is due to the fact that for some reason the armbian-bsp-cli-helios64 package for 21.05.2 (EDIT: clarify, 21.05.1 is fine as seen below) was build with the old udev rule (for 4.4 kernels): $ ls armbian-bsp-cli-helios64_21.05.1_arm64.deb\data.tar\.\etc\udev\rules.d\ 10-wifi-disable-powermanagement.rules 50-mali.rules 50-rk3399-vpu.rules 50-usb-realtek-net.rules 70-keep-usb-lan-as-eth1.rules 90-helios64-hwmon.rules 90-helios64-ups.rules $ ls armbian-bsp-cli-helios64_21.05.2_arm64.deb\data.tar\.\etc\udev\rules.d\ 10-wifi-disable-powermanagement.rules 50-mali.
  17. Same issue here, it's quite frustrating. Unfortunately, I have no idea where to even start an attempt at a fix. Can anyone confirm that this problem does not persist when using the 1Gbit NIC? Edit: Can confirm that on the 1G NIC it works just fine. As @Ammonia said, the driver for the 2.5G must be broken. This reminds me of the time that the driver was removed, @Igor probably remembers.
  18. Hello, i don´t have a xserver installed so i don´t have and can use xrandr log´s are here. http://ix.io/3o6R thanks you
  19. Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed. Also try code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } xrandr for resolution adjustment.
  20. Posting here following what was recommended on twitter. After updating my helios64 earlier this week and rebooting to get the new kernel, I realized it was suspiciously silent. A quick check to sensor temps readings and physical check made me realize the fan were not spinning. After a quick read on the wiki, I checked fancontrol which was indeed failing: root@helios64:~ # systemctl status fancontrol.service ● fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/
  21. Hello, today i try a USB C to HDMI Adapter and i get some picture on tv but it´s really unreadable and my log is full of this: rockchip-vop ff8f0000.vop: [drm:vop_plane_atomic_update [rockchipdrm]] *ERROR* Maximum dst width (3840) exceeded it is possible to restrict the resolution in the terminal? i think this error ocure because to high resolution or wrong detection Thank you
  22. Hi, I have nothing "new" for this thread but I can add some feedback as I have a similar issue (as the one originally reported) I've a raid 1+0 array with 4 WD30EFAX, connected to ata1-4 ports. The system was running "Armbian 21.02.2 Buster with Linux 5.10.16-rockchip64" on emmc at the time I reported the issue to Kobol support. I have the enclosure kit, so I use the provided SATA harness. A file transfer (read ~15G) from an NFS client was enough to trigger a lot of occurrences of: [78707.655206] ata4.00: failed command: READ FPDMA QUEUED [78
  23. Hello, HELIOS4 system was running (and doing nothing), when it suddenly crashed. After restart, nothing automatically loaded (system stuck in emergency mode), once USB cable plugged i managed to log only once into the system, and discovered that no disks where mounted anymore (not even available / detect by the board) (it's not so easy as it seems there are some freezes, maybe due to the hardware errors related to he missing hdd links) 13:00 root@helios4 ~# ll /dev/sd* zsh: no matches found: /dev/sd* Is this a failing PSU (like in other threads) ?