btw. The Helios4 hardware (excluding the hard drives) is still available.

Related Links: 1 2 3 4

I tried to compile a version of u-boot for sata trying to integrate the changes present in https://solidrun.atlassian.net/wiki/spaces/developer/pages/287212134/A38X+U-Boot in the U-boot build instruction and sources for Helios4 present in the Kobol Wiki but my skills are not sufficient for such a job.

In the binaries available for Helios4 at  https://imola.armbian.com/beta/pool/main/l/linux-u-boot-helios4-current/ there are only u-boots for uart, flash and mmc. 

Would it be possible to have the sata version in future releases?

Thanks in advance and for all the work done.

After upgrading helios4 I encountered this problem after rebooting:

U-Boot SPL 2019.04-armbian (Jul 03 2024 - 12:20:37 +0000)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  6   |  SATA0	|
 |   1    |  5   |  USB3 HOST0	|
 |   2    |  6   |  SATA1	|
 |   3    |  6   |  SATA3	|
 |   4    |  6   |  SATA2	|
 |   5    |  5   |  USB3 HOST1	|
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-18.09.2 
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR Training Sequence - Start scrubbing
DDR3 Training Sequence - End scrubbing
mv_ddr: completed successfully
Trying to boot from MMC1


U-Boot 2019.04-armbian (Jul 03 2024 - 12:20:37 +0000)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **
Model: Helios4
Board: Helios4
SCSI:  MVEBU SATA INIT
Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 

Net:   
Warning: ethernet@70000 (eth1) using random MAC address - e2:6d:a3:83:7f:e1
eth1: ethernet@70000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2996 bytes read in 381 ms (6.8 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
158 bytes read in 369 ms (0 Bytes/s)
28834 bytes read in 691 ms (40 KiB/s)
11165487 bytes read in 2303 ms (4.6 MiB/s)
8551104 bytes read in 1847 ms (4.4 MiB/s)
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...
starting USB...
USB0:   MVEBU XHCI INIT controller @ 0xf10f4000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   MVEBU XHCI INIT controller @ 0xf10fc000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: device type unknown
... is now current device

I guess the most important part is this:

Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...

This happened when linux-image was upgraded from 24.11.0-trunk.403 to 25.2.0-trunk.316 (25.2.0-trunk.343 doesn't work either). To get it working again I unpacked previous kernel and I'm back to 24.11.0-trunk.403. I noticed that this topic

has similar problem. I still got some ideas about how to debug this but I before that I wanted to ask if anyone has encountered this on this board? Did the initrd changed format during upgrade and I have to upgrade uboot (I noticed that FORCE_UBOOT_UPDATE is set to null so I guess installing linux-u-boot-helios4-current_25.2.0-trunk.316_armhf.deb doesn't dd bootloader onto sdcard.

Thanks in advance!

Happy to send it (I am based in Germany) to whoever wants it as long as you cover the cost. Please send me a direct message if interested, thanks!

Anybody can help me?.

I thought it might be the power supply, but I can't find where I could buy it. Does anyone know where to find it?

Thank you very much.

I have tried to Upgrade my Helios 4 nas but was unsuccessful. 

I tried several times with bookworm and OMV7  but every time I do an update of bookworm it breaks everything and the nas does not boot anymore. 

Is there a way to download again a bullseye image for helios 4 ?

I couldn't find any by myself and wod appreciate a link. 

Thank you

but it suddenly lost all SATA HDD. OMV shown the 2 HDD are missing.

i reboot it and during the boot i saw couple of error, failure... so  decided to reinstall armbian by a new SD card.

but tried 2 new cards with new images..

i got same error ... as attached log file.

it seems during booting the kernel, not sure it is u-boot or kernel report it cannot find the root file system.

i am not sure it is the SD card issue or it it the Helios4 board issue or any other issue.

could anyone help?

bootlog.txt

Trying to figure out what is not working I try to run the related service

systemctl start fancontrol.service

but it does not start. So I check the latest errors:

systemctl status fancontrol.service

I obtain

Failed ...fancontrol.service: Failed to locate executable /usr/sbin/fancontrol

so, fancontrol is simply not there and apt can't find it for installation.

I took the old sd card and copied the fancontrol to /usr/sbin/

Than make it executable with:

chmod +x /usr/sbin/fancontrol

than
 

systemctl start fancontrol.service

systemctl enable fancontrol.service

As soon as I started the service, voilà, the fan started to... blowing only when needed: problem solved!

Attached you find the fancontrol file.

fancontrol

There is some information in dmesg: pwm-fan j17-pwm: error -EBUSY: Could not get PWM

I am using Kobol Helios 4 NAS.

Can anyone tell me where the problem is?

When i try to execute

git clone https://github.com/kobol-io/sys-oled.git

cd sys-oled

sudo ./install.sh
I get the following error message via SSH.

Installing luma.oled library error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification. Installing sys-oled files 'etc/sys-oled.conf' -> '/etc/sys-oled.conf' 'bin/sys-oled' -> '/usr/local/bin/sys-oled' 'share/sys-oled/C&C Red Alert [INET].ttf' -> '/usr/local/share/sys-oled/C&C Red Alert [INET].ttf' 'share/sys-oled/helios4_logo.png' -> '/usr/local/share/sys-oled/helios4_logo.png' 'system/sys-oled.service' -> '/etc/systemd/system/sys-oled.service' Enabling sys-oled at startup

Does anyone have an Idea what to do?

warning - the ethernet ports change, breaking scripts where they're hardcoded, e.g the wol service.

changing the port in two places in the file and running

systemctl daemon-reload ; systemctl restart helios4-wol

seems to be running ok. This details the patch:

diff --git a/lib/systemd/system/helios4-wol.service.orig b/lib/systemd/system/helios4-wol.service
index 965eb74..451b857 100644
--- a/lib/systemd/system/helios4-wol.service.orig
+++ b/lib/systemd/system/helios4-wol.service
@@ -1,10 +1,10 @@
[Unit]
-Description=Enable Wake-on-LAN for Helios4 eth0
+Description=Enable Wake-on-LAN for Helios4 end1
After=network-online.target
Wants=network-online.target
[Service]
-ExecStart=/sbin/ethtool -s eth0 wol g
+ExecStart=/sbin/ethtool -s end1 wol g
Type=oneshot
[Install]

I have not been able to get the sys-oled to display however - it is detected ok but only shows gibberish. I tried all models to no avail.

To get the code running, I had to install python3-luma.core and python3-luma.oled.

Any ideas? Thanks 

Running OMV6 on bullseye

I'm a happy user of a Helios4, and have been for several years now. However, at some point it will be challenging to continue to support it, and I'd rather be proactive about maintaining access to my data than scrambling around.

Do people here have recommendations on current hardware that can replace the Helios4? It would need to meet the baseline hardware requirements of the existing hardware. Bonus points if one can re-use the laser-cut case

Thanks!

1. I wanted to have working fancontrol and that required the recent patch of @Heisath - https://github.com/armbian/build/pull/5392
2. I ran into an issue with not being able to install kernel headers (see below) so I needed to build an image with kernel headers built-in

Build steps

I wanted the release version so I did this in a clean build environment (WSL2 Ubuntu):

git clone --depth=1 --branch=v23.05.2 https://github.com/armbian/build

And then manually place this file in your local tree https://github.com/armbian/build/blob/main/patch/kernel/archive/mvebu-6.1/92-mvebu-gpio-remove-hardcoded-timer-assignment.patch.

You need to touch .ignore_changes.

Then run compile.sh INSTALL_HEADERS=yes.

Testing

After booting the image, I only did the following steps:

systemctl disable helios4-wol   # not sure why this service is failing but I do not use this anyway

apt update
apt upgrade
reboot
apt install zfs-dkms
apt install zfsutils-linux 

Kernel header issue

This is after apt update / apt upgrade / reboot. The repo seems to be out of sync. Also armbian-config fails altogether with a grep error (something with maximum count).

root@helios4:~# apt search linux-headers|grep mvebu

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

linux-headers-current-mvebu/bookworm 23.02.2 armhf
  Linux kernel headers for 5.15.93-mvebu on armhf current
linux-headers-edge-mvebu/bookworm 23.02.2 armhf
  Linux kernel headers for 6.1.11-mvebu on armhf edge
root@helios4:~# uname -a
Linux helios4 6.1.36-mvebu #2 SMP Wed Jun 28 11:12:41 CEST 2023 armv7l GNU/Linux
root@helios4:~# cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=helios4
BOARD_NAME="Helios4"
BOARDFAMILY=mvebu
BUILD_REPOSITORY_URL=https://github.com/armbian/build
BUILD_REPOSITORY_COMMIT=961a103
VERSION=23.05.1
LINUXFAMILY=mvebu
ARCH=arm
IMAGE_TYPE=user-built
BOARD_TYPE=conf
INITRD_ARCH=arm
KERNEL_IMAGE_TYPE=zImage
FORCE_BOOTSCRIPT_UPDATE=yes
VENDOR=Armbian
REVISION=23.05.1
BOOTSCRIPT_FORCE_UPDATE="yes"
BOOTSCRIPT_DST="boot.cmd"
root@helios4:~#

If the answer to the thread title is "yes" I need help how to do the upgrade.

If the answer is "no" I kindly ask for information about the reason not to be able to upgrade.

By the way: Helios4 is a maintained platform, maintainer is @Heisath

Question: When can I expect that <mirror>/apt/dists will be refreshed? Or is there any other way to upgrade my installation?

I decided to do some more thorough investigating and found that it was having problems writing to the sdcard. That led to the following entries in syslog:

Dec 20 21:36:43 helios-backup kernel: [318645.034243] mmc0: Timeout waiting for hardware interrupt.
Dec 20 21:36:43 helios-backup kernel: [318645.034254] mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
Dec 20 21:36:43 helios-backup kernel: [318645.034258] mmc0: sdhci: Sys addr:  0x00000008 | Version:  0x00000202
Dec 20 21:36:43 helios-backup kernel: [318645.034263] mmc0: sdhci: Blk size:  0x00007200 | Blk cnt:  0x00000001
Dec 20 21:36:43 helios-backup kernel: [318645.034267] mmc0: sdhci: Argument:  0x0084a0d0 | Trn mode: 0x0000002b
Dec 20 21:36:43 helios-backup kernel: [318645.034271] mmc0: sdhci: Present:   0x01e60006 | Host ctl: 0x00000017
Dec 20 21:36:43 helios-backup kernel: [318645.034274] mmc0: sdhci: Power:     0x0000000f | Blk gap:  0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034278] mmc0: sdhci: Wake-up:   0x00000000 | Clock:    0x00000207
Dec 20 21:36:43 helios-backup kernel: [318645.034282] mmc0: sdhci: Timeout:   0x0000000e | Int stat: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034285] mmc0: sdhci: Int enab:  0x03ff000b | Sig enab: 0x03ff000b
Dec 20 21:36:43 helios-backup kernel: [318645.034289] mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034292] mmc0: sdhci: Caps:      0x25fcc8b2 | Caps_1:   0x00002f77
Dec 20 21:36:43 helios-backup kernel: [318645.034296] mmc0: sdhci: Cmd:       0x0000193a | Max curr: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034299] mmc0: sdhci: Resp[0]:   0x00000900 | Resp[1]:  0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034303] mmc0: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000900
Dec 20 21:36:43 helios-backup kernel: [318645.034306] mmc0: sdhci: Host ctl2: 0x00000000
Dec 20 21:36:43 helios-backup kernel: [318645.034309] mmc0: sdhci: ADMA Err:  0x00000000 | ADMA Ptr: 0x78275208
Dec 20 21:36:43 helios-backup kernel: [318645.034313] mmc0: sdhci: ============================================
Dec 20 21:36:46 helios-backup kernel: [318648.042018] mmc0: Card stuck being busy! __mmc_poll_for_busy
Dec 20 21:36:48 helios-backup kernel: [318649.277911] mmc0: card never left busy state
Dec 20 21:36:48 helios-backup kernel: [318649.277918] mmc0: tried to HW reset card, got error -110
Dec 20 21:36:48 helios-backup kernel: [318649.277923] mmcblk0: recovery failed!
Dec 20 21:36:48 helios-backup kernel: [318649.277947] blk_update_request: I/O error, dev mmcblk0, sector 8691920 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
Dec 20 21:36:48 helios-backup kernel: [318649.277958] EXT4-fs warning (device mmcblk0p1): ext4_end_bio:348: I/O error 10 writing to inode 382819 starting block 1086491)

