Search the Community

I'm in the process of upgrading my network and with the Helios64 capable of 2.5 GbE, what are some people's switch recommendations? My needs aren't really too high so I think 5 ports should be enough until the rest of the infrastructure catches up in my home network. My short-list are: * QNAP QSW-1105-5T * TP Link TL-SG105-M2 * TRENDnet TEG-S350 Article from servethehome

Today I updated and upgraded my system, and after a reboot 'apt list' did no longer work. It shows 'Listing... done', and then uses 100% CPU on a single core, without producing anything. According to strace it's looping on reading a file: openat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.lz4", O_RDONLY) = 28 read(28, "\4\"M\30@@\300\206z\0\0\370\377\31Package: 0ad-data\n"..., 65536) = 65536 read(28, "ta$E\17p\2+\377\21c376d3f140540d9424753d"..., 65536) = 65536 read(28, "a5180e3e2d3f503ddcb5dd7b93\201\2\2\275\0\17"..., 65536) = 65536 read(28, "\2\3700071880bc23623a4ea3664b773a1b6"..., 65536) = 65536 read(28, "\f1'da?\2Jdan_\207\1\v=\2f215438\272\t\365\0213e4c"..., 65536) = 65536 read(28, "a6f6005b836871a9cc032472bbece3b7"..., 65536) = 65536 read(28, "3783a1460d749c6f887843fdd95ec981"..., 65536) = 65536 read(28, "\4\0032 - \16\1\0022\32\t?\27\177foreign\270\0041\370\21f1e69"..., 65536) = 65536 read(28, "dR\203\1\6\4\6T\37\3\324\0\",\ng_zplaying\2759\vt\203\1\233"..., 65536) = 65536 read(28, "\20u://ftp.\24'_nu/bc\2\3\0\363\20b8da7e3f11"..., 65536) = 65536 close(28) = 0 openat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.lz4", O_RDONLY) = 28 read(28, "\4\"M\30@@\300\206z\0\0\370\377\31Package: 0ad-data\n"..., 65536) = 65536 read(28, "ta$E\17p\2+\377\21c376d3f140540d9424753d"..., 65536) = 65536 read(28, "a5180e3e2d3f503ddcb5dd7b93\201\2\2\275\0\17"..., 65536) = 65536 read(28, "\2\3700071880bc23623a4ea3664b773a1b6"..., 65536) = 65536 read(28, "\f1'da?\2Jdan_\207\1\v=\2f215438\272\t\365\0213e4c"..., 65536) = 65536 read(28, "a6f6005b836871a9cc032472bbece3b7"..., 65536) = 65536 read(28, "3783a1460d749c6f887843fdd95ec981"..., 65536) = 65536 read(28, "\4\0032 - \16\1\0022\32\t?\27\177foreign\270\0041\370\21f1e69"..., 65536) = 65536 read(28, "dR\203\1\6\4\6T\37\3\324\0\",\ng_zplaying\2759\vt\203\1\233"..., 65536) = 65536 read(28, "\20u://ftp.\24'_nu/bc\2\3\0\363\20b8da7e3f11"..., 65536) = 65536 close(28) = 0 openat(AT_FDCWD, "/var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.lz4", O_RDONLY) = 28 read(28, "\4\"M\30@@\300\206z\0\0\370\377\31Package: 0ad-data\n"..., 65536) = 65536 read(28, "ta$E\17p\2+\377\21c376d3f140540d9424753d"..., 65536) = 65536 read(28, "a5180e3e2d3f503ddcb5dd7b93\201\2\2\275\0\17"..., 65536) = 65536 read(28, "\2\3700071880bc23623a4ea3664b773a1b6"..., 65536) = 65536 read(28, "\f1'da?\2Jdan_\207\1\v=\2f215438\272\t\365\0213e4c"..., 65536) = 65536 read(28, "a6f6005b836871a9cc032472bbece3b7"..., 65536) = 65536 read(28, "3783a1460d749c6f887843fdd95ec981"..., 65536) = 65536 read(28, "\4\0032 - \16\1\0022\32\t?\27\177foreign\270\0041\370\21f1e69"..., 65536) = 65536 read(28, "dR\203\1\6\4\6T\37\3\324\0\",\ng_zplaying\2759\vt\203\1\233"..., 65536) = 65536 read(28, "\20u://ftp.\24'_nu/bc\2\3\0\363\20b8da7e3f11"..., 65536) = 65536 close(28) = 0 This repeats over and over. I checked the file /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.lz4, and it seems valid, as in, lz4 decompresses it without complaints. When I put the decompressed /var/lib/apt/lists/deb.debian.org_debian_dists_buster_main_binary-arm64_Packages in the same directory, 'apt list' works. What is going on? It might be size related. The file is the biggest *_Packages.lz4 file in that directory. There are bigger lz4 files, but according to strace they are not accessed. The timestamp of deb.debian.org_debian_dists_buster_main_binary-arm64_Packages.lz4 is Dec 5 11:03, so I don't think it grew, at last update. The upgraded files are: Start-Date: 2021-01-17 14:07:30 Commandline: apt upgrade Requested-By: rockbian (1000) Install: javascript-common:arm64 (11, automatic), php-symfony-yaml:arm64 (3.4.22+dfsg-2+deb10u1, automatic), libjs-codemirror:arm64 (5.43.0-1+deb10u1, automatic), libjs-popper.js:arm64 (1.14.6+ds2-1, automatic), libjs-jquery-mousewheel:arm64 (1:3.1.13-2, automatic), php-symfony-filesystem:arm64 (3.4.22+dfsg-2+deb10u1, automatic), libjs-jquery-timepicker:arm64 (1.2-1, automatic), php-symfony-dependency-injection:arm64 (3.4.22+dfsg-2+deb10u1, automatic), libjs-jquery-ui:arm64 (1.12.1+dfsg-5, automatic), libjs-bootstrap4:arm64 (4.3.1+dfsg2-1, automatic), php-symfony-config:arm64 (3.4.22+dfsg-2+deb10u1, automatic), php-twig-i18n-extension:arm64 (3.0.0-2~bpo10+1, automatic) Upgrade: nodejs:arm64 (10.21.0~dfsg-1~deb10u1, 10.23.1~dfsg-1~deb10u1), python-apt-common:arm64 (1.8.4.2, 1.8.4.3), phpmyadmin:arm64 (4:4.9.7+dfsg1-1~bpo10+1, 4:5.0.4+dfsg2-1~bpo10+1), php-google-recaptcha:arm64 (1.2.4-1~bpo10+1, 1.2.4-3~bpo10+1), linux-buster-root-current-helios64:arm64 (20.11.4, 20.11.6), armbian-config:arm64 (20.11.3, 20.11.6), libnode64:arm64 (10.21.0~dfsg-1~deb10u1, 10.23.1~dfsg-1~deb10u1), libp11-kit0:arm64 (0.23.15-2, 0.23.15-2+deb10u1), php-mariadb-mysql-kbs:arm64 (1.2.11-1~bpo10+1, 1.2.12-1~bpo10+1), python3-apt:arm64 (1.8.4.2, 1.8.4.3), tzdata:arm64 (2020d-0+deb10u1, 2020e-0+deb10u1), linux-u-boot-helios64-current:arm64 (20.11.4, 20.11.6) End-Date: 2021-01-17 14:08:10

