Search the Community

Dear all; I'm looking for some help with my Helios64 NAS, since I update kernel to 5.15, zfs-dkms won't work. Which is normal, since the most recent version available for Helios64 of zfs-dkms is 2.0.3-1~bpo10+1 (tested on 1st April 2022), and this version is only compatible with kernel from 3.10 to 5.10. Then the first solution that I thought was to downgrade to 5.10 through the armbian-config tool, however when I'm trying to install the linux-headears (through armbian-config) I'm having the herdears of 5.15 (same issue with apt install linux-headers-current-rockchip64) while zfs-dkms looking for 5.10. Preparing to unpack .../zfs-dkms_2.0.3-1~bpo10+1_all.deb ... Unpacking zfs-dkms (2.0.3-1~bpo10+1) ... Setting up zfs-dkms (2.0.3-1~bpo10+1) ... Loading new zfs-2.0.3 DKMS files... It is likely that 5.10.63-rockchip64 belongs to a chroot's host Building for 5.15.25-rockchip64 Building initial module for 5.15.25-rockchip64 configure: error: *** None of the expected "capability" interfaces were detected. *** This may be because your kernel version is newer than what is *** supported, or you are using a patched custom kernel with *** incompatible modifications. *** *** ZFS Version: zfs-2.0.3-1~bpo10+1 *** Compatible Kernels: 3.10 - 5.10 Error! Bad return status for module build on kernel: 5.15.25-rockchip64 (aarch64) Consult /var/lib/dkms/zfs/2.0.3/build/make.log for more information. /var/lib/dkms/zfs/2.0.3/build/make.log: DKMS make.log for zfs-2.0.3 for kernel 5.15.25-rockchip64 (aarch64) Fri 01 Apr 2022 05:38:22 PM UTC make: *** No targets specified and no makefile found. Stop. I try then to perform a fresh installation of the system by downloading Armbian_21.08.2_Helios64_buster_current_5.10.63, and then it goes worst since I can't download the header through armbian-config (nothing happen), and apt install linux-headers-current-rockchip64 keep installing the sources for 5.15 ('/usr/src/linux-headers-5.15.25-rockchip64'). So the problem how I see it is either to: * Get the linux-headers of the previous kernel. * obtaining a zfs-dkms version compatible with 5.15 Thank you in advance for your help. PS: I am aware of the docker alternative, but I prefer to use zfs-dkms.

I accidentally ripped off a capacitor from the back of the Helios64. This missing capacitor is right below the SATA connector. I searched for the schematic of the board without any success. Does anyone happen to know the value and size of this capacitor?

Hello, I received recently an Helios64 from a new friend, However, when I get home, I plug it in, turn it on (already I have to press the power button for 4 seconds to get some life) and I get the following LEDs lit up: - LED1 - LED2 - LED3 - LED5 - LED6 i got nothing on the serial line (tested on MacOS and Windows), and no reaction when I do quick and long press on Recovery nor Reset. Is there some electronic schematic that could help me to debug hardware or procedure to get JTAG access to the RK3399 ? Regards,

Hey guys. I have helios64 with 5x WD14tb red pro.... and ZFS fs. but currently im out of free space I want to extend somehow my storage pool. I'm wonder if it's possible to buy additional storage enclosure like from QNAP ( TL-D800C) - JBOD 1 x USB 3.2 Gen 2 type C and put additional 8x HDD I wanted to create additional ZFS pool raidz1 Do You think it will work?

Feels like this should be on here so everyone knows https://blog.kobol.io/2021/08/25/we-are-pulling-the-plug/

Hello, My NAS becomes unresponsive every time I run a somewhat CPU-intensive task: indexing photos in photoprism, importing followings in Mastodon… or just browsing Mastodon. Is it expected of the Rockchip RK3399 or can I improve the situation with the right CPUfreq config ? For context, here is my CPUfreq config and kernel (I have yet to update): axel@helios64:~$ cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR=performance MAX_SPEED=1200000 MIN_SPEED=1200000 axel@helios64:~$ uname -a Linux helios64 5.10.21-rockchip64 #21.02.3 SMP PREEMPT Mon Mar 8 01:05:08 UTC 2021 aarch64 GNU/Linux Thanks!