Is it possible this is due to the power supply starting to go bad? I haven't yet tried using different sdcards, but that would be my next step.

Has anyone else seen this?

After my Helios4 had been laying in a cardboard box for a long time after moving houses, I decided it was time to once again set it up as an NAS.

I was previously running Open Media Vault (OMV) with 4 disks in xfs and using MergerFS for unionizing three of them at a single mount point and then using Snapraid for the fourth disk.

OMV worked pretty well for me but I go somewhat irritated from time to times because how it decides to thing in it's own way.

But now I when I re-installed it (after getting a new PSU) I went with Armbian instead to keep it closer to "standard" linux.

I think I will still go with MerverFS and Snapraid this time also but I also wonder what you guys and gals are using!

For example:

 - What filesystem are you using? xfs, btrfs or maybe zfs?

 - Are you running raid, mergerfs or something else?

 - How are making the storage avalible to other hosts? NFS, SSHFS?

 - Are you running some kind of admin UI to manage your Helios?

This seems to be an issue related to the python script to start the program, any help will be appreciated for those with python programming understanding:

$ sudo systemctl status sys-oled.service
* sys-oled.service - System Starting on OLED Display
   Loaded: loaded (/etc/systemd/system/sys-oled.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Fri 2021-09-17 02:22:42 JST; 10s ago
  Process: 4425 ExecStart=/usr/bin/python3 /usr/local/bin/sys-oled --display ${display_model} (code=exited, status=1/FAILURE)
 Main PID: 4425 (code=exited, status=1/FAILURE)

Sep 17 02:22:42 nas python3[4425]:     main()
Sep 17 02:22:42 nas python3[4425]:   File "/usr/local/bin/sys-oled", line 132, in main
Sep 17 02:22:42 nas python3[4425]:     display_info(device)
Sep 17 02:22:42 nas python3[4425]:   File "/usr/local/bin/sys-oled", line 105, in display_info
Sep 17 02:22:42 nas python3[4425]:     draw.text((0, 0), cpu_usage(), font=font, fill="white")
Sep 17 02:22:42 nas python3[4425]:   File "/usr/local/bin/sys-oled", line 78, in cpu_usage
Sep 17 02:22:42 nas python3[4425]:     temp = psutil.sensors_temperatures()['f10e4078.thermal']
Sep 17 02:22:42 nas python3[4425]: KeyError: 'f10e4078.thermal'
Sep 17 02:22:42 nas systemd[1]: sys-oled.service: Main process exited, code=exited, status=1/FAILURE
Sep 17 02:22:42 nas systemd[1]: sys-oled.service: Failed with result 'exit-code'.

Thank you in advance for any hints or recommendations about how to solve this.

Sincerely,

helios4# uname -r
5.15.86-mvebu
helios4# echo 0 > /dev/fan-j10/pwm1 # works, fan is off
helios4# echo 255 > /dev/fan-j10/pwm1 # works, fan at full speed
helios4# echo 0 > /dev/fan-j17/pwm1 # does nothing, full speed
helios4# echo 255 > /dev/fan-j17/pwm1 # does nothing, full speed

Some digging around I found that 92-mvebu-gpio-remove-hardcoded-timer-assignment.patch has been ported to 5.15, but it doesn't seem to work for me.

Thanks to the team.

One of these few exception is mvebu (ClearFog Base/Pro, ESPRESSObin, Helios 4). I don't understand why. DRBD is a very nice and secure block device which provides network block replication (raid over network), and it is widely used.

DRDB compile and work flawlessly on helios4 with the mvebu kernel. But we are obliged to compile the kernel or only the module, which is somewhat painful.

As I have an helios4 which provides a DRBD node, I first compiles three years ago the module using the current kernel headers,. Then I refrained from updating since I was needing this DRDB node. But now I need to update to buster, so I updated to the current branch.

Of course I lost my DRBD device, and so I compiled a home made kernel.

This is now technically very easy with the new build environment and docker. compile.sh and the associated set of bash scripts are very handy and well conceived. Thank you for the developers who did this work.

But with my servers t has been nevertheless very long and painful. I have only low power servers, and my gateway upper download rate is 300KB. So when I tried the script it could not download anything, I found that it gives to aria2c a lowest speed limit of 500K, so no hope to download something on my network. I tried to change this limit. I tried many value, usually I could down load at 220K, but it seems that the speed can slow down during short period of time,  so my downloads aborted. I had to reduce this minimal speed to 70KB to be able to download the software.

Then I compiled the kernel 14h of compilation on my machine! Next time I will try either to launch a temporary instance on a VPS with better bandwidth, and/or install DISTCC, but I have never tried discc in docker, and I have to learn.

Now running current-mvebu_22.11.0-trunk with kernel 5.15.76, drbd works flawlessly on helios4.

But for next release I strongly wish that it would be incorporated in the distribution. I think it could be useful for people looking fr a server to support a drbd node. But how to request it, posting in the github issues? doing a PR seems quite overkill to just replace 'n' by 'm' in CONFIG_BLK_DEV_DRBD.

Thanks to the team.

I would like to either disable the integrity check altogether, or more ideally, spread it out. I have two RAID-1 arrays, and there is no reason for all four drives to be checked simultaneously. For example, I can check one of the arrays (two HDDs) and then once that is done, the second array (the other two HDDs) after.

Does anyone know where the code/script for the integrity check lives? The closest I found was /etc/cron.daily/mdadm which runs

mdadm --monitor --scan --oneshot

but from the manpage description it is unclear to me whether that is superficial check or that may actually invoke a deep and lengthy integrity check.

after some time on storage i tried to reativate my batch 2 helios4 only to be greeted with a seemingly broken device.
Tried the following:

1. Flashed a new good SD Card with Armbian (golden sundisk one)

2. unplugged all harddisks in my helios 4

3. inserted SD-Card and plugged in in.

Result:

Orange blinking on the Network Port

Green blinking next to the Power slow

USB-TTY does not show up

Tt does not boot

I hear a slight chirping noise synchronous with the green LED. It comes directly from the board not the fans, harddisks or PSU. Sounds like  a fan briefly rubbing against something but it's comming 100% certain from the board.

Is my Helios4 broken? That would be absolutely saddening because theres no ECC Memory Replacement available.

Any Ideas?

phross@helios4:~$ uname -a
Linux helios4 5.15.26-mvebu #trunk.0002 SMP Thu Mar 3 10:15:53 UTC 2022 armv7l GNU/Linux
phross@helios4:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 0.00 ms.
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU
  maximum transition latency: 0.00 ms.

I remember reading discussions about issues with cpufreq patches causing issues on armada-38x socs. Is the cpufreq driver for armada-388 still not working?

I have a Armbian 22.02.1  with Linux 5.10.60-mvebu with buster debian packages.

Its possible to update bullseye a not lost my storage raids?

I know that Kobol is out of Business..

But I am thinking...what if my helios4 motherboard die...?

To mitigate that, I want to acquire new motherboard.

Does any one knows how I could get one?

Thanks in Advance

I got my helios4 sometimes in 2019 and it was one of the best purchases I ever made. It has served and was solid as a rock. Unfortunately all that ended couple of days ago when I noticed the Helios was not powering up properly, think it was the power supply not connected well (because I just recently changed the location) I removed and fitted the PSU a couple of times, I could see the led light come on but still it would not boot properly.

By the time I found out what the real problem is things had gone worse, the reason for the incomplete boot was the SD card has been removed. Unfortunately, it seems my constant removing and refitting the PSU to the board most have done some damage because right now the board has refused to come on.

I used a multi-meter to check the reading from the PSU and it is constantly at 12.5v but the molex for the sata is are all completely 0v. Same for the fan ground and 12v pin for the Fan male header. Curious enough, the control and sense pin out for the FAN reads about 4v. This is pretty much the only thing I was able to get reading from. Rest of the board just seem dead, no LED, no indication whatsoever that PSU is connected to the board.

I am aware that the PSU was one of the weak side of the Helios4, But like I said, the pin out of the PSU reads 12.5v so I am thinking maybe this is an issue with a blown mosfet? I am a total newb when it comes to computer hardware. There are no device out there (arm based and DIY) That comes close to the Helios so I am pretty much stuck. Any advise on how to troubleshoot this would be very much welcome.

I rebooted it from the console and when it came on, no storage was available. I could see some /dev/sd* but one HDD was missing from it and the lvm was not available anymore. Also all the HDDs where clicking and I was hearing a loud buzzing sound from the board.

I rebooted it again, measured the PSU and even load tested it and it is fine, the same for the moled connectors, it was measuring 12V and 5V, but the truth was, the HDDs this time were not even detected.

Took it all apart and booted it without any HDD connected and surprise, it no longer boots. It's missing now the 5V from the molex.

What is the reference for the small IC responsible for creating the 5V for the HDDs? does it has any impact in the board booting? or was the CPU board killed somehow in the process?

I measured the two coils near the CPU module and i see there 5V and 3.3V

I tested all the HDDs in a pc bbefore measuring voltages, and all of them are fine.

Thank you.

.

[ 1242.509097] BTRFS info (device sda): scrub: started on devid 1
[ 1242.560838] BTRFS info (device sda): scrub: started on devid 4
[ 1242.615578] BTRFS info (device sda): scrub: started on devid 3
[ 1242.703587] BTRFS info (device sda): scrub: started on devid 2
[ 3731.573257] ata2.00: exception Emask 0x0 SAct 0xffffffff SErr 0x0 action 0x0
[ 3731.573272] ata2.00: irq_stat 0x40000001
[ 3731.573279] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573283] ata2.00: cmd 60/80:00:00:2f:2b/00:00:03:00:00/40 tag 0 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573300] ata2.00: status: { DRDY ERR }
[ 3731.573306] ata2.00: error: { UNC }
[ 3731.573311] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573315] ata2.00: cmd 60/80:08:00:3b:2b/00:00:03:00:00/40 tag 1 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573331] ata2.00: status: { DRDY ERR }
[ 3731.573336] ata2.00: error: { UNC }
[ 3731.573342] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573346] ata2.00: cmd 60/80:10:00:3d:2b/00:00:03:00:00/40 tag 2 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573361] ata2.00: status: { DRDY ERR }
[ 3731.573365] ata2.00: error: { UNC }
[ 3731.573371] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573375] ata2.00: cmd 60/80:18:00:3f:2b/00:00:03:00:00/40 tag 3 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573390] ata2.00: status: { DRDY ERR }
[ 3731.573395] ata2.00: error: { UNC }
[ 3731.573400] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573404] ata2.00: cmd 60/80:20:00:5f:2b/00:00:03:00:00/40 tag 4 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573419] ata2.00: status: { DRDY ERR }
[ 3731.573423] ata2.00: error: { UNC }
[ 3731.573429] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573433] ata2.00: cmd 60/80:28:00:63:2b/00:00:03:00:00/40 tag 5 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573448] ata2.00: status: { DRDY ERR }
[ 3731.573452] ata2.00: error: { UNC }
[ 3731.573458] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573461] ata2.00: cmd 60/80:30:00:6d:2b/00:00:03:00:00/40 tag 6 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573477] ata2.00: status: { DRDY ERR }
[ 3731.573481] ata2.00: error: { UNC }
[ 3731.573486] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573490] ata2.00: cmd 60/80:38:80:76:27/00:00:02:00:00/40 tag 7 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573505] ata2.00: status: { DRDY ERR }
[ 3731.573510] ata2.00: error: { UNC }
[ 3731.573515] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573519] ata2.00: cmd 60/80:40:80:78:27/00:00:02:00:00/40 tag 8 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573534] ata2.00: status: { DRDY ERR }
[ 3731.573538] ata2.00: error: { UNC }
[ 3731.573543] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573547] ata2.00: cmd 60/80:48:80:7a:27/00:00:02:00:00/40 tag 9 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573562] ata2.00: status: { DRDY ERR }
[ 3731.573567] ata2.00: error: { UNC }
[ 3731.573572] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573576] ata2.00: cmd 60/80:50:80:7c:27/00:00:02:00:00/40 tag 10 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573591] ata2.00: status: { DRDY ERR }
[ 3731.573595] ata2.00: error: { UNC }
[ 3731.573601] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573604] ata2.00: cmd 60/80:58:80:7e:27/00:00:02:00:00/40 tag 11 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573620] ata2.00: status: { DRDY ERR }
[ 3731.573624] ata2.00: error: { UNC }
[ 3731.573629] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573633] ata2.00: cmd 60/80:60:80:80:27/00:00:02:00:00/40 tag 12 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573648] ata2.00: status: { DRDY ERR }
[ 3731.573653] ata2.00: error: { UNC }
[ 3731.573658] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573662] ata2.00: cmd 60/80:68:80:82:27/00:00:02:00:00/40 tag 13 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573678] ata2.00: status: { DRDY ERR }
[ 3731.573682] ata2.00: error: { UNC }
[ 3731.573687] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573691] ata2.00: cmd 60/80:70:80:84:27/00:00:02:00:00/40 tag 14 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573706] ata2.00: status: { DRDY ERR }
[ 3731.573711] ata2.00: error: { UNC }
[ 3731.573716] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573720] ata2.00: cmd 60/80:78:80:86:27/00:00:02:00:00/40 tag 15 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573735] ata2.00: status: { DRDY ERR }
[ 3731.573740] ata2.00: error: { UNC }
[ 3731.573745] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573748] ata2.00: cmd 60/80:80:80:88:27/00:00:02:00:00/40 tag 16 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573764] ata2.00: status: { DRDY ERR }
[ 3731.573768] ata2.00: error: { UNC }
[ 3731.573773] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573777] ata2.00: cmd 60/80:88:80:8a:27/00:00:02:00:00/40 tag 17 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573792] ata2.00: status: { DRDY ERR }
[ 3731.573797] ata2.00: error: { UNC }
[ 3731.573802] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573806] ata2.00: cmd 60/80:90:80:8c:27/00:00:02:00:00/40 tag 18 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573821] ata2.00: status: { DRDY ERR }
[ 3731.573825] ata2.00: error: { UNC }
[ 3731.573830] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573834] ata2.00: cmd 60/80:98:80:8e:27/00:00:02:00:00/40 tag 19 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573849] ata2.00: status: { DRDY ERR }
[ 3731.573854] ata2.00: error: { UNC }
[ 3731.573859] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573863] ata2.00: cmd 60/80:a0:80:90:27/00:00:02:00:00/40 tag 20 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573878] ata2.00: status: { DRDY ERR }
[ 3731.573883] ata2.00: error: { UNC }
[ 3731.573888] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573891] ata2.00: cmd 60/80:a8:80:92:27/00:00:02:00:00/40 tag 21 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573906] ata2.00: status: { DRDY ERR }
[ 3731.573911] ata2.00: error: { UNC }
[ 3731.573916] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573920] ata2.00: cmd 60/80:b0:80:94:27/00:00:02:00:00/40 tag 22 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573935] ata2.00: status: { DRDY ERR }
[ 3731.573939] ata2.00: error: { UNC }
[ 3731.573944] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573948] ata2.00: cmd 60/80:b8:80:96:27/00:00:02:00:00/40 tag 23 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573963] ata2.00: status: { DRDY ERR }
[ 3731.573968] ata2.00: error: { UNC }
[ 3731.573973] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.573977] ata2.00: cmd 60/80:c0:80:9a:27/00:00:02:00:00/40 tag 24 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.573992] ata2.00: status: { DRDY ERR }
[ 3731.573996] ata2.00: error: { UNC }
[ 3731.574001] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.574005] ata2.00: cmd 60/80:c8:80:9c:27/00:00:02:00:00/40 tag 25 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.574020] ata2.00: status: { DRDY ERR }
[ 3731.574025] ata2.00: error: { UNC }
[ 3731.574030] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.574034] ata2.00: cmd 60/80:d0:00:e2:f6/00:00:05:00:00/40 tag 26 ncq dma 65536 in
                        res 41/40:80:30:e2:f6/00:00:05:00:00/40 Emask 0x409 (media error) <F>