Sorry to repeat another case of this. Have attempted a few times to move boot from SD card to eMMC before the SD card fails. I did according to the wiki doc with nand-sata-install. Since I have OMV, I excluded the exports, and also afterward copied the salt and pillar. Also, in another attempt, on suggestion from another thread, I updated the boot loader and copied again. I can boot to my SD card, mount the eMMC, and see the root structure. From what I can tell in reading the boot output, it can't find any storage device? 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found But I can see it when the OS is up, mount and read it, and nand-sata-install can write to it. Here's the boot output: DDR Version 1.24 20191016 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 253 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 SdmmcInit=0 1 StorageInit ok = 67744 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xe5674 RunBL31 0x40000 �NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.10-armbian (Jan 05 2021 - 00:07:57 +0100) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 DDR Version 1.24 20191016 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 254 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 SdmmcInit=0 1 StorageInit ok = 67748 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xe5674 RunBL31 0x40000 �NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.10-armbian (Jan 05 2021 - 00:07:57 +0100) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: eth0: ethernet@fe300000 scanning bus for devices... starting USB... Bus usb@fe380000: USB EHCI 1.00 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe380000 for devices... 1 USB Device(s) found scanning bus dwc3 for devices... cannot reset port 4!? 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3185 bytes read in 19 ms (163.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 0 359 bytes read in 15 ms (22.5 KiB/s) 16181146 bytes read in 1556 ms (9.9 MiB/s) 27507200 bytes read in 2631 ms (10 MiB/s) 81696 bytes read in 41 ms (1.9 MiB/s) Failed to load '/boot/dtb/rockchip/overlay/-fixup.scr' Moving Image from 0x2080000 to 0x2200000, end=3cd0000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 16181082 Bytes = 15.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f4f81000, end f5eef75a ... OK Loading Device Tree to 00000000f4f04000, end 00000000f4f80fff ... OK Starting kernel ...

Dear Forum! If you are using Emmc as boot device, a M.2-ssd as system device and OMV is installed. You can backup with the OMV given image-backup (dd, fsarchiver). But how you can restore the backup? You need to boot from Sdcard (boot and system from sd)? And after that you can switch again back to emmc-boot and ssd-system without any issue? Is there any other easier way i.e. with CloneZilla to image-backup/restore? How you can do this?

I was trying to avoid opening a new instability topic, but this one seems different enough from the others to deserve it's own discussion. A few days ago I applied the 1G fix (pic attached) to the 2.5G port - which was not in use until then, since all my hardware is 1G max. I did this with the intention of using both ports: the 1G port goes to an isolated VLAN that serves VM images to my Proxmox hosts, and the 2.5G interface (running at 1G speed) serves files to the rest of my network. While the fix appears to work and the port is able to communicate at 1G speeds seemingly fine, after changing to this setup I'm experiencing frequent drops in the USB bus, which causes both the 2.5G port and my USB HDD (which has its own PSU) to disconnect, requiring a reboot to regain connectivity. When this happens, I get these messages in dmesg: [48657.415910] xhci-hcd xhci-hcd.0.auto: xHCI host not responding to stop endpoint command. [48657.415930] xhci-hcd xhci-hcd.0.auto: USBSTS: [48657.429522] xhci-hcd xhci-hcd.0.auto: xHCI host controller not responding, assume dead [48657.429604] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up [48657.429952] r8152 4-1.4:1.0 eth1: Stop submitting intr, status -108 [48657.430068] r8152 4-1.4:1.0 eth1: get_registers -110 [48657.430193] r8152 4-1.4:1.0 eth1: Tx status -108 [48657.430223] r8152 4-1.4:1.0 eth1: Tx status -108 [48657.430241] r8152 4-1.4:1.0 eth1: Tx status -108 [48657.430262] r8152 4-1.4:1.0 eth1: Tx status -108 [48657.430327] usb 3-1: USB disconnect, device number 2 [48657.431551] usb 4-1: USB disconnect, device number 2 [48657.431572] usb 4-1.1: USB disconnect, device number 3 [48657.467516] usb 4-1.4: USB disconnect, device number 4 The problem seems to manifest more quickly if I push more data through that interface. I'm running a clean (new) install of Armbian 21.02.3, with OMV and ZFS. Full dmesg and boot log below.

I backed this early, and I have had nothing but stability problems since I built the thing. Sometimes my machine runs for as few as 6 minutes before crashing, and helpfully, it keeps clearing the systemd journal every time it starts up so I can't even see what happened just before it crashed. It crashes running OMV and Syncthing with high load, it crashes doing absolutely nothing but watching the systemd journal. It crashes doing nothing at all. When it crashes, it corrupts my files, and often the OMV Database requiring me to CONSTANTLY reset the GUI password for OMV, and then find that half of OMV isn't working. It does this on both uSD cards and on the inbuilt MMC. I'm nearing my end with this thing, how can I do a full hardware test on it in a way that will say "Yes this is working as expected" or "No this is defective."

Hi All, I am on my Helios64 (already have a Helios4). I am running 2 x 8TB, 1x 256 M2, OMV5 debian etc. I have ZFS running (from the wiki instructions) in a basic mirror format, and if I add a few drives I think it would still be a mirror, however I have the following question. It seems far more complicated than MDADM, and potentially more unstable (not in terms of the underlying technology, but in terms of changing these kernals etc every week). Do you think for an average home user that this is really worth it or will constantly need work? To change it would mean starting again, but I do not want to change the setup every month and would intend to keep it stable for media, and backing up some stuff for the next few years. Or if it is working it should be fine for the long term? Cheers Scott

Hi there, I love my Helios64 to death. I'm running MooseFS CE and MooseFS PRO. The problem is I'm absolutely hammering it with I/O and it's consistently hard crashing, and no fix I've tried helps. Should I revert to the older kernel version or something? Or is this a useful test case...

I'm experiencing a lot of issues on 5.10.x and thought a dedicated thread would make sense. I've posted some reports in other threads too. Note that 5.9.x is much more stable for me, but not without problems. I'm also experiencing what I can only refer to as boot stalls, i.e. nothing happens. Occasionally when these stalls happen there is a rcu: INFO: rcu_preempt detected stalls on CPUs/tasks trace printed. This happens on both 5.9 and 5.10. Looking at where it stalls it seems to be around the time the hardware optimizations are applied and/or graphics modules are loaded. I have currently blocked the graphics modules from loading and have moved hardware optimizations to initrd so that they will be performed earlier. Time will tell if this has an effect or not. Distro: Armbian Buster 21.02.3 Kernel: 5.10.21 /proc/cmdline: root=ZFS=rpool/ROOT/debian rootwait rootfstype=zfs earlycon console=ttyS2,1500000 consoleblank=0 loglevel=7 ubootpart=794023b5-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u libata.force=noncq earlyprintk ignore_loglevel cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 Filesystem: ZFS 2.0.3 (root on ZFS, boot from eMMC) LUKS: Yes, full disk encryption (HDD -> Partition -> LUKS -> ZFS) IO scheduler: None Panic during boot: Unable to handle kernel write to read-only memory at virtual address ffff8000100d3a54 Kernel bug (system left inoperable): Internal error: Oops - BUG: 0 [#1] PREEMPT SMP And the latest issue: WARNING: Pool 'rpool' has encountered an uncorrectable I/O failure and has been suspended. Note: The warning above was only printed the latter time, but the same symptom occurred two times within two days. I.e. everything is stuck in iowait and it's basically impossible to do anything with the system. This only happens on 5.10, and happened two times within two days. On 5.9 (ZFS 2.0.3 as well) there is no such issue. Anyway, I'm back on 5.9.14 for the time being. Just finished a full scrub of the ZFS filesystem as well, no issues or errors.

I thought I'd rebuild the NAS with the latest image in the hope that it would be more stable. Unfortunately my hopes were in vain. I was in the middle of doing an rsync and it crashed with a kernel panic. Had a look on the forum and implemented the two suggestions of limiting the cpu to 1200MHz and tweaking the voltages. CPU @ 50c as reported in the login header. Anyway after updating the setting I reboot it and it crashed immediately ! The same SMP issue that seems to have been plaguing this board since release

I’ve googled it but can’t decide, the drive works just fine (it’s the 1st of the three disks I have in the box), no performance issues when copying from/to the box. I’m currently on “Armbian 20.11”, barely get the time to play with the setup due to work assignments, plan to update soon. Thanks! (PS. Newbie here) [ 13.298079] ata1: softreset failed (1st FIS failed) [ 18.449169] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 18.467303] ata1.00: ATA-10: ST6000VN0033-2EE110, SC60, max UDMA/133 [ 18.467315] ata1.00: 11721045168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 18.470029] ata1.00: configured for UDMA/133 [ 18.470721] scsi 0:0:0:0: Direct-Access ATA ST6000VN0033-2EE SC60 PQ : 0 ANSI: 5 [ 18.472237] sd 0:0:0:0: [sda] 11721045168 512-byte logical blocks: (6.00 TB/5 .46 TiB) [ 18.472247] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 18.472299] sd 0:0:0:0: [sda] Write Protect is off [ 18.472309] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 18.472393] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, does n't support DPO or FUA [ 18.580573] sda: sda1 [ 18.583350] sd 0:0:0:0: [sda] Attached SCSI disk [ 18.949151] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 18.959809] ata2.00: ATA-10: ST6000VN0033-2EE110, SC60, max UDMA/133 [ 18.959822] ata2.00: 11721045168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 18.962526] ata2.00: configured for UDMA/133 [ 18.963133] scsi 1:0:0:0: Direct-Access ATA ST6000VN0033-2EE SC60 PQ : 0 ANSI: 5 [ 18.964436] sd 1:0:0:0: [sdb] 11721045168 512-byte logical blocks: (6.00 TB/5 .46 TiB) [ 18.964451] sd 1:0:0:0: [sdb] 4096-byte physical blocks [ 18.964520] sd 1:0:0:0: [sdb] Write Protect is off [ 18.964534] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 18.964651] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, does n't support DPO or FUA [ 19.017200] sdb: sdb1 [ 19.019847] sd 1:0:0:0: [sdb] Attached SCSI disk [ 19.441176] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 19.450989] ata3.00: ATA-10: ST6000VN0033-2EE110, SC60, max UDMA/133 [ 19.451001] ata3.00: 11721045168 sectors, multi 0: LBA48 NCQ (depth 32), AA [ 19.453715] ata3.00: configured for UDMA/133 [ 19.454064] scsi 2:0:0:0: Direct-Access ATA ST6000VN0033-2EE SC60 PQ : 0 ANSI: 5 [ 19.455164] sd 2:0:0:0: [sdc] 11721045168 512-byte logical blocks: (6.00 TB/5 .46 TiB) [ 19.455178] sd 2:0:0:0: [sdc] 4096-byte physical blocks [ 19.455248] sd 2:0:0:0: [sdc] Write Protect is off [ 19.455262] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 19.455378] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, does n't support DPO or FUA [ 19.507285] sdc: sdc1 [ 19.509063] sd 2:0:0:0: [sdc] Attached SCSI disk [ 19.767590] ata4: SATA link down (SStatus 0 SControl 300) [ 20.079588] ata5: SATA link down (SStatus 0 SControl 300)

