clostro

  • Content Count

    29
  • Joined

About clostro

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm using Zyxel XGS1010-12. Has 8x1gbe, 2x2.5gbe, and 2x10gb sfp+ ports. Works ok, does what I need.
  2. Can maybe disable the service and put the script it is running, /usr/bin/helios64-ups.sh to root cron for every minute. You could make it run every 20 seconds by adding a while loop that goes 3 turns and sleeps 20 seconds in each turn. However, I don't see where this script checks to see if mains power is active. What I see is a script that will continually shutdown the device if the battery voltage is low even when the mains returns. Is that function provided by the service timer, as in the timer stops when there is mains? If so absolutely do NOT cron helios64-ups.sh as it is
  3. May I suggest outputting dmesg live to a network location? I'm not sure if the serial console output is the same as 'dmesg' but if it is, you can live 'nohup &' it to any file. That way you wouldn't have to keep connected to console or ssh all the time. Just don't output it to any local file system as writing to a local file system at a crash might corrupt it and cause more problems. nohup dmesg --follow > /network/location/folder/helios64-log.txt & 2>&1 exit needed to have single >, and exit the session with 'exit' apparently..
  4. Mine has been pretty stable for the last 2 months. Last restart was to update to Armbian 21.02.2 Buster with 5.10.16 kernel 24 days ago. I applied the Cpu freq mod for the previous kernel, and upgraded with apt, no fresh install. Cpu freq mod is still in place I assume. Device has been completely stable since that mod, and I am not undoing it for the time being. Reliability > everything else. I'm using the 2.5G port exclusively with a 2.5G switch. There are 4 4TB Seagate Ironwolf drives and an old (very old) Sandisk Extreme SSD in there. No OMV or ZFS. Just LVM Raid5 w
  5. Guys, those drives are CMR (ones I could pick out from the logs posted), not SMR. EFRX is CMR, EFAX is SMR. Also, SMR is the one to avoid at all costs. From https://www.servethehome.com/buyers-guides/top-hardware-components-freenas-nas-servers/top-picks-freenas-hard-drives/, ServeTheHome runs a lot of ZFS pools in their infra. Please refer to manufacturer spec sheets and tables before buying a HDD. Here are a few lists- https://nascompares.com/answer/list-of-wd-cmr-and-smr-hard-drives-hdd/ https://blog.westerndigital.com/wd-red-nas-drives/ https:
  6. @kelsoAny SSD will be fast enough for the network or USB speeds of this device. If you are buying new you can pick WD red, Samsung Evo, Sandisk Ultra/Extreme, Seagate firepro (?) ... just stay away from little or no known brands. You can check the models you picked and compare them here - https://ssd.userbenchmark.com/ They are getting a well deserved grilling for their CPU comparisons but I think their SSD data is good enough. I would be looking for the best 'Mixed' value for performance for use in this device, as the network and USB speeds are capping the max read or write speed anyhow.
  7. @Gareth Halfacree If you would be interested in FreeBSD, @SleepWalker was experimenting with it some time ago. Maybe still is.
  8. Just did an in place upgrade with armbian-config (was running the previous build with static cpu freq for 23 days stably), it all works fine after a reboot. Wanted to report results. Few things - -After armbian-config upgrade and reboot, there still were packages not up to date, had to run apt again. -The firewalld zone didn't come up on its own, but the firewall was working as configured. I'm confused about that one. It came back up after I restarted the firewalld service I think. -And the weirdest thing is that the zram1 log was full 100%. armbian-ramlog service was faili
  9. Putting aside the discussion about disk health and spin up and downs, a non spin down value might solve your issue here. You can take a look at both -S and -B options. I couldn't figure out the difference between their 'set' values entirely. They are both supposedly setting the APM value, but aside from -S putting the drives to sleep immediately and then setting the sleep timer, they have different definitions for the level values. From https://man7.org/linux/man-pages/man8/hdparm.8.html For instance -B and -S As you can s
  10. Have you tried to see the sleep/spin down timers on the disks with hdparm? hdparm -I /dev/sd[a-e] | grep level And here is a chart for interpreting the output APM values- http://www.howtoeverything.net/linux/hardware/list-timeout-values-hdparm-s
  11. Just wanted to report that the CPU frequency mod has been running stable under normal use for 15 days now (on 1Gbe connection). Haven't tried the voltage mod. I'll switch to the February 4th Buster 5.10 build soon. edit: 23 days, and I shut it down for sd card backup and system update. cpu freq mod is rock solid.
  12. Hi @aprayoga I have a question before I try modifying boot.scr - I tried @gprovost's suggestion about the CPU speeds and the device has been running stable for nearly 9 days now. I was waiting for 14 days to test its stability and then update Armbian. The current Armbian running on the device is Linux helios64 5.9.14-rockchip64 #20.11.4 SMP PREEMPT Tue Dec 15 08:52:20 CET 2020 aarch64 GNU/Linux. But I have been meaning to update to Armbian_20.11.10_Helios64_buster_current_5.9.14.img.xz. - Shall I try this mod on top of the current setup with the old A
  13. Thanks for the update, I really hope its not the cables in my case. I mean I was not getting these lines in the log before, just got them for the first time. The only difference from the last few boots is the CPU frequency and speed governor per the quote below. I don't think they are related, this was originally suggested for troubleshooting a 'sync and drop_caches' issue, which works fine on my device. Later it was also suggested for the 'mystery red light' issue, which was a problem on my device. But this could be something else. Hopefully not t
  14. Just started seeing these 'ata1.00: failed command: READ FPDMA QUEUED' lines in my log as well. I assume ata1 is sda. Had a whole bunch of them a while after boot and nothing afterwards. But the device was not accessed a whole lot during this time. It just booted up after a crash and the LVM cache was cleaning the dirty bits on the cache SSD connected to sda. sdb-e are populated with 4x4TB ST4000VN008 Ironwolfs, and sda is hooked up to an old (and I mean old) Sandisk Extreme 240GB SSD SDSSDX240GG25. I attached the smartctl report for the SSD below, and it passed a
  15. Just had another one right now. Previous one was 3 days ago. So I plugged the serial cable but the device was completely gone. No login, or any output. Also there are no logs or anything about previous boot once rebooted either. journalctl --list-boots lists only the current boot, and dmesg -E is empty. Anyhow, trying the CPU speed thing now. I hope it works, cleaning the entire SSD cache that gets dirty at every crash is worrying me.