[ 3731.574049] ata2.00: status: { DRDY ERR }
[ 3731.574054] ata2.00: error: { UNC }
[ 3731.574059] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.574063] ata2.00: cmd 60/80:d8:80:2a:27/00:00:02:00:00/40 tag 27 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.574078] ata2.00: status: { DRDY ERR }
[ 3731.574082] ata2.00: error: { UNC }
[ 3731.574087] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.574091] ata2.00: cmd 60/80:e0:80:66:27/00:00:02:00:00/40 tag 28 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.574107] ata2.00: status: { DRDY ERR }
[ 3731.574111] ata2.00: error: { UNC }
[ 3731.574116] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.574120] ata2.00: cmd 60/80:e8:80:72:27/00:00:02:00:00/40 tag 29 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.574135] ata2.00: status: { DRDY ERR }
[ 3731.574140] ata2.00: error: { UNC }
[ 3731.574145] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.574149] ata2.00: cmd 60/80:f0:00:21:2b/00:00:03:00:00/40 tag 30 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.574164] ata2.00: status: { DRDY ERR }
[ 3731.574168] ata2.00: error: { UNC }
[ 3731.574173] ata2.00: failed command: READ FPDMA QUEUED
[ 3731.574177] ata2.00: cmd 60/80:f8:80:98:27/00:00:02:00:00/40 tag 31 ncq dma 65536 in
                        res 41/40:d8:30:e2:f6/00:00:05:00:00/40 Emask 0x9 (media error)