Hi, Is TrustZone being utilized at all? I can't seem to find any documentation on what execution level Kobal is running at during boot. I assume it's dropping the Kernel into EL2? Cheers

Hi, I would like to make backup(s) of my system. The system (debian) is installed on sata SSD @ slot 1. I would like to have the backup of the system written to zfs pool on the other slots as an image. Which in case of system SSD failure, I could write back to a new SSD installed on the same slot 1, by booting to a rescue system from micro sd card. Have this kind of functionality already been implemented? Or parts of it? Linux has a bunch of backup solutions, but I suspect they might not work with the helios64 box (sd card, internal ssd). And my only helios64 box is in "production" use, so "trial and error" method is not the first option in my mind...

Hi all. Some time ago, in the release notes of a past Armbian version, I remember reading that the network LED should now be enabled by default and associated with eth0. Despite always keeping my Helios64 as up-to-date as possible, mine never lit up, but I didn't think much of it. Today I decided to investigate why, and I'm not sure where to go from here. First things first, the LED works, it's not a hardware issue. I can echo 1 and 0 to the LED path (/sys/class/leds/helios64:blue:net/brightness) and it lights on and off as expected. From what I can tell, this LED, along with the heartbeat one, is enabled by the Systemd unit helios64-heartbeat-led.service. When I check for the status of the unit, I get the following output: ● helios64-heartbeat-led.service - Enable heartbeat & network activity led on Helios64 Loaded: loaded (/etc/systemd/system/helios64-heartbeat-led.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sat 2021-03-13 00:30:52 GMT; 8min ago Process: 3740 ExecStart=/usr/bin/bash -c echo heartbeat | tee /sys/class/leds/helios64\:\:status/trigger (code=exited, status=0/SUCCESS) Process: 3744 ExecStart=/usr/bin/bash -c echo netdev | tee /sys/class/leds/helios64\:blue\:net/trigger (code=exited, status=1/FAILURE) Main PID: 3744 (code=exited, status=1/FAILURE) Mar 13 00:30:52 nas.lan systemd[1]: Starting Enable heartbeat & network activity led on Helios64... Mar 13 00:30:52 nas.lan bash[3740]: heartbeat Mar 13 00:30:52 nas.lan bash[3744]: netdev Mar 13 00:30:52 nas.lan bash[3744]: tee: '/sys/class/leds/helios64:blue:net/trigger': Invalid argument Mar 13 00:30:52 nas.lan systemd[1]: helios64-heartbeat-led.service: Main process exited, code=exited, status=1/FAILURE Mar 13 00:30:52 nas.lan systemd[1]: helios64-heartbeat-led.service: Failed with result 'exit-code'. Mar 13 00:30:52 nas.lan systemd[1]: Failed to start Enable heartbeat & network activity led on Helios64. Looking into the unit's source, I can see the line where this fails: ExecStart=bash -c 'echo netdev | tee /sys/class/leds/helios64\\:blue\\:net/trigger' And sure enough, there is no "netdev" inside /sys/class/leds/helios64:blue:net/trigger: $ cat /sys/class/leds/helios64:blue:net/trigger [none] usb-gadget usb-host kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock usbport mmc1 mmc2 disk-activity disk-read disk-write ide-disk mtd nand-disk heartbeat cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 activity default-on panic stmmac-0:00:link stmmac-0:00:1Gbps stmmac-0:00:100Mbps stmmac-0:00:10Mbps rc-feedback gpio-charger-online tcpm-source-psy-4-0022-online I'm not sure why it's not there or how does that get populated. I'm running Armbian Buster 21.02.3 with LK 5.10.21-rockchip64. Any help will be much appreciated.

