gprovost

@grek Can you change the IO scheduler to none as recommended here to see if any change.

@tommitytom Can you show us the early stage boot log (you will need to capture serial console output). Just want to check if you are using rockchip blob or u-boot TPL/SPL, since the latest one has still some instability.

@dieKatze88 Which kernel version are you running ? There has been significant stability improvement with latest one (version 5.10.21) ? Any chance you can have the serial console opened in hope to catch something when it crashes ?

Hmm that strange because as said on the log provided it look like a graceful shutdown so something must have triggered it. Maybe try to dig in log in /var/log.hdd/ see if you can find something

Hi, That's a good question and documentation is lacking on rockchip side on this matter. There is documentation on ARM Trusted Firmware, but not much on TrustZone. The only thing I can find is in Chinese (attached). Yes should be EL2 since there is not hypervisor running. Would be great to experiment with OP-TEE RockchipDeveloperGuideTrust_CN.pdf

@Vin Based on the log you provided, the system is not crashing but powering off on its own ?! Something is triggering a poweroff 10sec after you finished to start. That's strange. You sure it's not you who triggered the poweroff ? Or maybe the poweroff button on the front panel is being press by the sticker a bit ?

@TRS-80 I think it's important once in a while to re-question the whole thing because it helps to clarify the real objective that we might sometimes forget... or justify that energy should be focused somewhere else. I think ultimately the life of a distro will always depends on the size of its user base and lets distinguish here community and user base. User base includes all the passive users that we never hear from, I have no clue how much that represent for Armbian. @Igor Maybe you have such numbers : number of d/l per image and number of active forum user ? Even though this will not necessary help to say if armband-config is useful, it will help to give a sense of proportion of user we never hear from which to my assumption are often users that don't hack/tinker too much with their boards. Then I think it could be useful to run a poll on the forum & twitter and simply ask what the people are using their SBC + Armbian for : 1/ Hacking / Tinkering 2/ Headless server 3/ Set-top TV box 4/ Work Desktop Such kind of poll could will help understand the audience usage. If the great majority vote for option 1, then it would back up @TRS-80 assumption. But if majority is 3 and 4, then clearly we are talking about a user based that is not really CLI oriented. As for option 2, is a bit 50 / 50. We should also be aware of what's happening out there. 1/ DietPi user base is growing and I guess it's because of their approach of making a big eco system of 3rd party app available to user via an interface a bit similar to armbian-config. 2/ Debian / Ubuntu install, even in headless mode, is actually not purely CLI so we all get use to a bit of GUI even if we are advanced CLI users. I agree with Igor that the strength of armbian-config is also a lot the configuration features (without forgetting nand-sata-install which also deserve its attention). So personally I see a big plus to have armbian-config around, because it can only help to widen the user base which in fine is beneficial to Armbian sustainability. Yes that's a lot of assumption I made, It's why I think the poll would be really a nice driver for this refactoring effort.

Your power meter won't be able to catch current spike during disk spin-up because the spike is very short. But most likely the spike is high enough to trigger the over current protection. So yes with the current design you will need a dual USB type A cable to get enough current for hungry HDD. For next revision we will increase current limit on one of the port to address external HDD which requires more than the standard 900mA.

Could you guys update to latest kernel (linux-image-current-rockchip64_21.02.3_arm64 / LK 5.10.21) and revert to ondemand governor with the full range of frequency in case you were on performance mode. Also remove any vdd voltage tweak you might have put in /boot/boot.cmd. If you had vdd tweak you will need to rebuild u-boot boot script after removing the lines in /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Let us know how the new kernel improves the stability.

Could you guys update to latest kernel (linux-image-current-rockchip64_21.02.3_arm64 / LK 5.10.21) and revert to ondemand governor with the full range of frequency in case you were on performance mode. Also remove any vdd voltage tweak you might have put in /boot/boot.cmd. If you had vdd tweak you will need to rebuild u-boot boot script after removing the lines in /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Let us know how the new kernel improves the stability.

Could you guys update to latest kernel (linux-image-current-rockchip64_21.02.3_arm64 / LK 5.10.21) and revert to ondemand governor with the full range of frequency in case you were on performance mode. Also remove any vdd voltage tweak you might have put in /boot/boot.cmd. If you had vdd tweak you will need to rebuild u-boot boot script after removing the lines in /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Let us know how the new kernel improves the stability.

Could you guys update to latest kernel (linux-image-current-rockchip64_21.02.3_arm64 / LK 5.10.21) and revert to ondemand governor with the full range of frequency in case you were on performance mode. Also remove any vdd voltage tweak you might have put in /boot/boot.cmd. If you had vdd tweak you will need to rebuild u-boot boot script after removing the lines in /boot/boot.cmd mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr Let us know how the new kernel improves the stability.

