gprovost

@Gareth Halfacree Can you provide the output of the 2 following commands. lsblk and cat /proc/mounts

Humm that's funny. You can call directly the sub app that is in charge of installing / updating bootloader. $> nand-sata-install You should use option 5.

in /usr/sbin/fancontrol you can comment the lines 517 & 518 to achieve what you want. #trap 'restorefans 0' SIGQUIT SIGTERM #trap 'restorefans 1' SIGHUP SIGINT You will need to stop and restart the service in order for it to take effect systemctl restart fancontrol.service

@SymbiosisSystems Does the same issue happen with a fresh install on legacy (LK 4.4) ?

You can install watchdog service and make use of the RK3399 hardware watchdog apt-get install watchdog

Yes there is enough space to install OMV on eMMC.

We are coming up soon with a change that will finally improve DVFS stability.

No update. We can't get the cable we selected for the original listed price because of still component shortage. We will address this when we trigger our next batch.

We are coming up soon with some changes that seems to finally improve the DVFS issue.

Are you sure you save the settings (apply button located on top right of OMV interface) ? As for the 5 minutes startup, it's just OMV services which take some time to startup everything. BTW I'm working on making fixed IP configuration done with armbian-config auto transfer to OMV.

Yes this issue only applies to fixed IP setup use case with OMV. Unfortunately OMV doesn't use network-manager but networkd, therefore during installation OMV wipes out all existing fixed IP configuration done via armbian-config. After install of OMV, if you used fixed IP address, you need to connect to Helios64 by serial console, re-setup temporally the IP with ifconfig (e.g ifconfig eth0 x.x.x.x) which will allow you to connect to OMV web portal and then reconfigure via the web interface the network interface permanently. I know it's annoying, I'm sure we can automatize that in the OMV install. You are welcome to look at it : https://github.com/OpenMediaVault-Plugin-Developers/installScript/blob/master/install

Please provide the link generated by command armbianmonitor -u

@brunof You should first stop the array and then reassemble. mdadm --stop /dev/md0 then try to re assemble without --force option mdadm /dev/md0 --assemble /dev/sd[abcde] 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 only /dev/sda is out of sync, so you shouldn't lose anything). mdadm /dev/md0 --assemble --force /dev/sd[abcde] Finally can you share the link output from command armbianmonitor -u

@Eric Poscher-Mika Doesn't matter which speed you choose, the purpose of this temporary workaround is to disable variable frequency and use a fixed one. So you can choose the lowest if it fulfills your needs in term of compute power.

@ShadowDance @alban I guess it was a shot in the dark to check if NCQ has any sort of impact.

This is a quirk for UAS device applied to all Armbian release, it is not specific to Helios64. https://github.com/armbian/build/blob/2b1306443d973033c6f2cef7b221f5c25f0af98d/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L379

I shared the design of the thermal pad, showing that the whole area below heatsink is cover with thermal pad by default. @allen--smithee That's very valuable feedback, I think we will need to review our approach on thermal pad. One factor we had to take in consideration is also ease of installation on the factory line.

If you can still connect to OMV web portal, then go check your created user and be user they right to connect to SSH.

Hahahah best one I have read so far about the LED brightness. Yeah be sure it something we will solve in next batch.

@freed00m Could you disable NCQ and see how if you manage to complete the SMART extended test. Edit /boot/armbianEnv.txt and add the following line : extraargs=libata.force=noncq

Hey guys, could you disable NCQ and see how it impacts your system when trying to reproduce the issue. Edit /boot/armbianEnv.txt and add the following line : extraargs=libata.force=noncq

Are you trying to ssh with root user ?

@allen--smithee Actually what you are doing is not ideal since now the inductors (little squary components that appears through your thermal pad) are not able anymore to dissipate heat via the heatsink. These inductors generate quite a lot of heat and it will spread to LPDDR4 and PMIC trough PCB. The purpose of the Helios64 heatsink is obviously not to just dissipate heat for the SoC but for all other key components (LPDDR4, SATA controller, USB-to-LAN, etc...). Here your measurement is only from the SoC point of view, which is not necessary the best way at looking at overall thermal management. Could you add back some thermal pad on the inductors and re-run your thermal measurement. It would be interesting to see if you see the same thing afterwards. In any case we will change thermal pad supplier, we are not really happy by the current one.

@slymanjojo Is your install on microSD card or eMMC ?

Which HDD (on which SATA port) are not recognized anymore ? Have you tried plugging the unrecognized ones in another slot just to check if it's an issue specific to one or more of the slots.