[ 3731.574192] ata2.00: status: { DRDY ERR }
[ 3731.574196] ata2.00: error: { UNC }
[ 3731.576554] ata2.00: configured for UDMA/100
[ 3731.576609] sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.576617] sd 1:0:0:0: [sdb] tag#0 Sense Key : 0x3 [current]
[ 3731.576622] sd 1:0:0:0: [sdb] tag#0 ASC=0x11 ASCQ=0x4
[ 3731.576629] sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 03 2b 2f 00 00 00 80 00
[ 3731.576633] blk_update_request: I/O error, dev sdb, sector 53161728 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.576689] sd 1:0:0:0: [sdb] tag#1 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.576696] sd 1:0:0:0: [sdb] tag#1 Sense Key : 0x3 [current]
[ 3731.576701] sd 1:0:0:0: [sdb] tag#1 ASC=0x11 ASCQ=0x4
[ 3731.576707] sd 1:0:0:0: [sdb] tag#1 CDB: opcode=0x28 28 00 03 2b 3b 00 00 00 80 00
[ 3731.576711] blk_update_request: I/O error, dev sdb, sector 53164800 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.576741] sd 1:0:0:0: [sdb] tag#2 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.576747] sd 1:0:0:0: [sdb] tag#2 Sense Key : 0x3 [current]
[ 3731.576752] sd 1:0:0:0: [sdb] tag#2 ASC=0x11 ASCQ=0x4
[ 3731.576758] sd 1:0:0:0: [sdb] tag#2 CDB: opcode=0x28 28 00 03 2b 3d 00 00 00 80 00
[ 3731.576761] blk_update_request: I/O error, dev sdb, sector 53165312 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.576791] sd 1:0:0:0: [sdb] tag#3 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.576797] sd 1:0:0:0: [sdb] tag#3 Sense Key : 0x3 [current]
[ 3731.576803] sd 1:0:0:0: [sdb] tag#3 ASC=0x11 ASCQ=0x4
[ 3731.576808] sd 1:0:0:0: [sdb] tag#3 CDB: opcode=0x28 28 00 03 2b 3f 00 00 00 80 00
[ 3731.576811] blk_update_request: I/O error, dev sdb, sector 53165824 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.576842] sd 1:0:0:0: [sdb] tag#4 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.576849] sd 1:0:0:0: [sdb] tag#4 Sense Key : 0x3 [current]
[ 3731.576854] sd 1:0:0:0: [sdb] tag#4 ASC=0x11 ASCQ=0x4
[ 3731.576860] sd 1:0:0:0: [sdb] tag#4 CDB: opcode=0x28 28 00 03 2b 5f 00 00 00 80 00
[ 3731.576863] blk_update_request: I/O error, dev sdb, sector 53174016 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0
[ 3731.576891] sd 1:0:0:0: [sdb] tag#5 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.576898] sd 1:0:0:0: [sdb] tag#5 Sense Key : 0x3 [current]
[ 3731.576903] sd 1:0:0:0: [sdb] tag#5 ASC=0x11 ASCQ=0x4
[ 3731.576908] sd 1:0:0:0: [sdb] tag#5 CDB: opcode=0x28 28 00 03 2b 63 00 00 00 80 00
[ 3731.576912] blk_update_request: I/O error, dev sdb, sector 53175040 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.576947] sd 1:0:0:0: [sdb] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.576954] sd 1:0:0:0: [sdb] tag#6 Sense Key : 0x3 [current]
[ 3731.576959] sd 1:0:0:0: [sdb] tag#6 ASC=0x11 ASCQ=0x4
[ 3731.576965] sd 1:0:0:0: [sdb] tag#6 CDB: opcode=0x28 28 00 03 2b 6d 00 00 00 80 00
[ 3731.576968] blk_update_request: I/O error, dev sdb, sector 53177600 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.576997] sd 1:0:0:0: [sdb] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.577003] sd 1:0:0:0: [sdb] tag#7 Sense Key : 0x3 [current]
[ 3731.577008] sd 1:0:0:0: [sdb] tag#7 ASC=0x11 ASCQ=0x4
[ 3731.577014] sd 1:0:0:0: [sdb] tag#7 CDB: opcode=0x28 28 00 02 27 76 80 00 00 80 00
[ 3731.577017] blk_update_request: I/O error, dev sdb, sector 36140672 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0
[ 3731.577043] sd 1:0:0:0: [sdb] tag#8 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.577050] sd 1:0:0:0: [sdb] tag#8 Sense Key : 0x3 [current]
[ 3731.577055] sd 1:0:0:0: [sdb] tag#8 ASC=0x11 ASCQ=0x4
[ 3731.577060] sd 1:0:0:0: [sdb] tag#8 CDB: opcode=0x28 28 00 02 27 78 80 00 00 80 00
[ 3731.577064] blk_update_request: I/O error, dev sdb, sector 36141184 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.577086] sd 1:0:0:0: [sdb] tag#9 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=3s
[ 3731.577092] sd 1:0:0:0: [sdb] tag#9 Sense Key : 0x3 [current]
[ 3731.577097] sd 1:0:0:0: [sdb] tag#9 ASC=0x11 ASCQ=0x4
[ 3731.577103] sd 1:0:0:0: [sdb] tag#9 CDB: opcode=0x28 28 00 02 27 7a 80 00 00 80 00
[ 3731.577106] blk_update_request: I/O error, dev sdb, sector 36141696 op 0x0:(READ) flags 0x0 phys_seg 16 prio class 0
[ 3731.577293] ata2: EH complete
[ 5747.007408] BTRFS warning (device sda): checksum error at logical 145793888256 on dev /dev/sdb, physical 49304711168, root 1094, inode 157635, offset 150896640, length 4096, links 1 (path: volumes/quassel-config/_data/quassel-storage.sqlite)
[ 5747.007434] BTRFS error (device sda): bdev /dev/sdb errs: wr 12, rd 83, flush 0, corrupt 7, gen 0
[ 5747.117543] BTRFS error (device sda): unable to fixup (regular) error at logical 145793888256 on dev /dev/sdb
[ 7435.261454] BTRFS info (device sda): scrub: not finished on devid 3 with status: -125
[ 7435.261491] BTRFS info (device sda): scrub: not finished on devid 1 with status: -125
[ 7435.261512] BTRFS info (device sda): scrub: not finished on devid 2 with status: -125
[ 7435.261734] BTRFS info (device sda): scrub: not finished on devid 4 with status: -125

The end is me stopping the scrub. Is this an indication that the power supply needs replacing?

edit: Maybe the hard drive instead...

If go with the original Kobol github version, https://github.com/kobol-io/sys-oled, it fails to build RPI.GPIO and something else.

I also found an alternate at https://github.com/rpardini/sys-oled-hc4, that builds, but when I run it, it complains about a thermal call in python:

# sys-oled --display sh1106
Traceback (most recent call last):
  File "/usr/local/bin/sys-oled", line 142, in <module>
    main()
  File "/usr/local/bin/sys-oled", line 132, in main
    display_info(device)
  File "/usr/local/bin/sys-oled", line 105, in display_info
    draw.text((0, 0), cpu_usage(), font=font, fill="white")
  File "/usr/local/bin/sys-oled", line 78, in cpu_usage
    temp = psutil.sensors_temperatures()['cpu_thermal']
KeyError: 'cpu_thermal'

I opened an issue with the Kobol github, but I don't anticipate much in the way of results there. `rpardini` doesn't appear to be able to accept issues.

Has anyone had any success with getting this running in bullseye?

Unfortunately the speeds don't exceed 45 MB/s. when running RSYNC jobs. On the PC I can completely use the speed of the GBit Port.. When connected to the USB Ports of HELIOS4 the speeds are low.

Can somebody help?

The external enclosure is from UGREEN. HDD is NTFS formatted. Any advice will be gratefully appreciated.

Fortunately the drive that was wiped was a redundancy drive.

Previously I already shared some numbers related to the CESA engine while using @tkaiser sbc-bench tool. I also shared some findings on the openssl support for the kernel modules (cryptodev and af_alg) that interact with the cesa engine. My conclusion was :

1. performance wise : effectively cryptodev performs slightly better than af_alg.

2. openssl / libssl support : very messy and broken, it all depends which version of openssl you use.

Since many Debian Stretch apps depend on "old" libssl (1.0.2), I felt taking the cryptodev approach was the best way since it could expose all encryption and authentication algorithms supported by the cesa engine... even though it requires some patching in openssl. Plus cryptodev implementation in new LTS openssl version 1.1.1 has been completely reworked, so long term it should be the right way.

Anyhow I'm not going to describe here the step by step setup, I'm already writing a page on our wiki for that, once it's ready I will post the link here. Also I won't risk myself talking about the relevance of some of ciphers, it deserves a topic on its own.

I'm just going to share benchmark number on a concrete use case which is HTTPS file download :

So I setup on my Helios4 Apache2 to serve a 1GB file hosted on a SSD drive.

Then I did 3 batch of download tests, for each batch I configured Apache2 to use a specific cipher that I know is supported by the cesa engine.

• AES_128_CBC_SHA
• AES_128_CBC_SHA256
• AES_256_CBC_SHA256

For each batch, I do the following 3 tests :

1. download without cryptodev module loaded (100% software encryption)

2. download with cryptodev loaded and libssl (openssl) compiled with -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS

3. download with cryptodev loaded and libssl (openssl) compile only with -DHAVE_CRYPTODEV, which means hashing operation will still be done 100% by software.

Here are the results :

Note: CPU utilization is for both cores. Obviously each test is just a single process running on a single core therefore when you see CPU utilization around 50% (User% + Sys%) it means the core used for the test is fully loaded. Maybe i should have reported the number just for the core used, which would be more or less doing x2 of the value you see in the table.