Hi Folks I am about to set up my helios64 nas on an imac mini m1 or an older intel imac mini. Buying the NAS was risky for me as I am a newbie to Linux. Nevertheless fortune favours the brave and all that. I am having difficulty finding the optimal set up of my helios64 NAS Do I buy a m.2 sata ssd and 4 western digital red pro hard drives? Do the hard drives have to be identical? Assuming I am buying Western Digital WD Red Pro NAS 4TB HDD, WD4003FFBX whats the best m.2 sata to pair up with these? I do have the 2.5 inch adapter.

Hi, i have successfully installed my new helios64 and enabled zfs. Everythings works so far, but it seems I'm missing something "important" in regards to ZFS. I did the following tests: I took one of my WD 4TB Plus drives (in slot 3) and formatted the disk with a) ext4 (mkfs.ext4 /dev/sdc) b) btrfs (mkfs.btrfs /dev/sdc) and c) zfs (zpool create test /dev/sdc). Based on these 3 formats I did a "dd if=/dev/zero of=test2.bin bs=1GB count=5" to measure write performance and a "dd if=test2.bin of=/dev/null" to get the read performance (all tests were done 3 times, results averaged) The results I got look like this: a) ext4 ... avg write 165MB/s - read 180MB/s b) btrfs ... avg write 180MB/s - read 192MB/s c) zfs ... avg write 140MB/s - read 45MB/s (!) So while ext4 and btrfs produce for sequential read / write pretty much the same (and expected) results, zfs seems to be significantly slower in write and dramaticially slower in read performance. I need to admit, I'm new to zfs ... but is this expected / normal? zfs has tonns of parameters to tune performance - are there any settings which are "needed" to achive almost the same values as e.g. with btrfs? (honestly, I expected to perform zfs equally to btrfs - as zfs should be the more "mature" file system ...) thanks! A

