gprovost

  • Content Count

    434
  • Joined

  • Last visited

2 Followers

About gprovost

  • Rank
    Embedded member

Profile Information

  • Gender
    Male
  • Location
    Singapore

Contact Methods

  • Website URL
    http://kobol.io

Recent Profile Visitors

6576 profile views
  1. Can you do : mdadm --examine /dev/sd[abcde] and post output here That will define what we can do next : force re adding device to the array or recreating it (last resort). https://raid.wiki.kernel.org/index.php/RAID_Recovery Have you tried something on your own when you realized the array was missing ? If yes I need to know which command you did or what action you did in OMV.
  2. @BacchusIX I'm not sure I see anything wrong (beside some issue with fan control). Are you using fixed IP or DHCP ? Take note that fixed IP setup through armbian-config will be wiped out by OMV installation because OMV use netplan/networkd instead of NetworkManager. So if you use fixed IP, you need to configure it again inside OMV directly.
  3. Thanks for the video. It's the SATA controller which is doing that dimming thingy Effectively when I configure link_power_management_policy to med_power_with_dipm I will see the LED dimming cycle happen. By default link power policy is max_performance root@helios64:/sys/class# egrep . /sys/class/scsi_host/host*/link_power_management_policy /sys/class/scsi_host/host0/link_power_management_policy:max_performance /sys/class/scsi_host/host1/link_power_management_policy:max_performance /sys/class/scsi_host/host2/link_power_management_policy:max_performance /s
  4. Sorry a bit confused. Can you confirm again clearly your statement. Only the HDD activity LED are impacted by the dimming cycling ? Or the System Activity LED is also impacted ?
  5. @BacchusIX Yes please provide some log or screenshot. Also which Ethernet port are you using on Helios64 ? I'm asking because in early version, the OMV install script was removing the TX offload setting on 2.5GbE instead of keeping it.
  6. Could be a bad contact. Have you shave a bit the plastic of USB-C cable sleeve to insure better contact through the back panel port ?
  7. Good point indeed, we need to experiment to see to which extend it is really needed. Experimenting with the following inspired from the odroid thread you shared #!/bin/bash # Wait mdadm arrays are in clean state [ -x /sbin/mdadm ] && /sbin/mdadm --wait-clean --scan # Choose hdparm param systemctl list-jobs | egrep -q 'reboot.target.*start' && YVAL='Y' || YVAL='y' # Park all SATA disks. if [ -x /usr/sbin/hdparm ]; then for DEV in /sys/block/sd* ; do [ -e $DEV ] && /usr/sbin/hdparm -$YVAL /dev/${DEV##*/} done sleep 3 fi for DEV in
  8. @Ammonia We will disclose the schematics soon, but here the section you are looking for
  9. Nice approach and you right it is something we should implement in baseline. We will work on that.
  10. @JohnnyMnemonic It doesn't seem you are connecting Helios64 to a USB3.0 port on your Debian PC ? It has to be on a USB3.0 port. FYI the FTDI is the usb-to-serial device that uses only the USB2.0 lanes of the Helios64 USB-C port, while we can use the USB SS lanes in parallel for other function (e.g DAS mode).
  11. Are all the HDD status LED (blue) doing this dimming in and out simultaneously ?
  12. @SR-G Yes please try will newly available image of Armbian 20.11.1 Can find download link here https://www.armbian.com/helios64/ or https://wiki.kobol.io/download/ We will post a new blog post to announce the new build. The past issue was due to some bug in an hardware optimization script. However after we fixed that, there are still other instability reported here and there, and we are still trying to find the root cause. Hopefully LK5.9 will provide a much better experience.
  13. Can you try mdadm --run /dev/md0 to reactivate the array Not sure why your array is deactivate though. Maybe some settings were saved up in OMV. Then you can check again the status of the array with mdadm -D /dev/md0 and cat /proc/mdstat