For reference:

  Using AES_128_GCM_SHA256 (Default Apache 2.4 TLS cipher. GCM mode is not something that can be accelerated by CESA.)

  CPU Utilization : User %42.9, Sys %7.2
  Throughput : 30.6MB/s

  No HTTPS
  CPU Utilization : User %1.0, Sys %29.8
  Throughput : 112MB/s

CONCLUSION

1. Hashing operation are slower on the CESA engine than the CPU itself, therefore making HW encryption with hashing is less performant than 100% software encryption.

2. HW encryption without hashing provides 30 to 50% of throughput increase while decreasing the load on the CPU by 20 to 30%.

3. Still pondering if it's worth the effort to encourage people to do the move... but i think it's still cool improvement.

I have a little problem with my i2c-screen on the Helios4.

It was setup according to the Kobol-Wiki and was working right from the start. However after running for some time (in this example it took around 6 hours) the screen is black and empty.

Once I SSH back into the helios and restart the systemd sys-oled.service, it works again for some time...

"journalctl -u sys-oled.service" gives the following:

Sep 13 10:18:38 helios4 systemd[1]: Started System Starting on OLED Display.
Sep 13 16:46:01 helios4 python3[23009]: Traceback (most recent call last):
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/bin/sys-oled", line 158, in <module>
Sep 13 16:46:01 helios4 python3[23009]:     main()
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/bin/sys-oled", line 148, in main
Sep 13 16:46:01 helios4 python3[23009]:     display_info(device)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/bin/sys-oled", line 130, in display_info
Sep 13 16:46:01 helios4 python3[23009]:     draw.text((0, 27), network(net_name), font=font, fill="white")
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/core/render.py", line 43, in __exit__
Sep 13 16:46:01 helios4 python3[23009]:     self.device.display(self.image)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 114, in display
Sep 13 16:46:01 helios4 python3[23009]:     self.command(set_page_address, 0x02, 0x10)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/core/device.py", line 48, in command
Sep 13 16:46:01 helios4 python3[23009]:     self._serial_interface.command(*cmd)
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 91, in command
Sep 13 16:46:01 helios4 python3[23009]:     list(cmd))
Sep 13 16:46:01 helios4 python3[23009]:   File "/usr/local/lib/python3.7/dist-packages/smbus2/smbus2.py", line 643, in write_i2c_block_data
Sep 13 16:46:01 helios4 python3[23009]:     ioctl(self.fd, I2C_SMBUS, msg)
Sep 13 16:46:01 helios4 python3[23009]: TimeoutError: [Errno 110] Connection timed out
Sep 13 16:46:01 helios4 systemd[1]: sys-oled.service: Main process exited, code=exited, status=1/FAILURE
Sep 13 16:46:01 helios4 systemd[1]: sys-oled.service: Failed with result 'exit-code'.

Any hint / idea is highly appreciated.

The bus-width being 4 is also quite suspect. All the other Armada 38x devices have it at 8. Armada 37x ones have it at 4.

192.168.0.123:/mnt/md0 /mnt/RAID nfs rw,_netdev,hard,intr,rsize=8192,wsize=8192,timeo=14,user 0 0

That used to work. I made no changes to my Helios4. When I try to mount it manually, this is what I get:

mount -av
mount.nfs: timeout set for Fri Jul 23 07:26:16 2021
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,vers=4.2,addr=192.168.0.123,clientaddr=192.168.0.2'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'hard,intr,rsize=8192,wsize=8192,timeo=14,addr=192.168.0.123'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Unable to receive
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Unable to receive - Connection refused
mount.nfs: Connection timed out

I have no idea why the Helios4 is refusing the connection when it worked fine before. Any help would greatly be appreciated.

My Helios4 stop of working.

It was probably SD CARD because I format an other one with the last Armbian and after it boot again.

Now I config ip address and can connect to it via ssh.

Install webmin and saw that it didn't mount /dev/md0

I did it but filesystem in raid1 is btrfs.

When I mounted it it say :  unknown filesystem type 'LVM2_member'

Someone can help me?

Best regards.

• I flashed my sd cart to upgrade to the last armbian available (I was on armbian 9)
• After some hurdle I finally could had a stable boot and installed OpenMediaVault
• When looking for my RAID 10 data I found that they were gone, replaced by what looks like a linux system, here's its current content :

root@helios4:~# ls /mnt/md0/
aquota.group  boot  export  lost+found  opt   run      srv  usr
aquota.user   dev   home    media       proc  sbin     sys  var
bin           etc   lib     mnt         root  selinux  tmp

I have no idea where those data come from, the only mdadm command I did were the one to import an existing raid, I did not use mkfs or any other command that could alter, format, erase, … my data.

Full story:

Yesterday I wanted to upgrade my helios4 system.

First I upgraded my kernel to the last legacy version avaiable following this post: https://blog.kobol.io/2020/03/13/armbian-new-release/, this completed successully

After that I followed what was at the end of this post: https://blog.kobol.io/2019/08/01/armbian-new-release/, to upgrade from Debian 9 (Stretch) to 10 (Buster), it was quite long  completed it successfully.
Then I had a stupid idea, can I upgrade my kernel from the LEGACY branch to the CURRENT one ? This broke my system boot.

With no easily available way to fix my system I decided to flash my sd card to do a clean install. Before that I did a simple copy (cp) of my card content to one of my computer, so I've all my old conf, for example the one in /etc/, available.
I downloaded the latest os image in https://wiki.kobol.io/download/#latest-os-images, flashed my SD card using balena-etcher, and rebooted my system.
After that I flashed the SD card three more times due to mistakes of mine:

• first after I installed Samba alongside OMV using armbian-config (instead of letting OMV handle it), leading to a boot error.
• second after I used mdadm commands (to import an existing raid) after OMV installation, leading to OMV scripts conflicting with what was saved in my mdadm conf.
  • When using OMV web interface at this step, before crashing it, there was already something that really worried me since my RAID10 drive was reported to only use 1.7Go of the available 5.2To (I had more than 3To of data on it).
• lastly I reflashed in a desparate attempt to see if following the import an existing raid procedure before installing OMV would yield a better result.

That's were I'm now, with my data still replaced by this strange linux instal and OMV still to be installed.

For information here's my ARRAY line on my old mdadm.conf:

ARRAY /dev/md0 metadata=1.2 name=helios4:0 UUID=9320d0fb:d59774c6:f7f2746c:476c3ce9
And the one in my new ():
ARRAY /dev/md/helios4:0 metadata=1.2 name=helios4:0 UUID=9320d0fb:d59774c6:f7f2746c:476c3ce9

If you have any question don't hesitate to ask it :).

Hope you can help.

Helios4.

Try to enter armbian-config → system → cpu

root@helios4:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="21.04 (Hirsute Hippo)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Armbian 21.08.0-trunk Hirsute"
VERSION_ID="21.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=hirsute
UBUNTU_CODENAME=hirsute

HELIOS4 system was running (and doing nothing), when it suddenly crashed.

After restart, nothing automatically loaded (system stuck in emergency mode), once USB cable plugged i managed to log only once into the system, and discovered that no disks where mounted anymore (not even available / detect by the board) (it's not so easy as it seems there are some freezes, maybe due to the hardware errors related to he missing hdd links)

13:00 root@helios4 ~# ll /dev/sd*
zsh: no matches found: /dev/sd*

Is this a failing PSU (like in other threads) ? 

To be noted : the PSU has a blinking green light ... i can't remember if it was like that before ?

In journalctl : 

May 26 12:57:03 helios4 kernel: ata1: SATA link down (SStatus 0 SControl 300)
May 26 12:57:04 helios4 kernel: ata1: SATA link down (SStatus 0 SControl 300)
May 26 12:57:06 helios4 kernel: ata1: COMRESET failed (errno=-32)
May 26 12:57:06 helios4 kernel: ata1: reset failed (errno=-32), retrying in 8 se
May 26 12:57:06 helios4 kernel: ata2: SATA link down (SStatus 0 SControl 300)
May 26 12:57:07 helios4 kernel: ata2: SATA link down (SStatus 0 SControl 300)
May 26 12:57:08 helios4 kernel: ata2: SATA link down (SStatus 0 SControl 300)
May 26 12:57:11 helios4 kernel: ata2: COMRESET failed (errno=-32)
May 26 12:57:11 helios4 kernel: ata2: reset failed (errno=-32), retrying in 8 se
May 26 12:57:12 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:12 helios4 kernel: ata4: COMRESET failed (errno=-32)
May 26 12:57:12 helios4 kernel: ata4: reset failed (errno=-32), retrying in 8 se
May 26 12:57:13 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:14 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:15 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:15 helios4 kernel: ata1: SATA link down (SStatus 0 SControl 300)
May 26 12:57:16 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:16 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:17 helios4 kernel: ata1: SATA link down (SStatus 0 SControl 300)
May 26 12:57:17 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:17 helios4 kernel: ata1: SATA link down (SStatus 0 SControl 300)
May 26 12:57:18 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:19 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)
May 26 12:57:19 helios4 kernel: ata3: SATA link down (SStatus 0 SControl 300)

Full boot log : 

Quote

 

U-Boot SPL 2019.04-armbian (Nov 23 2020 - 16:19:37 +0100)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  6   |  SATA0    |
 |   1    |  5   |  USB3 HOST0    |
 |   2    |  6   |  SATA1    |
 |   3    |  6   |  SATA3    |
 |   4    |  6   |  SATA2    |
 |   5    |  5   |  USB3 HOST1    |
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-18.09.2 
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR Training Sequence - Start scrubbing
DDR3 Training Sequence - End scrubbing
mv_ddr: completed successfully
Trying to boot from MMC1

U-Boot 2019.04-armbian (Nov 23 2020 - 16:19:37 +0100)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **
Model: Helios4
Board: Helios4
SCSI:  MVEBU SATA INIT
Target spinup took 0 ms.
Target spinup took 0 ms.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 
No Link on this port!
Can not start port 1