My Helios64 has been booting from an M.2 drive since I got it, and while I've been doing regular apt-upgrades I've been ignoring the bootloader. This post suggests that could be a problem, so I figured I'd upgrade the bootloader through armbian-config. Trouble is, I can't. I can load armbian-config without error, but when I go into System there's no Install option any more. All I have are Freeze, Nightly, Lowlevel, Bootenv, CPU, Avahi, Hardware, Other, SSH, Firmware, ZSH, Default. Is there another way to ensure the bootloader is up-to-date?

Thought I'd download the latest image in the hope that it might be more stable ... kernel panic on reboot, booted second time and then whlst trying to update kernel panic again. This board seems to be so unstable it's bascially unuseable

Hello, i want use and control kodi on my Helios64 with the tv remote. Have someone experiance with that and a recommendation for cables or usb c dockingstation? thank you

Curious if anybody else with tick-stop error? Not certain if this applies; the only change is installing Docker and Pi-Hole containerized. A quick read seems related to a soft interrupt of 8; - The only solution I could find by googling; is: "Add nohz=off to the kernel parameters during boot to disable it." Can I safely ignore this error message; or should I do this nohz=off to the kernel parms?

Hi, On an up-to-date Helios64, around 50% of boots are stuck at "Starting kernel ...". As device is having kernel panics every day, it reboots and then sometimes can't start, stuck on this. When will we have a stable device ? I can't understand selling devices which just can't run !

