Jump to content

clostro

Members
  • Posts

    30
  • Joined

Recent Profile Visitors

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

  1. https://wiki.kobol.io/helios64/button/#recovery-button Usb type-c to emmc flashing according to wiki. I'm not sure how it works though, never tried it.
  2. I'm using Zyxel XGS1010-12. Has 8x1gbe, 2x2.5gbe, and 2x10gb sfp+ ports. Works ok, does what I need.
  3. 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. Because you won't be able to boot the device until the battery charges over 7 volts. #!/bin/bash #7.0V 916 Recommended threshold to force shutdown system TH=916 val=$(cat '/sys/bus/iio/devices/iio:device0/in_voltage2_raw') sca=$(cat '/sys/bus/iio/devices/iio:device0/in_voltage_scale') adc=$(echo "$val * $sca / 1" | bc) if [ "$adc" -le $TH ]; then /usr/sbin/poweroff fi There is a whole device with lots of data in there, is there any documentation on iio:device0? edit- apparently there is https://wiki.kobol.io/helios64/ups/#ups-status-under-linux
  4. 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..
  5. 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 with SSD rw cache. No docker or VMs running. Cockpit for management. Samba for file sharing. Borg for backups.
  6. 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://www.seagate.com/internal-hard-drives/cmr-smr-list/ As far as I know, all Hitachi drives are CMR.
  7. @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. Western Digitals you picked use CMR, which is supposedly much better than SMR, can take a look at this table if you have to pick other models. https://nascompares.com/answer/list-of-wd-cmr-and-smr-hard-drives-hdd/ One suggestion before you put any critical data into those brand new disks- Run 'smart' tests on each drive, long tests. Should take about 10 hours I think. One of my brand new Seagates couldn't complete a test at first run and had to be replaced. Now I'm on edge and running nightly borg backups to an older NAS because the other disks are from the same series. Call me paranoid but I usually stagger HDD purchases by a few days in between, and/or order from different stores to avoid having them from the same production batch, couldn't do that this time around. @WernerI use 4 4TB Seagate NAS drives, whatever their branding was.. And an old 240GB Sandisk Extreme SSD for Raid caching. LVM Raid 5 + dm-cache(read and write, writeback, smq). It ain't bad. SSD really picks up the slack of the spinning rust especially when you are pushing random writes to the device, and the smq is pretty smart at read caching for hot files.
  8. @Gareth Halfacree If you would be interested in FreeBSD, @SleepWalker was experimenting with it some time ago. Maybe still is.
  9. 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 failing and wouldn't work properly until I manually deleted /var/log/pcp* since it was the one hogging all the space. Did test the 2.5G adapter with crystaldisk on Windows client a few times, which would previously crash eth1 (sometimes near instant death), and so far it works fine. Did some iperf3 tests, and I am getting +1.9gbps on one side and +2.2gbps on the other with 'ethtool -K eth1 rx off tx on' edit: forgot about the eth0, it wouldn't show up in ifconfig after the update. Not sure what happened about that one since the cockpit interface shows it just fine, just not configured. It may have been me toying around with it before the update. I might have cloned its MAC address so it would get the same IP as the eth1 from pihole dhcp, really can't remember.
  10. 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 see, the value of 255 and other special levels are different between -S and -B. But the definitions also sounds like they are doing the same thing as well. I would like to learn if anyone can clarify the difference.
  11. 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
  12. 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.
  13. 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 Armbian and CPU speed mod? Or can I update to the newest image? - If I update to the latest image, can I just update in place or do you suggest a fresh install? - Also shall I also redo the CPU speed mod as well? After a fresh install. Thanks
  14. 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 the cables, I would rather have the SSD connected to that slot fail than to change the harness.
  15. 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 short smart test just now. I'll start a long test in a minute. Using Linux helios64 5.9.14-rockchip64 #20.11.4 SMP PREEMPT Tue Dec 15 08:52:20 CET 2020 aarch64 GNU/Linux. Serial number of the board is 000100000530 if that could help.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines