gprovost

Thanks for the update. Good to hear that with fix cpu frequency system is stable. Yeah the main source of instability is DVFS, we already did some change by tweaking regulator ramp delay : https://github.com/armbian/build/commit/d18323fcc358ddd5bd0836c4853cbc281b6293c6 It improved a lot stability but unfortunately doesn't seem to completely solved the problem for everyone. So we are still investigating and getting Rockchip to look at it also.

Yes new packages with required driver are ready, you can just do the usual apt-get update && apt-get upgrade then reboot.

@Schroedingers Cat Yes please run your system with serial console open and command dmesg -w and then copy here the result once the system crashes.

@Julien Michel Could you try to swap SATA port 1 and port 2 on board then check if now the HDD slot that has issue is slot 2 ? This way we can narrow down the issue.

Just to be sure, when you boot your board and you see "Starting kernel..." you wait few minutes before considering it's stuck ? What's the LED status one minute after you see "Starting kernel..." ? Is System LED blinking ?

@Niglix OMV5 will wipe out any fixed IP configuration, so if you didn't use DHCP you will need to login via console to setup temporally an IP in order to then access the OMV web interface and reconfigure for good the network interface via the web interface.

Helios64 LAN2 is completely disable thanks to the following commit : https://github.com/armbian/build/commit/6bb68d7ff787614bf0798b2d3fad9883144a9c2d The mainline kernel r8153 driver doesn't support the vendor ID and product ID used in Helios64, so the interface is completely disable, it's not just losing 2.5Gb speed :-( We didn't see at all this commit, and personally I wasn't aware of the publication of 20.11.3 release, because most probably I'm not following the right thread. Can someone point me out what thread I'm supposed to follow before a new minor release is being pushed ?

@Ammonia Have you managed to fix it yourself ? If not please contact us to support@kobol.io

Effectively there was an issue with /boot partition behind too small, it has been fixed in future build https://github.com/armbian/build/pull/2425

Hmmm if LED1 is not ON but you sure PSU supply +12V then something is wrong with the board. Please contact us to support@kobol.io for further action. Most likely return the board for repair or exchange.

Yeah recovering would require you to boot the board from microSD card (using any recent image for Helios64). Then you will need to use the right tool (e.g dd or fsarchiver) to write your system backup on the M.2 SSD. If you use eMMC only for u-boot then unlikely to get corrupted and would be easy to restore even without a backup since it's just u-boot there. But it cost you nothing you backup the 1st 100MB of the eMMC with dd. This is the kind of question that would require some guideline at some point on our wiki ;-)

@Kev Then still to reply you question, we have a wiki page that covers your question : https://wiki.kobol.io/helios64/install/transfer/ Any further point please create or use a topic under Helios64

Sound a bit strange to put ZFS on top of RAID5, since ZFS has raid feature : RAIDZ Using ZFS on ARM is still a bit early days and requires a bit of tuning, therefore you need to understand ZFS a bit better than just on surface. For that you need to allow yourself some time to play around with it. If you are looking at checksuming / scrubbing feature just on small portion of your data then there is also Snapraid tool that can be interesting. It always comes don't to your usage. If you data is mainly non-encrypted data such as video, movie, picture then a bit flip | bit rotting is unlikely to have any effect. It's hard to give a single recommendation that applies to everyone needs unfortunately.

@helios4noob Yeah as recommended by @SIGSEGV you can do a fresh install a new microSD card and keep the old one as backup in case you need access something that is not on your RAID array. When you do a fresh install (Debian10 + OMV5), the system will automatically detect you previous raid ARRAY, you won't loose your data. Then you just need to mount it again via OMV interface.

@Renée Have you tried with a new sdcard flashed with new image. It could also be bad physical contact in the microSD card reader. You said you tried with SPI, but how did you write u-boot on SPI if you system is unable to boot ? To load spl and u-boot over UART you need kwboot. I need to check if we have those instructions somewhere. @Kev You sure you are in the right forum section ? You are mentioning eMMC, and there is no eMMC on Helios4. So wondering if you are talking about Helios64 instead ? Armbian-config (nand-sata-install tool) works without issue to transfer OS from SDcard to eMMC. Anyhow I'm even sure I understand your question.

@FredK is lsb_release (/usr/bin/lsb_release) really missing or it's a path issue ? I don't see this issue on my side.

@Mangix You can check that you system effectively use mv_xor engine by looking at the interrupt counters. cat /proc/interrupts [...] 47: 27799 0 GIC-0 54 Level f1060800.xor 48: 29949 0 GIC-0 97 Level f1060900.xor You will see the counter increase when doing operation on your RAID array (FYI XOR only used for RAID5 and 6).

@Chris Bognar Nice script Actually we already implemented in latest release an auto graceful shutdown when system has been running on battery for more than 10min. https://github.com/armbian/build/pull/2376 It's all done with udev rules and systemd unit file so in a way it's pretty elegant but pretty simple. We are still planning to deliver at some point an helios64 service daemon that will manage the UPS feature in more advanced way as you are doing ( and to make it easy to configure / manage in OMV too). Other feature of this dedicated helios64 daemon is to control the fan is a more smart way, taking in consideration HDD temperature. Anyhow cool script and thanks for sharing it here, I'm sure it will interest many. (side note: I agree with @TRS-80 a bit compact and not easy to read, and would nicer as a script trigger by systemd timer)

@djurny Thanks for the feedback. We will let you know. We are working with Rockchip to get to the root cause of this instability. We are still suspecting wrong DDR timing settings.

Good to hear :-)

At first glance, things look pretty good so it should be easy reassemble the array. The reason it didn' t happen automatically it's because the event count between sda, sdc is different from sdb, sdd, sde. Fortunately the difference is very small, so data on the RAID should still be ok. First you need to stop the array mdadm --stop /dev/md0 Let's try to re assemble without --force option mdadm /dev/md0 --assemble /dev/sd[abcde] Let us know if it works. If yes then you array should start the syncing process (cat /prod/mdstat), you could share the output of mdadm -D /dev/md0 If if fails, please show the output. Next step, if previous one failed, it's to try assemble with --force option. Please take note that if --force is used you might end up with few file corrupted (whatever writing operation that happen in the difference of event count, in your case the difference of event count is very small). mdadm /dev/md0 --assemble --force /dev/sd[abcde] Same here, share output of cat /prod/mdstat and mdadm -D /dev/md0

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.

@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.

@ebin-dev No unfortunately it is not a way to dim the LED ;-)

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 /sys/class/scsi_host/host3/link_power_management_policy:max_performance /sys/class/scsi_host/host4/link_power_management_policy:max_performance Did you set med_power_with_dipm yourself. If not I wonder what program did that for you. For now i don't see the point to use a different link_power_management_policy than max_performance. But that deserves some investigation.