I'm sick of having to play reset-it-until-it-boots-then-it-reboots-later game, anyone know a similar motherboard I can use in place of the helios64 with minimal extra messing around? I totally understand that the front and back panel will be a problem to set up, I just don't want to have to hack the main case part, and have support for the five SATA ports.

Not sure if this is the place for this since it isn't really a software issue, but... So I decided to take apart my Helios64 to apply the 2.5Gb/1Gb Ethernet fix and things went badly. I ended up accidentally destroying the 402 caps on one of the SATA ports by scrapping the board against the standoffs as I was pulling it out of the case. As far as I can tell, they should be part of the SATA standard, 10nF DC blocking caps, so I have a rough idea of what they might have been but I don't know for sure since they are simply gone. Does anyone happen to know what those caps were or have access to a circuit diagram or BOM I could reference? It would be nice to replace them with the original part number. I did find the information for the Helios4, but I don't know if those are the same and that exact part seems impossible to get anyway. Thanks for reading.

Hey guys, I figured it was time to ask again... Does doing an `apt full-upgrade` from Buster to Bullseye break anything like before a year ago? I kind of want to do it, but not if the eMMC issues are still around. I really prefer not using the slower SD card method. And i also want to ask about stability for people that still use a Kobol with Armbian on Bullseye. Any pertinent issues with anything? A few people on here have claimed that they have gotten the vanilla Debian kernel to run on the Helios64, but I'm not sure how... Sure would be great if the vanilla Debian distro worked on this board, but I doubt that'll ever happen... I love my Kobol, and I am going to have a hard time finding a good replacement for it. i just really like having full CLI access, complete understanding of all the hardware, little to no proprietary bits, and also the open-ness of the hardware. It's all great. But man, finding alternatives NASes is going to be hard for me now. Hahaha. (Please ignore the fact that I posted this on April Fools Day. That's just a coincidence).