Yes exactly and I think it's important to recommend to disable it at pool creation.

Yes I agreed, there was the PR from @aprayoga that we would like to see deployed before the v21.05 comes. Hopefully it solves most of instability issue for all Helios64 board. I have tested latest from nightly repo (trunk.40) and it works. @aprayoga Can you please confirm also on your side that all good for a new 21.02.3 build.

@lanefu Ahahah yeah it seems you are describing more a Cluster Node SBC than a NAS which is our main focus at Kobol ;-) Sorry... But yeah while for me PoE = Remote Power Supply for the big family of everything & nothing that we call IoT... I can clearly see the benefit of it for easy clustering of a small SBC compute node. Maybe you should move the topic to a more general Rockchip thread, because honestly I don't think such design would be a priority for us right now... but who knows ;-)

Yes you can look in /usr/lib which is the latest linux-u-boot-current-helios64_XX.YY.X_arm64 folder and use it then with the same above dd commands But please take note that it is usually not necessary to update u-boot. If your system boot fine and works fine then there isn't much benefit at updating U-boot and taking the risk to mess up something.

@ShadowDance Since you are giving good recommendation on ZFS, I wonder if there should be some clear recommendation on the pro/con of using ZFS compression and/or deduplication on system with limited RAM ?

WoL feature is not yet supported because suspend mode was not yet supported until now. Suspend mode has been recently added for Pinebook Pro (RK3399) in kernel mainline, so just a question of time before we got this on Helios64. https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-current/board-pbp-add-suspend.patch

Can you share more info because cannot say much based on the few input you provided ps -o pid,user,%mem,command ax | sort -b -k3 -r top -b -n 1 and the link generated by armbianmonitor -u https://linuxhint.com/check_memory_usage_process_linux/

Yes unfortunately nand-sata-install does not work the other way around, I'm looking at it currently since there was another use case related to install on OS rootfs on HDD that wasn't also supported. The step for you case should be : 1. First boot the system on a microSD card with a fresh install of Armbian. 2. Copy rootfs from old destination (HDD) to new destination (eMMC) mkdir /mnt/rfs_new /mnt/rfs_old mount /dev/mmcblk2p1 /mnt/rfs_new/ mount /dev/sdX1 /mnt/rfs_old/ rsync -avrlt --delete --exclude-from=/usr/lib/nand-sata-install/exclude.txt /mnt/rfs_old/ /mnt/rfs_new/ 3. use command blkid to know the UUID of /dev/mmcblk2p1 4. Modify /mnt/rfs_new/boot/armbianEnv.txt to modify rootdev line with the UUID of /dev/mmcblk2p1 verbosity=1 bootlogo=false overlay_prefix=rockchip rootdev=UUID=075c8660-77ca-4048-a04b-be3364c60a40 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u 5. Modify /mnt/rfs_new/etc/fstab - Remove /media/mmcboot and /boot mount point lines - Edit / mount point to use the UUID of /dev/mmcblk2p1 # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=075c8660-77ca-4048-a04b-be3364c60a40 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 6. Sync and Poweroff 7. Remove microSD and Poweron (maybe cross your finger also)

Will the runners of the CI pipeline be VMs running latest Armbian OS version in which we test armbian-config ? Because a docker deployment can fail for 2 category of reasons, the container / compose file issues or because of the host OS itself. So to catch the second category we need to emulate the Armbian OS host.

Right now we still have a bit of difficulty to distinguish between ATA errors related to cable issue (something that we are addressing with a new PCB back-plane) and ATA errors potentially due to the SATA controller. For the latest one we are asking help from JMicron, but the issue is that we don't have an easy way to reproduce the error. The issue that might be related to SATA controller seems to only show up with BTRFS and ZFS while doing some scrubbing. Do you guys have a suggestion for a simple reproducible test starting from scratch (no data on HDD) ? Thanks for your help.

I really like the idea to put the constrain that all 3rd party applications must only be supported through containers. That will clearly help to improve user experience thanks to well maintained container but mainly avoid app installation that would potentially mess up the OS. We need to think of a way to list in the menu the already installed containers (of course only list the container installed by armbian-config). Also the question will be do we want to make docker and docker-compose packages a dependency of new armbian-config ? I think we should, it will make thing easier... but of course also not a big deal to install them only when first 3rd app is being installed. I also like the fragmented approached made by @tparys clearly it will help a lot for maintenance and contribution. We will need to define a clear policy on how to handle local and global variables between the different chunk of scripts. On the CI topic, I unfortunately also don't see what could be really easily tested in an automated pipeline. Happy to participate in the refactoring effort.

What happen when you press the button check ?

Ok here the dirty way to update it in your specific case where eMMC is at /dev/mmcblk1 We will work on nand-sata-install to support the use case of rootfs on HDD/SSD and bootloader on eMMC.