Net:   
Warning: ethernet@70000 (eth1) using random MAC address - 8a:1e:dc:26:d7:9a
eth1: ethernet@70000
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2996 bytes read in 214 ms (13.7 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
120 bytes read in 182 ms (0 Bytes/s)
27241 bytes read in 627 ms (42 KiB/s)
9448011 bytes read in 1878 ms (4.8 MiB/s)
6607552 bytes read in 1379 ms (4.6 MiB/s)
## Loading init Ramdisk from Legacy Image at 02880000 ...
   Image Name:   uInitrd
   Created:      2021-05-14  13:15:56 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    9447947 Bytes = 9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02040000
   Booting using the fdt blob at 0x2040000
   Loading Ramdisk to 0f6fd000, end 0ffffa0b ... OK
ERROR: reserving fdt memory region failed (addr=2040000 size=6c000)
   Loading Device Tree to 0f68e000, end 0f6fcfff ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Loading, please wait...
Starting version 241
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
/dev/mmcblk0p1: recovering journal
/dev/mmcblk0p1: clean, 75903/1818432 files, 933326/7567200 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

Welcome to Debian GNU/Linux 10 (buster)!

[  OK  ] Started Forward Password R…uests to Wall Directory Watch.
[  OK  ] Created slice User and Session Slice.
[  OK  ] Listening on fsck to fsckd communication Socket.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Listening on udev Control Socket.
[  OK  ] Listening on Syslog Socket.
[  OK  ] Listening on Journal Socket (/dev/log).
[  OK  ] Reached target Slices.
[  OK  ] Set up automount Arbitrary…s File System Automount Point.
[  OK  ] Listening on RPCbind Server Activation Socket.
[  OK  ] Listening on initctl Compatibility Named Pipe.
[  OK  ] Listening on udev Kernel Socket.
[  OK  ] Reached target System Time Synchronized.
[  OK  ] Listening on Journal Socket.
         Mounting RPC Pipe File System...
         Starting udev Coldplug all Devices...
         Starting Load Kernel Modules...
         Starting Set the console keyboard layout...
         Mounting Kernel Debug File System...
         Mounting POSIX Message Queue File System...
         Starting Create list of re…odes for the current kernel...
         Starting Remount Root and Kernel File Systems...
         Starting Nameserver information manager...
[  OK  ] Reached target Swap.
[  OK  ] Created slice system-getty.slice.
[  OK  ] Listening on Journal Audit Socket.
[  OK  ] Reached target Local Encrypted Volumes.
[  OK  ] Reached target Paths.
[  OK  ] Mounted RPC Pipe File System.
[  OK  ] Started Load Kernel Modules.
[  OK  ] Mounted Kernel Debug File System.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Started Create list of req… nodes for the current kernel.
[  OK  ] Started Remount Root and Kernel File Systems.
[  OK  ] Started Set the console keyboard layout.
         Starting Create System Users...
         Starting Load/Save Random Seed...
         Starting Apply Kernel Variables...
         Mounting FUSE Control File System...
[  OK  ] Started udev Coldplug all Devices.
[  OK  ] Started Nameserver information manager.
[  OK  ] Started Create System Users.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Mounted FUSE Control File System.
         Starting Create Static Device Nodes in /dev...
         Starting Helper to synchronize boot up for ifupdown...
[  OK  ] Started Helper to synchronize boot up for ifupdown.
[  OK  ] Started Create Static Device Nodes in /dev.
         Starting udev Kernel Device Manager...
[  OK  ] Reached target Local File Systems (Pre).
         Mounting /tmp...
[  OK  ] Mounted /tmp.
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Found device /dev/ttyS0.
[ TIME ] Timed out waiting for device /dev/md/helios4:0.
[DEPEND] Dependency failed for /mnt/internal/raid.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark… need to relabel after reboot.
         Starting Raise network interfaces...
         Starting Set console font and keymap...
         Starting Preprocess NFS configuration...
         Starting Armbian ZRAM config...
[  OK  ] Stopped Forward Password R…uests to Wall Directory Watch.
[  OK  ] Closed Syslog Socket.
[  OK  ] Reached target Login Prompts.
[  OK  ] Reached target Timers.
[  OK  ] Reached target Sockets.
         Starting Armbian hardware monitoring...
         Starting Armbian hardware optimization...
[  OK  ] Started Emergency Shell.
[  OK  ] Reached target Emergency Mode.
[  OK  ] Started Set console font and keymap.
[  OK  ] Started Preprocess NFS configuration.
[  OK  ] Started Armbian hardware monitoring.
[  OK  ] Started Armbian hardware optimization.
[  OK  ] Reached target NFS client services.
[  OK  ] Started Raise network interfaces.
[  OK  ] Reached target Network.
[  OK  ] Reached target Network is Online.
[  OK  ] Started Armbian ZRAM config.
         Starting Armbian memory supported logging...
[  OK  ] Started Armbian memory supported logging.
         Starting Journal Service...
[  OK  ] Started Journal Service.
         Starting Flush Journal to Persistent Storage...
[  OK  ] Started Flush Journal to Persistent Storage.
         Starting Create Volatile Files and Directories...
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Started Entropy daemon using the HAVEGE algorithm.
         Starting RPC bind portmap service...
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Started Update UTMP about System Boot/Shutdown.
         Starting Update UTMP about System Runlevel Changes...
[  OK  ] Started RPC bind portmap service.
[  OK  ] Reached target Remote File Systems (Pre).
[  OK  ] Reached target Remote File Systems.
[  OK  ] Reached target RPC Port Mapper.
[  OK  ] Started Update UTMP about System Runlevel Changes.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "eGive root password for maintenance
(or press Control-D to continue): 
Reloading system manager configuration
Starting default target

 

I stripped two or three mounting screws for the board. Does anyone know what is the type of these screws and what size are they?

Thanks

I ended up using the clean built and reconfiguring all the services and dockers. I do not recommend using the newer kernel if you are using dockers. This is where I would have random system reboots. OMV4 was very stable but since omv4 was eol. I decided to upgrade or do a clean install. I did both with the same random reboots using the newer kernel 5. Once i switched back to the older kernel with my config, I was not having the random reboot issues. I understand this would be hard to replica because everyone has different configs. I am just trying to help anyone else that would be in this situation.

Thx 

First using my Helios4 after I left her in my storage room.

I have installed and running open media vault. I sometimes wanted to shutdown the NAS. I shutdown using sudo poweroff. Is the a soft method to turn it on again? I currently turn it on using the power switch.

Regards,

Hi all, I am trying to get ZFS up and running on my new Helios4. My apologies if I am overlooking something trivial. My assumption is that I need a different image?

Steps taken:

# apt-get install zfsutils-linux

At the final stage of installation (configuration), the error output is:

The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.
zfs-share.service: Main process exited, code=exited, status=1/FAILURE
zfs-share.service: Failed with result 'exit-code'.

Image details:

Helios4 provided Armbian image Debian 10 - Buster, 02/08/2019

https://cdn.kobol.io/files/Armbian_5.91_Helios4_Debian_buster_next_4.19.63.7z

Using 4 HDDs in my Helios 4 with Openmediavault 5.5. After a update & restart all the HDD's are gone (not shown at all in lsblk anymore). After poking around in the the systemmessages i found this in dmsg, but don't know what to do with it. 

```

[ 1.746837] ahci-mvebu f10a8000.sata: supply ahci not found, using dummy regulator

[ 1.746909] ahci-mvebu f10a8000.sata: supply phy not found, using dummy regulator

[ 1.747062] platform f10a8000.sata:sata-port@0: supply target not found, using dummy regulator

[ 1.747207] platform f10a8000.sata:sata-port@1: supply target not found, using dummy regulator

[ 1.747285] ahci-mvebu f10a8000.sata: masking port_map 0x3 -> 0x3

[ 1.747314] ahci-mvebu f10a8000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl platform mode

[ 1.747321] ahci-mvebu f10a8000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs

[ 1.747935] scsi host0: ahci-mvebu

[ 1.748192] scsi host1: ahci-mvebu

[ 1.748288] ata1: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x100 irq 43

[ 1.748292] ata2: SATA max UDMA/133 mmio [mem 0xf10a8000-0xf10a9fff] port 0x180 irq 43

[ 1.748381] ahci-mvebu f10e0000.sata: supply ahci not found, using dummy regulator

[ 1.748452] ahci-mvebu f10e0000.sata: supply phy not found, using dummy regulator

[ 1.748598] platform f10e0000.sata:sata-port@0: supply target not found, using dummy regulator

[ 1.748734] platform f10e0000.sata:sata-port@1: supply target not found, using dummy regulator

[ 1.748797] ahci-mvebu f10e0000.sata: masking port_map 0x3 -> 0x3

[ 1.748823] ahci-mvebu f10e0000.sata: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl platform mode

[ 1.748830] ahci-mvebu f10e0000.sata: flags: 64bit ncq sntf led only pmp fbs pio slum part sxs

[ 1.749443] scsi host2: ahci-mvebu

[ 1.749647] scsi host3: ahci-mvebu

[ 1.749777] ata3: SATA max UDMA/133 mmio [mem 0xf10e0000-0xf10e1fff] port 0x100 irq 44

[ 1.749780] ata4: SATA max UDMA/133 mmio [mem 0xf10e0000-0xf10e1fff] port 0x180 irq 44

```

and a little later

```
[ 2.063860] ata3: SATA link down (SStatus 0 SControl 300)

[ 2.067856] ata1: SATA link down (SStatus 0 SControl 300)

[ 2.067910] ata4: SATA link down (SStatus 0 SControl 300)

[ 2.067929] ata2: SATA link down (SStatus 0 SControl 300)

```

Any ideas how to proceed?

Pastebin: dmesg
Pastebin: Openmediavault Report

I am thinking about moving the Helios4 into a Inter-Tech SC-4100 case.

The backplane in that case has only one Molex powerconnector.

So is it possible to combine both power connectors on the board (J14 + J19) into one ?

https://wiki.kobol.io/helios4/img/hardware/board_legend.jpg

Thanks

Br,

Joe

https://www.wireguard.com/install/#debian-module-tools

Wireguard server is working correctly as I have other devices working.

I recieve the following output:

root@helios4:/etc/wireguard# wg-quick up PiVPNHelios4
[#] ip link add PiVPNHelios4 type wireguard
[#] wg setconf PiVPNHelios4 /dev/fd/63
[#] ip -4 address add 10.6.0.5/24 dev PiVPNHelios4
[#] ip link set mtu 1420 up dev PiVPNHelios4
[#] resolvconf -a tun.PiVPNHelios4 -m 0 -x
Unknown interface 'tun': No such device
[#] ip link delete dev PiVPNHelios4

Have I setup something wrong with wireguard? or is it not fully supported?

Solution:

remove the DNS value from the configuration

I tried to use again my Helios4, but when we put the power on, only the LED8 light up.

This Helios4 was working great a few month ago (before we receive the Helios64 :-)

So we removed all sata cables (and fan, and power cables for hard drives) to made new tests. But still the same...:-(

And the processor is hot.

So, if someone have a idea to fix it.

Thank you.

Regard.

First, the SSH speed is about 30 MB/s, while the CPU core where sshd runs is at 100% (so I suppose it's the bottleneck).

I create a sparse file and copy it over SSH:

helios4# dd if=/dev/null bs=1M seek=2000 of=/tmp/blank

With scp I get up to 31.2 MB/s:

pc# scp root@helios4:/tmp/blank /tmp

With rsync I get pretty much the same numbers:

pc# rm /tmp/blank
pc# rsync -e ssh --progress root@helios4:/tmp/blank /tmp/
blank
  2,097,152,000 100%   31.06MB/s    0:01:04 (xfr#1, to-chk=0/1)

(I tested both, because with another server, rsync over ssh runs faster - up to 80 MB/s, while scp is still at about 30 MB/s.)

Am I'm planning to use sftp/ssh to access the files, such speed is absolutely unsatisfactory. Is it possible to tune it somehow to be much closer to the line rate of 1 Gbit/s?

The second question is about the best RAID level for this setup. My HDD's read speed is about 250 MB/s, and if I combine 4 of them into a RAID0, the read speed reaches 950 MB/s on another computer, but when I put these disks into the Helios4, the max read speed is about 350 MB/s. Given that the network speed is 125 MB/s, it doesn't seem useful to use any forms of striping, such as RAID0, RAID10 (far), etc., does it? What is the recommended RAID configuration for this system then, given that I have 4 HDDs?

Would RAID10 (near) be better than RAID10 (far)? RAID10 (far) should provide the same read speed as RAID0 for sequential read, however, as on Helios4 the speed is far from 4x (it's just 1.4x), and the network line rate is anyway lower, maybe it makes more sense to optimize for parallel reads. RAID10 (near) will occupy only 2 disks on a single-streamed read (as opposed to 4 with RAID10 (far)), so a second reading stream can use two other disks and improve performance by avoiding seeking to different locations on a single disk. Does this layout make sense, or am I missing something?

I'm also considering RAID6 that has better redundancy than RAID10 at the cost of lower speed and higher CPU usage. While lower speed might not be a problem if it's still higher than the line rate of 1 Gbit/s, CPU may be the bottleneck. As I see from the SSH test above, even such a simple test occupies 100% of one core and some part of the other core, so running RAID6 may increase the CPU demands and cause performance decrease.

One more option is RAID1 over LVM that would combine pairs of disks, but I don't see any apparent advantage over RAID10 (near).

Does anyone have experience running RAID10 (near/far), RAID6 or maybe other configurations with Helios4? What would you advise to build out of 4 HDDs 8 TB each if my goal is to have redundancy and read/write speeds close to the line rate?

If it is available, how can it be activated?

If the usb gadget Ethernet is not default build , which helios4 kernel build options should I modify?

After updating nextcloud to 20.0.5 (now I use 20.0.7) I get the following warning in OMV5 Settings->Overview:

Zitat

MariaDB version "10.1.47-MariaDB-0ubuntu0.18.04.1" is used. Nextcloud 21 will no longer support this version and requires MariaDB 10.2 or higher.

Asking thas question in the OMV-forum I received the following answer from the user "Morlan":

Zitat

This is a complicated issue. Because MariaDB is not officially compiled for arm32 devices the linuxserver image is stuck on 10.1.*. I don't know if that will change. I tried to find an alternative this morning, but I have not found an easy solution .. Maybe someone else has an idea?

A missing MariaDB docker version 10.2ff could be a show-stopper if nextcloud v21 will be available for Helios4.

For quite some time I experienced system freezes. I already measured the voltage on the board 12V and 5V are okay on both connectors.

Attached you will find the armbianmonitor -U output.

I tried to capture kernel logs using information from some other thread.

sudo dmesg -n 7
sudo dmesg -w

But I could not capture anything useful.

Today the system froze while checking the raid (filesystem was not mounted).

[  168.224361] md: data-check of RAID array md0

Is there anything else I can do to shed some light?

Thanks and regards

-kratz00

armbianmonitor.log

Did an apt update/upgrade & reboot today, and the system came back up but none of the drives did.  Imaged a new SD card with stock armbian, and still no luck.

Measured the voltage of the PS (at the plug, not the molex connector) at 12.3v

Anything else I can check/try?

It's been a while, so I have unfortunately forgotten the details of what actually happened.  I didn't expect that set of updates to change anything in the firmware, only the OS and u-boot on the MMC-card.

The board powers on, attempts to boot from the MMC and then bails.

This is the error log: (slightly trimmed)

Quote

 

BootROM - 1.73

Booting from MMC
BootROM: Bad header at offset 00000200
BootROM: Bad header at offset 00004400
BootROM: Bad header at offset 00200000
BootROM: Bad header at offset 00400000
<Snip ~20 lines of sequential Bad Header offset lines>

BootROM: Bad header at offset 02C00000
BootROM: Bad header at offset 02E00000
BootROM: Bad h
Trying Uart

 

 

I've tried several different MMC cards.  I've tried booting from SPI, SATA and UART, all with various forms of failure.

SATA & SPI also give bad header messages.

UART just never seems to do anything - there don't appear to be any functional docs for this recovery method.

What's next?  This board is currently a heavy (and hot) paperweight.

So I am trying to setup my Helios 4. I am running into some issues with the installation, trying to group them here, so it will be easier. 

1. I am trying to setup NextCloud following your tutorial on kobol wiki but I cannot install PHP 7.3 

Here is the screenshot of the output after running the command: 

2. Also, when I enter Armbian-Config, it seems unstable and crash. The menu doesn't display. 

3. Other issue, I cannot access my NAS through SSH. It returns "operation timed out"

How to solve these issues? 

Thank you for your help.

I am opening a new topic to make things clearer. 

This is a follow-up post from here: 

After managing to install it, I moved my Helios 4 and switched it on again. It started to work but then it shut down. I cannot switch it on anymore. I don't know if it comes from the Power supply or the motherboard. 

What are the solutions? 

Thank you for your help. 

Kernel 4.19.63 - works

4.19.84 - I believe works

4.19.104 and above - broken

Newer ones are broken as well. This is most likely an issue with some local patch.

Any way to view the history?

PIN 1: +2.66V (fluctuates between 2.64-2.66)
PIN 2: +2.66V (fluctuates between 2.64-2.66)
PIN 3: GND
PIN 4: GND

What are the voltages that Helios4 expects for these pins?  Should both 1 & 2 be 12V or should one be 12V and the other 5V?

I already ordered the following PSU as per another thread (however, this won't arrive for another week)
https://www.amazon.com/gp/product/B07NCG1P8X/

```

[    0.007976] xor: measuring software checksum speed
[    0.164062] xor: using function: arm4regs (2534.000 MB/sec)
[    0.316068] raid6: neonx8   xor()  1096 MB/s
[    0.452063] raid6: neonx4   xor()  1378 MB/s
[    0.588069] raid6: neonx2   xor()  1610 MB/s
[    0.724066] raid6: neonx1   xor()  1346 MB/s
[    0.860075] raid6: int32x8  xor()   328 MB/s
[    0.996072] raid6: int32x4  xor()   369 MB/s
[    1.132082] raid6: int32x2  xor()   332 MB/s
[    1.268063] raid6: int32x1  xor()   285 MB/s
[    1.268067] raid6: .... xor() 1610 MB/s, rmw enabled
[    1.665163] mv_xor f1060800.xor: Marvell shared XOR driver
[    1.694139] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )
[    1.694257] mv_xor f1060900.xor: Marvell shared XOR driver
[    1.722115] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr )

```

I see that /proc/interrupts shows no action despite me using RAID5.

edit: from looking at kernel source, it seems btrfs uses xor_blocks instead of async_tx. The former seems software only.

This main thread has been locked. Thanks to the Armbian team, we now have our own Kobol club (kinda sub forum) dedicated to our products (Helios64 & Helios4).

So now you are encourage to create individual threads for new issue, discuss feature, share setup, etc...

This will help to improve overall readability.

Note : Before asking a question please insure the information is not already available on Helios4 Wiki or addressed in a previous post in this forum.

Latest Build :

Check : https://dl.armbian.com/helios4/

Archived Build :

Check :  https://archive.armbian.com/helios4/archive/

Known Issues :

• During SATA heavy load, accessing SPI NOR Flash will generate ATA errors. Temporary fix : Disable SPI NOR flash by default.
  • Refer to following page to use SPI NOR Flash : https://wiki.kobol.io/helios4/spi/
• SDcard High Speed timing have compatibility issue with some brands. Temporary fix : Disable UHS option/support by default.
  • Refer to following page to enable UHS mode : https://wiki.kobol.io/helios4/sdcard/

• Software update
• Wiki / Documentation update
• Etc...

I'm having a hard time clarifying if OMV 5 is stable on Helios 4 and if there are any successful builds out there.

Since there doesn't seem to be an upgrade path from OMV4 -> OMV5 and so requiring a full rebuild, I want to understand as much as possible before actually trying this new version out.

Any successes out there?

I bought an helios4 (and run helios4 4.19.63-mvebu) to replace a bananapi server under armbian, the bananapi was running a DRBD node, so I need this service. I first tried to install it, and have seen that DRBD was not configured in the kernel linux-image-next-mvebu 5.91. and the module was missing I checked in the git repository that linux-mvebu64-next.config has now this configuration option, and thought that I will get a new kernel by switching to nightly build. As this option is offered by armbian-config I toggled it. After some time my Helios4 failed to reboot and was bricked.

I mounted my SD on an other system to try to analyze the situation, nothing appeared in the log neither syslog, message, or apt/history.log. So I checked the script armbian-config. jobs.sh only switch the source.list from apt.armbian.com  to beta.armbian.com then call reload_bsp which remove linux-image-next-mvebu, linux-dtb-next-mvebu, linux-buster-root-next-helios4, armbian-config. Then it try to reinstall them, but for helios4  linux-image-next-mvebu, linux-dtb-next-mvebu, and linux-buster-root-next-helios4 are not in beta.armbian.com, so nothing get reinstalled and the system was broken.

So I checked that the previous packages were missing, except the kernel which was not removed. I downloaded them from stable, re-installed them on the sdcard with `dpkg -x`,  I edited the armbian.list to switch back to apt.armbian.com, and my system came back to life after few hours of work.

I would consider that it is not reasonable to propose to switch to nightly build when they don't exist. The script should first verify that the packages to be uninstalled are present on beta.armbian.com.

And now my question is how to install the development kernel on Helios4, do I need to recompile the kernel, or only the DRBD module, and why daily build are missing for helios4.

Hi all,

I've pre-ordered my helios4 and was so excited to finally receive my new NAS after a few months of waiting. I love this project and want to see this project to grow and maybe inspire others to create similar projects as this one.

That said, I was really disappointed when I finally started my board and realized that the UART to micro usb was broken when I plugged it in my computer. No USB device is at all recognized(on linux nor on my mac). At first, to eliminate any potential problems, I tried at least 6 different micro usb to usb cables thinking that a cable could be broken... it happens some time. With all 6 cables tried, never did I get my computer to detect a USB device plugged in.

To continue my great adventure, I soldered a 3 pin header on the UART ports of the board since I have a UART to USB cable at home. Once the pins were soldered on the board, with great excitement I booted the puppy to see if it fixed my issue. It fixed only half the issue. I now detect the USB device andI can now see all tx leaving the arm board however the rx seems to be broken. I get to the login page but can't type anything. Well that sucks. I was hoping the issue was between the UART and micro USB controller but I was wrong. Maybe the issue was with the rx all along and the UART to USB controller just don't work when either rx or tx is not working(this is just a guess). The issue is now more uphill than I thought and I won't be able to troubleshoot this on my own since I am no electronic engineer.

So now, I have a brand new board but with only tx working but not rx so basically I am at a loss here.

This looks like a manufacturing issue. Am I the only one who has this problem? This is part of batch 3 helio4.

Please let me know if you ever went through something similar or if you have an idea how I can fix this.

Any help would be appreciated and if others from the same batch has this issue, it would be great to report it rather to leave it at a loss.

Thanks

1. Question: How do I check that ECC is really active?

2. Possible Kernel issue: The Debian Buster image's Kernel seems to lack CPU frequency info settings: "cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory". How can that be fixed?

3. Possible assembly issue: I think the air flow through the case should be reversed.

Testing scenario: two units about 0,5 m apart in the same location. One unit assembled as shown in the Wiki, the second one assembled with reverse fan direction. First unit equipped with WD40EFRX-68N32N0 (3 platters), second one with the older WD40EFRX-68WT0N0 (4 platters). Because of that, the second unit was expected to run slightly warmer.

First test after 12 hs idling, second test 30 mins. after a reboot. As you can see, the unit with the reversed air flow always stays cooler even with lower fan speeds.

In idle, there is a whopping 5.72°C difference in SoC temperature and a 2.56°C difference in ambient temperature. Fans speed in second unit reduced by nearly 36%. Disk temperatures are all pretty similar.

After reboot, there is a still a 3.80°C difference between the SoCs and a 1.94°C difference in ambient temperature. Fans speed difference is nearly 29%. Disks in the second unit run warmer, but are now within their optimal temperature range between 30°C and 40°C. (Beyond that, failure rates rise steeply even if WD40EFRX are rated for up to 60°C.)

Of course, behaviour under load remains to be seen. I cannot test that at this early stage. But even with measurement inaccuracies taken into account I still think the fans should be mounted the other way round. That would require either longer screws, silicone anti-vibration mounts or you would have to do with the fans mounted on the other side of the plate with the ribbon cables threaded through one of the holes, as I have done for this test.

Thoughts/comments?

12 hs idling:

Unit #1:                     Unit #2:
Fan J10 RPM:    68           Fan J10 RPM:    44
Fan J17 RPM:    74           Fan J17 RPM:    47

SoC core temp.: 49,408.      SoC core temp.: 43,695
Ambient  temp.: 34,687.      Ambient  temp.: 32,125

/dev/sda temp.: 23           /dev/sda temp.: 23
/dev/sdb temp.: 23           /dev/sdb temp.: 23
/dev/sdc temp.: 22           /dev/sdc temp.: 23
/dev/sdd temp.: 22           /dev/sdd temp.: 25

/dev/sda state: standby      /dev/sda state: standby
/dev/sdb state: standby      /dev/sdb state: standby
/dev/sdc state: standby      /dev/sdc state: standby
/dev/sdd state: standby      /dev/sdd state: standby


30 mins. after reboot:

Unit #1:                     Unit #2:
Fan J10 RPM:    76           Fan J10 RPM:    52
Fan J17 RPM:    74           Fan J17 RPM:    55

SoC core temp.: 49,408.      SoC core temp.: 45,600
Ambient  temp.: 35,312.      Ambient  temp.: 33,375

/dev/sda temp.: 26           /dev/sda temp.: 29
/dev/sdb temp.: 26           /dev/sdb temp.: 30
/dev/sdc temp.: 26           /dev/sdc temp.: 31
/dev/sdd temp.: 26           /dev/sdd temp.: 30

/dev/sda state: active/idle  /dev/sda state: active/idle
/dev/sdb state: active/idle  /dev/sdb state: active/idle
/dev/sdc state: active/idle  /dev/sdc state: active/idle
/dev/sdd state: active/idle  /dev/sdd state: active/idle

Hi,

I'm new proud user of Helios4 Batch3.  I started to "play" with different options on this board - and after a 24 hours of use - board doesnt start anymore.

Status led blinks but and disk leds blink for short time.

It is not possible to connect via terminal console or network.

I'think that problem (at least logs point that way) with missing or unavail mount point or (one) disk problem.

But nevertheless I think that system itself should still be accessible. Am I wrong? Some disks can fail but not all mount points reside on them.

If I disconnect all disks (physically) then connection(s) is/are possible again.

I'm still completely new to this board and system.

Please advise.

Regards.

After creating a raid 6 array and creating a filesystem on it I decided to switch to a raid 5 instead. So i re-created the array and after that was done mkfs.ext4 fails every time. The error I get is:

Quote

mke2fs 1.44.5 (15-Dec-2018) Creating filesystem with 4395292032 4k blocks and 274706432 inodes Filesystem UUID: 78105eda-697a-4f57-865c-ded74fc6b213 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000, 214990848, 512000000, 550731776, 644972544, 1934917632, 2560000000, 3855122432 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): mkfs.ext4: Attempt to read block from filesystem resulted in short read while trying to create journal

Having to wait for the arrays to be created TWICE now has taken my entire weekend!

The armbianmonitor didn't work with the following output:

root@helios4:/home/user# armbianmonitor -u
System diagnosis information will now be uploaded to no results to fetchPlease post the URL in the forum where you've been asked for.

Can anyone help me determine why this error is happening? It'd be much appreciated!

Last login: Wed Jan  9 22:58:09 2019 from 192.168.1.13

root@helios4:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.4 port 5001 connected with 192.168.1.13 port 36416
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.6 sec  51.2 MBytes  40.7 Mbits/sec

I'm going through the setup process of my Helios4, but am encountering issues with the termina/serial login, which appears to be a character set issue of some type, which I can't figure out. Here is what I have so far:

sudo picocom -b 115200 /dev/tty.usbserial-DJ00JLDH
picocom v3.1

port is        : /dev/tty.usbserial-DJ00JLDH
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
hangup is      : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,
logfile is     : none
initstring     : none
exit_after is  : not set
exit is        : no

Type [C-a] [C-h] to see available commands
Terminal ready

Ubuntu 18.04.1 LTS helios4 ttyS0

helios4 login:
Ubuntu 18.04.1 LTS helios4 ttyS0

helios4 login: r?????p?????????????p?????????????~p?????????????????????~p??????????????????p?????????????p?????????????~p?????????????????????~p?????????????
Ubuntu 18.04.1 LTS helios4 ttyS0

when I try to enter the root login details, the character set is obviously not set correctly, but I am not sure where to begin troubleshooting this, and there is nothing in previous threads or in the Wiki.

Any pointers would be greatly appreciated!

thanks!

_slayer_

I wanted to give a short teaser of an upcoming board I have been developing. The board will be launched through a crowd-funding campaign in couple of weeks.

Codename : Helios-4

I'm sure the heatsink will give you some hint The board has been build around the Marvell Armada 388 SoC / SoM from SolidRun. So part of the design is inspired from the Clearfog dev board. Actually the SolidRun helped me on the PCB layout to make this little guy reality.

Here the main specs :

We are taking order for the 2nd batch of Helios4.

If you are interested visit our shop.

We offer the two following kits for order :

• Helios4 2GB ECC Full Kit
• Helios4 2GB ECC Basic Kit

Thanks for the support ;-)

The Kobol Team