even though I disabled DVFS : $ cat /etc/default/cpufrequtils ENABLE="true" GOVERNOR=conservative MAX_SPEED=1416000 MIN_SPEED=1416000 I had a few random reboot. I disabled zswap and , since I get this kind of trace about it: mars 30 22:15:29 helios64 kernel: ------------[ cut here ]------------ mars 30 22:15:29 helios64 kernel: kernel BUG at mm/zswap.c:1313! mars 30 22:15:29 helios64 kernel: Internal error: Oops - BUG: 0 [#1] PREEMPT SMP mars 30 22:15:29 helios64 kernel: Modules linked in: binfmt_misc softdog veth xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter br_netfilter bridge governor_performance aufs zram quota_v2 quota_tree ftdi_sio r8152 usbserial snd_soc_hdmi_codec leds_pwm snd_soc_rockchip_i2s snd_soc_rockchip_pcm gpio_charger pwm_fan snd_soc_core panfrost gpu_sched snd_pcm_dmaengine snd_pcm snd_timer snd hantro_vpu(C) soundcore rockchip_vdec(C) rockchip_rga rockchip_iep v4l2_h264 fusb302 videobuf2_dma_contig sg videobuf2_vmalloc v4l2_mem2mem videobuf2_dma_sg tcpm videobuf2_memops videobuf2_v4l2 videobuf2_common typec videodev mc gpio_beeper cpufreq_dt nfsd dm_mod auth_rpcgss nfs_acl lockd grace sunrpc ledtrig_netdev lm75 ip_tables x_tables autofs4 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear realtek raid10 uas dwmac_rk stmmac_platform mars 30 22:15:29 helios64 kernel: md_mod stmmac pcs_xpcs adc_keys mars 30 22:15:29 helios64 kernel: CPU: 4 PID: 3214 Comm: containerd-shim Tainted: G C 5.15.29-rockchip64 #trunk.0010 mars 30 22:15:29 helios64 kernel: Hardware name: Helios64 (DT) mars 30 22:15:29 helios64 kernel: pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) mars 30 22:15:29 helios64 kernel: pc : zswap_frontswap_load+0x320/0x330 mars 30 22:15:29 helios64 kernel: lr : zswap_frontswap_load+0x218/0x330 mars 30 22:15:29 helios64 kernel: sp : ffff80000e363b10 mars 30 22:15:29 helios64 kernel: x29: ffff80000e363b10 x28: 000000000000094b x27: ffff0000f5526080 mars 30 22:15:29 helios64 kernel: x26: ffff800009b3d700 x25: 0000000000002690 x24: 00000000ffffffea mars 30 22:15:29 helios64 kernel: x23: ffff00000f2e9980 x22: ffff00000f2e9988 x21: ffff8000094f49c8 mars 30 22:15:29 helios64 kernel: x20: fffffbffeffcb170 x19: ffff00003319e4d0 x18: 00000000000000ff mars 30 22:15:29 helios64 kernel: x17: 00000000ffffffff x16: 0000000000000001 x15: 5165ca840ace4dcb mars 30 22:15:29 helios64 kernel: x14: ffff80000b7e257e x13: ffff80000b7e257e x12: 0000000000000001 mars 30 22:15:29 helios64 kernel: x11: ffff80000b08d6ad x10: 000000000000000b x9 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x8 : 0000000000000209 x7 : ffff80000e363a70 x6 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x5 : 0000000000000001 x4 : 0000000000000030 x3 : 0000000000000001 mars 30 22:15:29 helios64 kernel: x2 : 0000000000000000 x1 : ffff000004f50e80 x0 : 0000000100000000 mars 30 22:15:29 helios64 kernel: Call trace: mars 30 22:15:29 helios64 kernel: zswap_frontswap_load+0x320/0x330 mars 30 22:15:29 helios64 kernel: __frontswap_load+0x88/0x168 mars 30 22:15:29 helios64 kernel: swap_readpage+0x1a8/0x3c0 mars 30 22:15:29 helios64 kernel: do_swap_page+0x4e0/0x6c8 mars 30 22:15:29 helios64 kernel: __handle_mm_fault+0x5e4/0xdd0 mars 30 22:15:29 helios64 kernel: handle_mm_fault+0xe8/0x278 mars 30 22:15:29 helios64 kernel: do_page_fault+0x1e0/0x448 mars 30 22:15:29 helios64 kernel: do_translation_fault+0x58/0x68 mars 30 22:15:29 helios64 kernel: do_mem_abort+0x40/0xb0 mars 30 22:15:29 helios64 kernel: el0_da+0x24/0x58 mars 30 22:15:29 helios64 kernel: el0t_64_sync_handler+0x68/0xb8 mars 30 22:15:29 helios64 kernel: el0t_64_sync+0x180/0x184 mars 30 22:15:29 helios64 kernel: Code: 12800174 a9446bf9 17ffffc4 d4210000 (d4210000) mars 30 22:15:29 helios64 kernel: ---[ end trace 240751e909ea5fbc ]--- like https://bugzilla.kernel.org/show_bug.cgi?id=192571 . I was able to reproduce the above a few times with: stress -c 1 -m 16 --vm-keep but am unable today. As it seems zswap is useless on zram a swap, maybe it should be turned off either way. I disabled it by adding: extraargs=zswap.enabled=0 to /boot/armbianEnv.txt

In case someone is interested in a almost new Helios 64 "full bundle" with a lot of spare parts that did only run for about 3 months: https://www.ebay.de/itm/363567434154 Thanks, Paul

Hello, I have been holding onto kernel 5.10 (5.10.21-rockchip64 to be exact) for a while as it has been pretty stable for me and also because I heard bad feedback from newer kernels on the Helios 64. But with the recent discovery of the DirtyPipe exploit (which has been introduced in Linux 5.8), I might be looking to upgrade to the latest Armbian kernel (which contains a fix to the vulnerability). So, my question to fellow Helios64 users is: have you encountered any issue with kernel 5.15, especially when using OpenMediaVault 5, Docker, MergerFS and NFS?

Upgrading Helios64 from Armbian Buster to Bullseye (see below) works as expected on my system. However, I am using systemd-networkd and just a few services (nextcloud, netatalk, etc. and not ZFS) EDIT: Upgrading Buster installations to Bullseye also works fine if you use network-manager, even if you have a bridge configured (using bridge-slave; binutils-bridge). # cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" _ _ _ _ __ _ _ | | | | ___| (_) ___ ___ / /_ | || | | |_| |/ _ \ | |/ _ \/ __| '_ \| || |_ | _ | __/ | | (_) \__ \ (_) |__ _| |_| |_|\___|_|_|\___/|___/\___/ |_| Welcome to Armbian 21.08.1 Bullseye with Linux 5.10.43-rockchip64 System load: 2% Up time: 12:29 Memory usage: 19% of 3.77G IP: xx.xx.xx.xx CPU temp: 42°C Usage of /: 41% of 15G storage/: 57% of 3.6T Edit: Attention - if you upgrade your Buster or Bullseye installation on emmc to Armbian 21.08.1 it will not be writable anymore. You will then have to downgrade linux on emmc from 5.10.60 to 5.10.43 as described in this thread. Edit: There is a temporary fix for the problem. See this message from @piter75 To upgrade Armbian Buster to Bullseye, first disable Armbian updates in /etc/apt/sources.list.d/Armbian.list for the time being. Then fully upgrade Buster (sudo apt update && sudo apt upgrade -y) , then change the apt sources (see below) followed by 'sudo apt update && sudo apt full-upgrade'. I kept all the configuration files by confirming 'N' in the following dialogue. # cat /etc/apt/sources.list deb http://deb.debian.org/debian/ bullseye main deb-src http://deb.debian.org/debian/ bullseye-updates main deb http://security.debian.org/debian-security bullseye-security main deb-src http://security.debian.org/debian-security bullseye-security main deb http://ftp.debian.org/debian bullseye-backports main

Hi to all, after the 16GB of the eMMC is slowly reaching my limits, I installed a 128GB M.2 SSD and wanted to use the kobol tutorial to transfer the system data on it... https://wiki.kobol.io/helios64/install/transfer/#transfer-rootfs-from-emmc-to-sata-or-usb ... unfortunately I see at position 4 only /dev/md0 instead of the M.2 Sata on /dev/sda root@helios64:/dev# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk sdb 8:16 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 raid5 /srv/dev-disk-by-label-nas sdc 8:32 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 raid5 /srv/dev-disk-by-label-nas sdd 8:48 0 3.7T 0 disk └─md0 9:0 0 7.3T 0 raid5 /srv/dev-disk-by-label-nas mmcblk2 179:0 0 14.6G 0 disk └─mmcblk2p1 179:1 0 14.4G 0 part / mmcblk2boot0 179:32 0 4M 1 disk mmcblk2boot1 179:64 0 4M 1 disk root@helios64:/dev# does anyone know what my error is here? I use OMV and have 3 hard disk running in RAID 5. Previously the hard drives were connected to SATA 1, SATA 3 and SATA 5. I had to change the hard drive on SATA 1 to 2, because the M.2 needs the SATA 1. Is it perhaps because of this?

Like many others, I get constant reboots with my Helios. I'm not sure it's worth me posting logs as a number of people already seem to be doing that. My question is, does anyone have a stable system? If so what OS and kernel are you using? I don't care about latest and greatest features, I just want it to stop hard rebooting.

Hi! I am trying the vanilla 5.15 kernel which has support for helios64. The system is booting, disks, MMC and network are working. But fancontrol fails. It seems the /sys entries have changed and the udev rules are not working. I've tried to understand the wiki page in order to adapt the udev rules and fancontrol config file but I am a little bit lost. Is there updated versions of those config files? Kind regards, Xavier Miller.

Using P14 in the documentation (https://wiki.kobol.io/helios64/usb/#serial-console) I am unable to get a serial connection to work. Has anyone been able to get UART2 debug Serial working using P14 and an FT232 USB cable? With Kobol plug pulled looking to just have this run in DAS mode over USB-C to still get use without fear but still need to maintain serial console to monitor booting as it sometimes locks up on boot. Downclocking to 1Ghz or below conservative seems to do a lot better but still looking to have remote debug console. When I try to connect I just get the follow error and no output. pl2303_get_line_request - failed: -32

I've gotten the following messages/error the past 2 mornings. Any ideas what the problem is? CRON-APT RUN [/etc/cron-apt/config]: Sat Jan 22 07:35:28 EST 2022 CRON-APT SLEEP: 1394, Sat Jan 22 07:58:42 EST 2022 CRON-APT ACTION: 0-update CRON-APT LINE: /usr/bin/apt-get update -o quiet=2 E: Failed to fetch https://stpete-mirror.armbian.com/apt/dists/buster/main/binary-armhf/by-hash/SHA512/5d6932f3c06c2c055d95b7a09e2bd4686b4bf8756d10bb52c9c9b96b33f1adde18116d55152d9c103d1e24ef83acecdddfc32a945b60812b6818b2be5a48458c 404 Not Found [IP: 130.225.254.116 80] E: Failed to fetch https://imola.armbian.com/apt/dists/buster/main/by-hash/SHA512/1b7ba13d5e752b8c1035070d43466f71960018c32426f5f8724c9d49fe7a33a4389e818f2b86b74355a57eedb76e1cf8e4d15c980ec3843ca07061d08a540ab5 404 Not Found [IP: 130.225.254.116 80] E: Failed to fetch http://mirrors.dotsrc.org/armbian-apt/dists/buster/main/by-hash/SHA512/609db1af113c6958edd2e1b95c5d94b8f47bb919fe1dd9612a5f9747ad45fc888f849e044f8a0d46de9b2692932bf498302505ac91a06023ea3029e71c8515b6 404 Not Found [IP: 130.225.254.116 80] E: Some index files failed to download. They have been ignored, or old ones used instead.

This is a continuation of ata1.00: failed command: READ FPDMA QUEUED noted by @djurny. I've experienced the same issue, and have some additional data points to provide. My observations so far: I'm using WDC WD60EFRX (68MYMN1 and 68L0BN1) drives The drives were working without issue previously behind a ASMedia ASM1062 SATA Controller, I've also used some of them behind ASM1542 (external eSATA enclosure) I can reproduce the issue on a clean install of Armbian 20.08.21 Buster and Focal I can reproduce via simple `dd` to `/dev/null` from the drive so filesystem does not seem to be the underlying cause Every drive is affected (i.e. each SATA slot) At what point dd produces an error varies from SATA slot to SATA slot (not drive dependent), SATA slot 4 can reproducibly produce the error almost immediately after starting a read The problem goes away when setting `extraargs=libata.force=3.0` in `/boot/armbianEnv.txt` [1] [1] However, even with SATA limited to 3 Gbps, the problem did reappear when hot-plugging a drive. This reset happened on drive slot 3 when I hot-plugged a drive onto slot 5. This seems weird to me considering they are supposed to be on different power rails. This may suggest there is in general a problem with either the PSU or power delivery to the drives. Here's an excerpt from the reset: [152957.354311] ata3.00: exception Emask 0x10 SAct 0x80000000 SErr 0x9b0000 action 0xe frozen [152957.354318] ata3.00: irq_stat 0x00400000, PHY RDY changed [152957.354322] ata3: SError: { PHYRdyChg PHYInt 10B8B Dispar LinkSeq } [152957.354328] ata3.00: failed command: READ FPDMA QUEUED [152957.354335] ata3.00: cmd 60/58:f8:00:f8:e7/01:00:71:02:00/40 tag 31 ncq dma 176128 in res 40/00:f8:00:f8:e7/00:00:71:02:00/40 Emask 0x10 (ATA bus error) [152957.354338] ata3.00: status: { DRDY } [152957.354345] ata3: hard resetting link And the full dmesg from when the error happened is below:

Hi, I got write errors on the eMMC, and the filesystem becomes read-only. Dmesg shows that: [ 304.982737] mmc2: running CQE recovery [ 304.987677] mmc2: running CQE recovery [ 304.989762] blk_update_request: I/O error, dev mmcblk2, sector 26826008 op 0x1:(WRITE) flags 0x4000 phys_seg 127 prio class 0 [ 304.989791] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789645 starting block 3353569) [ 305.021383] mmc2: running CQE recovery [ 305.026213] mmc2: running CQE recovery [ 305.030808] mmc2: running CQE recovery [ 305.032702] blk_update_request: I/O error, dev mmcblk2, sector 26265544 op 0x1:(WRITE) flags 0x4000 phys_seg 111 prio class 0 [ 305.033382] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 793979 starting block 3283345) [ 305.109165] mmc2: running CQE recovery [ 305.114772] mmc2: running CQE recovery [ 305.120284] mmc2: running CQE recovery [ 305.125405] mmc2: running CQE recovery [ 305.126960] blk_update_request: I/O error, dev mmcblk2, sector 25560376 op 0x1:(WRITE) flags 0x0 phys_seg 15 prio class 0 [ 305.126976] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789517 starting block 3195094) [ 305.128183] mmc2: running CQE recovery [ 305.132052] mmc2: running CQE recovery [ 305.138255] mmc2: running CQE recovery [ 305.143172] mmc2: running CQE recovery [ 305.143705] blk_update_request: I/O error, dev mmcblk2, sector 25568256 op 0x1:(WRITE) flags 0x0 phys_seg 11 prio class 0 [ 305.143719] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789519 starting block 3196066) [ 305.146059] mmc2: running CQE recovery [ 305.150856] mmc2: running CQE recovery [ 305.153652] blk_update_request: I/O error, dev mmcblk2, sector 25566136 op 0x1:(WRITE) flags 0x0 phys_seg 14 prio class 0 [ 305.153674] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789524 starting block 3195813) [ 305.156107] mmc2: running CQE recovery [ 305.161761] mmc2: running CQE recovery [ 305.166281] mmc2: running CQE recovery [ 305.173900] mmc2: running CQE recovery [ 305.179678] mmc2: running CQE recovery [ 305.184108] mmc2: running CQE recovery [ 305.189973] mmc2: running CQE recovery [ 305.192654] blk_update_request: I/O error, dev mmcblk2, sector 25550264 op 0x1:(WRITE) flags 0x0 phys_seg 6 prio class 0 [ 305.192674] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789534 starting block 3193811) [ 305.195645] mmc2: running CQE recovery [ 305.201382] mmc2: running CQE recovery [ 305.206397] mmc2: running CQE recovery [ 305.209876] mmc2: running CQE recovery [ 305.212505] EXT4-fs warning (device mmcblk2p1): ext4_end_bio:345: I/O error 10 writing to inode 789547 starting block 3194323) [ 305.215282] mmc2: running CQE recovery [ 305.267254] mmc2: running CQE recovery [ 305.272126] mmc2: running CQE recovery [ 305.276368] mmc2: running CQE recovery [ 305.282479] mmc2: running CQE recovery [ 305.287200] mmc2: running CQE recovery [ 305.291543] mmc2: running CQE recovery [ 305.315011] JBD2: Detected IO errors while flushing file data on mmcblk2p1-8 [ 305.317983] mmc2: running CQE recovery [ 305.322443] mmc2: running CQE recovery [ 305.329227] mmc2: running CQE recovery [ 305.330168] Aborting journal on device mmcblk2p1-8. [ 305.332721] mmc2: running CQE recovery [ 305.333640] EXT4-fs error (device mmcblk2p1): ext4_journal_check_start:83: Detected aborted journal [ 305.334031] EXT4-fs (mmcblk2p1): Remounting filesystem read-only [ 305.334048] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794035, error -30) [ 305.334380] EXT4-fs error (device mmcblk2p1): ext4_journal_check_start:83: Detected aborted journal [ 305.335183] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794033, error -30) [ 305.336335] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794038, error -30) [ 305.337472] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794037, error -30) [ 305.337497] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794036, error -30) [ 305.339676] EXT4-fs (mmcblk2p1): failed to convert unwritten extents to written extents -- potential data loss! (inode 794039, error -30) I did a fsck, and rebooted, but it gives the same kind of errors after that, It seems I cannot write on eMMC anymore. I use eMMC to store the boot script + a rescue subsystem (I boot it by renaming /boot.rescue to /boot). It is formatted as a ext4 partition. What can I do to get back to a sane state ? Kind regards, Xavier Miller.