Hey there, so I was curious is there an easier way to make microSD take precedence in the boot order then having to futz with jumpers? Wanting to try out a new distro on microSD before deciding to make the switch and flash it to eMMC. If I do futz with jumpers I'll still be able to mount and write to the eMMC correct?

I'm having an aggressive memory leak issue I can't place: Within 5 minutes the 4GB are full. htop and top don't show a massive program growing unbouded. `df` doesn't show a tmpfs that is too large. Only `slabtop` is imforative: OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 26638624 26638624 99% 0.12K 832457 32 3329828K kmalloc-128 So `kmalloc-128` is growing without bounds. As I understand it kmalloc is a collection of smaller memory allocations? I've tried using a previous kernel version (5.10.16 and 5.10.12) but nada. I've disabled docker, and that along with omv were the only services running. Any suggestions would be great!

I have installed OMV via armbian-config (software). After that I tried to install Nextcloud the same way. In the process I noticed that Apache2 does not start due to a port mismatch (port 80). I was able to determine that obviously the web server nginx is already installed and used for OMV. Can someone please explain to me if this is intentional or if I made a mistake during the installation? Is it possible not to install OMV and Nextcloud in parallel? How can I solve this?

Hello, After I first installed my Helios64, I feared the 16Gb eMMC would be quickly filled. So when I used nand-sata-install, I chose to boot from eMMC but to have the root filesystem on a 500Gb sata drive. I have now second thoughts about it, since I realized that the OS take less than 8Gb, AND I'd like to add a 5th disk to my raid Halas nand-sata-install doesn't seem to work on an already moved filsystem. lsblk show this for the eMMC and the root partition peyo@helios64:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465,8G 0 disk └─sda1 8:1 0 465,8G 0 part / ... mmcblk2 179:0 0 14,6G 0 disk └─mmcblk2p1 179:1 0 14,4G 0 part /media/mmcboot And /etc/fstab shows this UUID=f2d7d6e7-902c-44dc-bdae-aedeb4495385 /media/mmcboot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 /media/mmcboot/boot /boot none bind 0 0 UUID=0fcd9a2c-9a46-4a5e-a0f5-e407bd34e8fb / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 ... And in /media I have this peyo@helios64:~$ ll /media/ total 8 drwxr-xr-x 3 root root 4096 déc. 6 11:31 mmcboot drwxr-xr-x 2 root root 4096 déc. 6 11:31 mmcroot Would it be so simple as 1 - rsync all that's on my present / (except for the NFS export and /tmp)? 2 - changin /etc/fstab to this UUID=f2d7d6e7-902c-44dc-bdae-aedeb4495385 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 3 - reboot (with crossed fingers) Thanks for you help