If Helios/Kobol is out of business - What "specs" should I use to define a replacement board - a rockchip 3399 board with the dimensions ? Help please -- (I'm getting an increased number of memory errors and of late an increased number of USB faults) I'm running (at the moment) - the system as a simple NAS with exported NFS4 volumes - the entire lot of 5 drives are formatted at BTRFS -- I'm working on archiving the data off and once done I'll format all as ext4 and try using simple RAID. Rich Leonard

A few Armbian packages were updated (armbian-bsp-cli-helios64, armbian-config, armbian-firmware &armbian-zsh) to version 21.05.08. At some point I noticed that the fancontrol service had failed to start up after the reboot - it was complaining about a file missing(/dev/thermal-cpu). If you run into this after the update, just update your /etc/fancontrol to the content below and your fancontrol should go back to normal. # Helios64 PWM Fan Control Configuration # Temp source : /dev/thermal-cpu # After 21.05.08 [2021.08.10] # Temp source : /dev/thermal-board INTERVAL=10 # FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-cpu/temp1_input /dev/fan-p7/pwm1=/dev/thermal-cpu/temp1_input # After 21.05.08 [2021.08.10] FCTEMPS=/dev/fan-p6/pwm1=/dev/thermal-board/temp1_input /dev/fan-p7/pwm1=/dev/thermal-board/temp1_input MINTEMP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MAXTEMP=/dev/fan-p6/pwm1=110 /dev/fan-p7/pwm1=110 MINSTART=/dev/fan-p6/pwm1=60 /dev/fan-p7/pwm1=60 MINSTOP=/dev/fan-p6/pwm1=40 /dev/fan-p7/pwm1=40 MINPWM=20

Posting here following what was recommended on twitter. After updating my helios64 earlier this week and rebooting to get the new kernel, I realized it was suspiciously silent. A quick check to sensor temps readings and physical check made me realize the fan were not spinning. After a quick read on the wiki, I checked fancontrol which was indeed failing: root@helios64:~ # systemctl status fancontrol.service ● fancontrol.service - fan speed regulator Loaded: loaded (/lib/systemd/system/fancontrol.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/fancontrol.service.d └─pid.conf Active: failed (Result: exit-code) since Fri 2021-05-28 00:08:13 CEST; 1min 42s ago Docs: man:fancontrol(8) man:pwmconfig(8) Process: 2495 ExecStartPre=/usr/sbin/fancontrol --check (code=exited, status=0/SUCCESS) Process: 2876 ExecStart=/usr/sbin/fancontrol (code=exited, status=1/FAILURE) Main PID: 2876 (code=exited, status=1/FAILURE) May 28 00:08:13 helios64 fancontrol[2876]: MINPWM=0 May 28 00:08:13 helios64 fancontrol[2876]: MAXPWM=255 May 28 00:08:13 helios64 fancontrol[2876]: AVERAGE=1 May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: Error: file /dev/thermal-cpu/temp1_input doesn't exist May 28 00:08:13 helios64 fancontrol[2876]: At least one referenced file is missing. Either some required kernel May 28 00:08:13 helios64 fancontrol[2876]: modules haven't been loaded, or your configuration file is outdated. May 28 00:08:13 helios64 fancontrol[2876]: In the latter case, you should run pwmconfig again. May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE May 28 00:08:13 helios64 systemd[1]: fancontrol.service: Failed with result 'exit-code'. Basically fancontrol expect a device in /dev to read the sensors value from, and that device seems to be missing. After a bit of poking around and learning about udev, I managed to manually solve the issue by recreating the device symlink manually: /usr/bin/mkdir /dev/thermal-cpu/ ln -s /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input systemctl restart fancontrol.service systemctl status fancontrol.service Now digging more this issue happen because udev is not creating the symlink like it should for some reason. After reading the rule in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and a bit of udev documentation, I managed to find how to test it: root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] Reading rules file: /etc/udev/rules.d/90-helios64-hwmon-legacy.rules Reading rules file: /etc/udev/rules.d/90-helios64-ups.rules [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0 USEC_INITIALIZED=7544717 run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0 ' <-- something is wrong here, there is no target Unload module index Unloaded link configuration context. After spending a bit more time reading the udev rule, I realized that the second argument was empty because we don't match the ATTR{type}=="soc-thermal" condition. We can look up the types like this: root@helios64:~ # find /sys/ -name type | grep thermal /sys/devices/virtual/thermal/cooling_device1/type /sys/devices/virtual/thermal/thermal_zone0/type /sys/devices/virtual/thermal/cooling_device4/type /sys/devices/virtual/thermal/cooling_device2/type /sys/devices/virtual/thermal/thermal_zone1/type /sys/devices/virtual/thermal/cooling_device0/type /sys/devices/virtual/thermal/cooling_device3/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/gpu/trips/gpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_crit/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert0/type /sys/firmware/devicetree/base/thermal-zones/cpu/trips/cpu_alert1/type root@helios64:~ # cat /sys/devices/virtual/thermal/thermal_zone0/type cpu <-- we were expecting soc-thermal! and after rewriting the line with the new type, udev is happy again # Edit in /etc/udev/rules.d/90-helios64-hwmon-legacy.rules and add the following line after the original one ATTR{type}=="cpu", ENV{HWMON_PATH}="/sys%p/temp", ENV{HELIOS64_SYMLINK}="/dev/thermal-cpu/temp1_input", RUN+="/usr/bin/mkdir /dev/thermal-cpu/" root@helios64:~ # udevadm control --reload root@helios64:~ # udevadm test /sys/devices/virtual/thermal/thermal_zone0 [...] DEVPATH=/devices/virtual/thermal/thermal_zone0 ACTION=add SUBSYSTEM=thermal IS_HELIOS64_HWMON=1 HWMON_PATH=/sys/devices/virtual/thermal/thermal_zone0/temp HELIOS64_SYMLINK=/dev/thermal-cpu/temp1_input USEC_INITIALIZED=7544717 run: '/usr/bin/mkdir /dev/thermal-cpu/' run: '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0/temp /dev/thermal-cpu/temp1_input' Unload module index Unloaded link configuration context. Apparently for some reason the device-tree changed upstream and the thermal type changed from soc-thermal to cpu?

Hello to everybody ! I'm new to this forum and to linux. After installing my Helios64 recently, I had a few problems and had to go with the eMMC maskrom installation which were fine. PS : I've installed on top of the linux kernel (4.4) Open Media Vault (latest version). After installing everything, I've noticed that the fans were not functioning. I've checked the documentation on kobol.io site and went to the /etc/fancontrol config file and set the values as it was shown on the doc. I've restarted the fancontrol service, but still nothing. I've tried to read the pwm of my fans (has fan P7 were linked to the hwmon0 : cat /sys/class/hwmon0/pwm1) and i had the following message "No such file or directory" Can somebody help me : I'm scared about this issue and will shut down the NAS until I found a solution. Best regards, Pramil

Hi! I'm trying to install NUT because I connected a UPS device. I'd like to get it working so that the server is shutdown safely when there is a power interruption and that I get an e-mail notifying me as soon as there is an interruption. Already after installing via sudo apt install nut nut-client nut-server I get the following warnings: Setting up nut-client (2.7.4-8) ... Job for nut-monitor.service failed because the service did not take the steps required by its unit configuration. See "systemctl status nut-monitor.service" and "journalctl -xe" for details. invoke-rc.d: initscript nut-client, action "restart" failed. ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Sat 2021-12-11 16:33:11 CET; 24ms ago Process: 24611 ExecStart=/sbin/upsmon (code=exited, status=0/SUCCESS) Dec 11 16:33:11 helios64 systemd[1]: Starting Network UPS Tools - power device monitor and shutdown controller... Dec 11 16:33:11 helios64 upsmon[24611]: upsmon disabled, please adjust the configuration to your needs Dec 11 16:33:11 helios64 upsmon[24611]: Then set MODE to a suitable value in /etc/nut/nut.conf to enable it Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Failed with result 'protocol'. Dec 11 16:33:11 helios64 systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller. And the output of systemctl status nut-monitor.service is: ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; vendor preset: enabled) Active: failed (Result: protocol) since Sat 2021-12-11 16:33:11 CET; 5min ago Dec 11 16:33:11 helios64 upsmon[24611]: upsmon disabled, please adjust the configuration to your needs Dec 11 16:33:11 helios64 upsmon[24611]: Then set MODE to a suitable value in /etc/nut/nut.conf to enable it Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory Dec 11 16:33:11 helios64 systemd[1]: nut-monitor.service: Failed with result 'protocol'. Dec 11 16:33:11 helios64 systemd[1]: Failed to start Network UPS Tools - power device monitor and shutdown controller. Dec 11 16:33:12 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:13 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:13 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:14 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat Dec 11 16:33:15 helios64 systemd[1]: /lib/systemd/system/nut-monitor.service:6: PIDFile= references path below legacy directory /var/run/, updat And I can't use stuf like nut-scanner so the packages aren't completely installed. Googling around just confused me because it's not even clear to me where the mistake is or how to fix it. Any help is appreciated, even if just in form of "go there and ask them".