Helios4 Support


gprovost

Recommended Posts

Unable to find the GPG public key to verify Armbian_5.91_Helios4_Debian_buster_next_4.19.63.img - Signature made using RSA key ID 3ABD3FCD. Tried searching several key servers and the forum.

 

The key ID 9F0E78D5 listed on https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-authenticity can be found and is able to verify Armbian_5.91_Helios4_Debian_stretch_default_4.14.135.img

 

Has the new public key not been published or maybe I didn't search the correct server?

Link to post
Share on other sites
Donate and support the project!

3 hours ago, MellowLizard said:

Unable to find the GPG public key to verify Armbian_5.91_Helios4_Debian_buster_next_4.19.63.img - Signature made using RSA key ID 3ABD3FCD. Tried searching several key servers and the forum.

 

From where did you downloaded the image ? From armbian repo or from our wiki (wiki.kobol.io) ?

Link to post
Share on other sites
On 2/17/2018 at 6:39 AM, gprovost said:

@NickS I just created this patch for fancontrol that fixes 2 issues :

- fix 'too many arguments' error messages

- set pwm to minimum speed when fancontrol exit

https://github.com/helios-4/build/blob/helios4/packages/bsp/helios4/fancontrol.patch

 

@Last_phil Good that you managed to setup Plex server. You pinpoint one the reason I never liked Plex, the need to still transcode stuff while the player device can natively support the codec. Many people asked the question about Plex on Helios4, I said clearly it will run but don't expect it to have the guts to transcode everything.

 

@tbendiksen Good suggestion, you can rise a Pull Request directly on Armbian official repo as Igor suggested you. 

 

Has anyone got a copy of the fan control patch, the above link is returning 404 and my fans go to max when shutdown the Helios4

Link to post
Share on other sites

The following patch makes fans revert to slow on shutdown rather than top speed!
================================================================================


--- /usr/sbin/fancontrol    2018-02-17 13:54:50.065478090 +0800
+++ /usr/sbin/fancontrol    2018-02-17 13:58:56.910831481 +0800
@@ -334,7 +334,7 @@
     # No enable file? Just set to max
     if [ ! -f $ENABLE ]
     then
-        echo $MAX > $1
+        echo $MINPWM > $1
         return 0
     fi
 
@@ -433,9 +433,9 @@
         fi
 
         # If fanspeed-sensor output shall be used, do it
+        min_fanval=100000
         if [[ -n ${fan} ]]
         then
-            min_fanval=100000
             fanval=
             # A given PWM output can control several fans
for one_fan in $(echo $fan | sed -e 's/+/ /')

Link to post
Share on other sites

I tried to move the complete system from the SD-card to an SSD, so i followed the tutorial as described here.

I'm not sure how to do the following steps:

Quote

3) Select option Boot from SPI - system on SATA, USB or NVMe

And follow the on screen instructions.

4) When RootFS migration is done, disable spi_workaround.

5) Set DIP switches SW1 to SPI Boot and reboot the system.

I can't move the target SATA-device because spi_workaround is enabled.

 

What can I do to get rid of the SD-card and booting from SPI / SATA-device?

Should I move the /boot partition from the SD-card to sdb1? Is it necessary to modify /etc/fstab ?

 

(I alread tried moving the rootFS with sata-nand-install while spi_workaround is disabled. The system was booting and mounted from sdb1, but I can't get it to boot without the SD-card)

Link to post
Share on other sites

I'm trying to start afresh on the latest buster image, but failing miserably.

1. Armbian-config setting Locale not working and subsequently giving perl errors.  (Fixed by manually editing /etc/default/locale)
2. Arbmian-config setting Keyboard not doing anything.  (Fixed by manually edditing /etc/default/keyboard)

3. Arbmian-config accessing "system - CPU" crashes armbian-config.

cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: File or folder doesn't exist
cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: File or folder doesn't exist

4. Can't do anything iptables, not even -L to see existing rules, let alone actually configuring anything.

iptables v1.8.2 (nf_tables):  CHAIN_ADD failed (No such file or directory): chain INPUT

Haven't been able to get around the last one.  Tried removing and reinstalling the iptables package, but same result.

Link to post
Share on other sites
On 12/23/2019 at 12:20 AM, sirleon said:

I tried to move the complete system from the SD-card to an SSD, so i followed the tutorial as described here.

I'm not sure how to do the following steps:

I can't move the target SATA-device because spi_workaround is enabled.

 

What can I do to get rid of the SD-card and booting from SPI / SATA-device?

Should I move the /boot partition from the SD-card to sdb1? Is it necessary to modify /etc/fstab ?

 

(I alread tried moving the rootFS with sata-nand-install while spi_workaround is disabled. The system was booting and mounted from sdb1, but I can't get it to boot without the SD-card)

Hi @sirleon, the tutorial is intended for moving the rootfs to USB thumb drive and due to spi_workaround it does not work with SATA seamlessly but you almost there..

I suggest to move the rootfs to drive that connected to SATA0 (most likely /dev/sda), because there is known issue that u-boot failed to recognized SATA device other than on SATA0.

 

To boot from SATA you need to:
1. Move the rootfs with sata-nand-install while spi_workaround is disabled, and reboot.
    The system will boot from SD card.

2.  Unmount /boot and copy over boot files from /media/mmcboot/boot to /boot

umount /boot
cp -rf /media/mmcboot/boot/* /boot/

3.  Edit /etc/fstab and remove/comment 2 lines that have mount point to /media/mmcboot and /boot.

4.  Reboot the system and cancel u-boot auto boot.

5.  Run following commands on u-boot prompt to add sata boot and reboot

setenv boot_targets "usb0 scsi0 mmc0 pxe dhcp"
setenv bootcmd_scsi0 'devnum=0; run scsi_boot'
saveenv

You could reorder the boot order on boot_targets variable. On above command, it would tried to boot from USB and if failed try SATA/SCSI and so on.

 

Link to post
Share on other sites

@aprayoga Thank you very much! It is working now after I followed your advice in combination with these instructions from David

to solve this Error:

Quote

scanning bus for devices...
  Device 0: (0:0) Vendor: ATA Prod.: C300-CTFDDAC064M Rev: 0007
            Type: Hard Disk
            Capacity: 61057.3 MB = 59.6 GB (125045424 x 512)
  Device 1: (0:1) Vendor: ATA Prod.: C300-CTFDDAC064M Rev: 0007
            Type: Hard Disk
            Capacity: 61057.3 MB = 59.6 GB (125045424 x 512)
Found 2 device(s).

scsi device 0: (0:0) Vendor: ATA Prod.: C300-CTFDDAC064M Rev: 0007
            Type: Hard Disk
            Capacity: 61057.3 MB = 59.6 GB (125045424 x 512)
** Bad device specification scsi -bootable **
Scanning scsi :1...
Found U-Boot script /boot/boot.scr
2976 bytes read in 62 ms (46.9 KiB/s)
## Executing script at 03000000
Boot script loaded from scsi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
No FDT memory address configured. Please configure
the FDT address via "fdt addr <address>" command.
Aborting!
Applying kernel provided DT fixup script (-fixup.scr)
## Executing script at 00300000
Wrong image format for "source" command
Applying user provided fixup script (fixup.scr)
## Executing script at 00300000
Wrong image format for "source" command
SCRIPT FAILED: continuing...

 

 

Link to post
Share on other sites

@Koen

Don´t know if this is the right direction for you but i had a similar problem trying to get docker running. I had to switch back to iptables-legacy like it is descriped here.

 

Also NetworkManager don´t get DNS via DHCP so i had to remove the line "dns = default" in /etc/NetworkManager/NetworkManager.conf to get name resolution to work. 

Link to post
Share on other sites
13 hours ago, sirleon said:

@aprayoga Thank you very much! It is working now after I followed your advice in combination with these instructions from David

to solve this Error:

 

 

Good to hear you got it working.  I tried the instructions first on my system and did not encounter such error. Could you share your u-boot version?

 

 

On 12/29/2019 at 7:57 AM, Koen said:

I'm trying to start afresh on the latest buster image, but failing miserably.

1. Armbian-config setting Locale not working and subsequently giving perl errors.  (Fixed by manually editing /etc/default/locale)
2. Arbmian-config setting Keyboard not doing anything.  (Fixed by manually edditing /etc/default/keyboard)

3. Arbmian-config accessing "system - CPU" crashes armbian-config.


cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: File or folder doesn't exist
cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: File or folder doesn't exist

4. Can't do anything iptables, not even -L to see existing rules, let alone actually configuring anything.


iptables v1.8.2 (nf_tables):  CHAIN_ADD failed (No such file or directory): chain INPUT

Haven't been able to get around the last one.  Tried removing and reinstalling the iptables package, but same result.

I test on fresh Armbian_19.11.3_Helios4_buster_current_4.19.84.img
 

1. I don't encounter such error when accessing the system from Windows using PuTTY or thru serial console

   UPDATE: i tried to SSH from my Ubuntu machine (got id_ID locale), indeed there are perl warning regarding locale but armbian-config is still usable to generate the locale, no need to manually edit file. After the locale generated by armbian-config, no more perl locale warning.


2. Confirmed

3. Confirmed.

cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies: No such file or directory
cat: /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors: No such file or directory


/usr/lib/armbian-config/jobs.sh: line 1075:
Error: Expected at least 5 tokens for --menu, have 4.
Use --help to list options. / 1000: syntax error in expression (error token is ": Expected at least 5 tokens for --menu, have 4.
Use --help to list options. / 1000")

The path is not exist, even though the driver is compiled. I will need to investigate further.

---

I also tried using fresh Armbian 5.91 then upgraded to Armbian 19.11.3, but strangely i don't see the System - CPU menu.

helios4_armbian_config_system-cpu.PNG.8520da8295bfa0cfc8d12c2c71acc05e.PNG

 

4. As mentioned on @sirleon link, apparently Buster make use nftables by default and on our kernel is not enabled. You could try to switch to iptables-legacy version.

CONFIG_NF_TABLES=m
CONFIG_NF_TABLES_SET=m
# CONFIG_NF_TABLES_INET is not set
# CONFIG_NF_TABLES_NETDEV is not set
# CONFIG_NF_TABLES_IPV4 is not set
# CONFIG_NF_TABLES_ARP is not set
# CONFIG_NF_TABLES_IPV6 is not set
# CONFIG_NF_TABLES_BRIDGE is not set

meanwhile, i will try to enable those modules and test.

 

@Igor, could you take a look whether armbian-config issues also occur on other board?

Edited by aprayoga
added ssh from ubuntu test
Link to post
Share on other sites
3 hours ago, aprayoga said:

could you take a look whether armbian-config issues also occur on other board?


Armbian buster with Linux 5.4.6-rockchip:
I could change locales as expected and keyboard and CPU speed as well (on console). No issues here. Everything works as expected. http://ix.io/25TY

 

It is normal that cpu-freq throws errors out ... since we don't have driver in 4.19.y ... well it could be suppressed. But the rest must work.

Link to post
Share on other sites

 

5 hours ago, aprayoga said:

Good to hear you got it working.  I tried the instructions first on my system and did not encounter such error. Could you share your u-boot version?

Spoiler

U-Boot SPL 2019.04-armbian (Aug 02 2019 - 10:25:29 +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 SPI


U-Boot 2019.04-armbian (Aug 02 2019 - 10:25:29 +0000)

SoC:   MV88F6828-B0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from EXT4... Card did not respond to voltage select!
Loading Environment from SPI Flash... SF: Detected w25q32 with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
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:   eth1: ethernet@70000

=> printenv
arch=arm
baudrate=115200
board=helios4
board_name=helios4
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; setenv boot_interface ${de                                                                                                        vtype};source ${scriptaddr}
boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi                                                                                                        ;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bo                                                                                                        otefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
boot_interface=scsi
boot_net_usb_start=usb start
boot_prefixes=/ /boot/
boot_script_dhcp=boot.scr.uimg
boot_scripts=boot.scr.uimg boot.scr
boot_syslinux_conf=extlinux/extlinux.conf
boot_targets=scsi▒0 mmc▒0
bootargs=console=ttyS0,115200 root=/dev/sda1 rootwait rootfstype=ext4 ubootdev=scsi scandelay loglevel=1
bootcmd=run bootcmd_sata
bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv ef                                                                                                        i_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; f                                                                                                        i; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;                                                                                                        setenv bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r                                                                                                        }; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci                                                                                                         ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
bootcmd_mmc0=devnum=0; run mmc_boot
bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
bootcmd_sata=scsi reset; scsi scan; load scsi 0:1 0x2040000 /boot/dtb/armada-388-helios4.dtb; load scsi 0:1 0x2880000 /                                                                                                        boot/uInitrd; load scsi 0:1 0x2080000 /boot/zImage; bootz 0x2080000 0x2880000 0x2040000;
bootcmd_scsi▒0=devnum=0; run scsi_boot
bootcmd_usb0=devnum=0; run usb_boot
bootdelay=3
bootfile=boot.scr.uimg
bootfstype=ext4
bootscsi=scsi reset; ext4load scsi 1:1 $kernel_addr $image_name; ext4load scsi 0:1 $fdt_addr $fdt_name; setenv bootargs                                                                                                         $console root=/dev/sda1 rw; boot $kernel_addr - $fdt_addr
console=ttyS0,115200
cpu=armv7
distro_bootcmd=scsi_need_init=; for target in ${boot_targets}; do run bootcmd_${target}; done
efi_dtb_prefixes=/ /dtb/ /dtb/current/
emmc_fix=off
eth1addr=00:50:43:25:fb:84
eth2addr=00:50:43:84:25:2f
eth3addr=00:50:43:0d:19:18
ethact=ethernet@70000
ethaddr=00:50:43:84:fb:2f
fdt_addr=0x2040000
fdt_addr_r=0x2040000
fdt_high=0xffffffff
fdtcontroladdr=7fb634b8
fdtfile=armada-388-helios4.dtb
fileaddr=3000000
filesize=ba0
initrd_high=0xffffffff
kernel_addr_r=0x2080000
load_addr=0x300000
load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
loadaddr=0x02000000
mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi
pxefile_addr_r=0x3100000
ramdisk_addr_r=0x2880000
rootdev=/dev/mmcblk0p1
rootfstype=ext4
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan                                                                                                        _dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_for_efi;
scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for                                                                                                         distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for                                                                                                        _boot; fi; done; setenv devplist
scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-                                                                                                        ${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes}; do if test -e ${devtype} ${devnum}:${distro_bootpart} $                                                                                                        {prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/boot                                                                                                        arm.efi; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: co                                                                                                        ntinuing...; fi; setenv efi_fdtfile
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Foun                                                                                                        d ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${sc                                                                                                        ript}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x3000000
scsi_boot=run scsi_init; if scsi dev ${devnum}; then devtype=scsi; run scan_dev_for_boot_part; fi
scsi_init=if ${scsi_need_init}; then scsi_need_init=false; scsi scan; fi
scsidevs=2
soc=mvebu
spi_workaround=off
stderr=serial@12000
stdin=serial@12000
stdout=serial@12000
usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi
vendor=kobol
verbosity=1

Environment size: 4935/65532 bytes

 

 

Link to post
Share on other sites

I originally posted this on the OMV forums but got no replies as I figured it was more likely related the their software.

Anyway


I updated my Helios4 w/ OMV4.x overnight and then was getting this message


"Invalid RPC response. Please check the syslog for more information."

Error #0: OMV\Rpc\Exception: Invalid RPC response. Please check the syslog for more information. in /usr/share/php/openmediavault/rpc/rpc.inc:186 Stack trace: #0 /usr/share/php/openmediavault/rpc/proxy/json.inc(97): OMV\Rpc\Rpc::call('LuksMgmt', 'openContainer', Array, Array, 3) #1 /var/www/openmediavault/rpc.php(45): OMV\Rpc\Proxy\Json->handle() #2 {main}



Found a few other threads with simiular but different errors - I ran 


"dpkg -l | grep openm"

The output was...

root@helios4:~# dpkg -l | grep openm
ii  openmediavault                  4.1.30-1                          all          openmediavault - The open network attached storage solution
ii  openmediavault-flashmemory      4.2.1                             all          folder2ram plugin for OpenMediaVault
ii  openmediavault-keyring          1.0                               all          GnuPG archive keys of the OpenMediaVault archive
ii  openmediavault-luksencryption   3.0.5                             all          OpenMediaVault LUKS encryption plugin
ii  openmediavault-lvm2             4.0.7-1                           all          OpenMediaVault Logical Volume Manager (LVM2) plugin
ii  openmediavault-netatalk         4.0.7-1                           all          OpenMediaVault netatalk (AppleTalk Protocol Suite) plugin
ii  openmediavault-nut              4.0.13-1                          all          OpenMediaVault Network UPS Tools (NUT) plugin
ii  openmediavault-omvextrasorg     4.1.16                            all          OMV-Extras.org Package Repositories for OpenMediaVault

ii  openmediavault-rsnapshot        4.2.1                             all          OpenMediaVault rsnapshot backup plugin.




Any ideas on how to handle this? Ive had a few issues with updates running periodically on omv on my helios4 and dont to have to redo OMV again if there is a simple fix. As of right now I cant mount any of my drives.

Thanks

Sent from my LM-G710 using Tapatalk

Link to post
Share on other sites
I originally posted this on the OMV forums but got no replies as I figured it was more likely related the their software.

Anyway


I updated my Helios4 w/ OMV4.x overnight and then was getting this message


"Invalid RPC response. Please check the syslog for more information."

Error #0: OMV\Rpc\Exception: Invalid RPC response. Please check the syslog for more information. in /usr/share/php/openmediavault/rpc/rpc.inc:186 Stack trace: #0 /usr/share/php/openmediavault/rpc/proxy/json.inc(97): OMV\Rpc\Rpc::call('LuksMgmt', 'openContainer', Array, Array, 3) #1 /var/www/openmediavault/rpc.php(45): OMV\Rpc\Proxy\Json->handle() #2 {main}



Found a few other threads with simiular but different errors - I ran 


"dpkg -l | grep openm"

The output was...

root@helios4:~# dpkg -l | grep openm
ii  openmediavault                  4.1.30-1                          all          openmediavault - The open network attached storage solution
ii  openmediavault-flashmemory      4.2.1                             all          folder2ram plugin for OpenMediaVault
ii  openmediavault-keyring          1.0                               all          GnuPG archive keys of the OpenMediaVault archive
ii  openmediavault-luksencryption   3.0.5                             all          OpenMediaVault LUKS encryption plugin
ii  openmediavault-lvm2             4.0.7-1                           all          OpenMediaVault Logical Volume Manager (LVM2) plugin
ii  openmediavault-netatalk         4.0.7-1                           all          OpenMediaVault netatalk (AppleTalk Protocol Suite) plugin
ii  openmediavault-nut              4.0.13-1                          all          OpenMediaVault Network UPS Tools (NUT) plugin
ii  openmediavault-omvextrasorg     4.1.16                            all          OMV-Extras.org Package Repositories for OpenMediaVault

ii  openmediavault-rsnapshot        4.2.1                             all          OpenMediaVault rsnapshot backup plugin.




Any ideas on how to handle this? Ive had a few issues with updates running periodically on omv on my helios4 and dont to have to redo OMV again if there is a simple fix. As of right now I cant mount any of my drives.

Thanks

Sent from my LM-G710 using Tapatalk


From my syslog

Dec 30 11:34:22 localhost omv-engined[22219]: PHP Fatal error: Uncaught TypeError: Argument 2 passed to array_keys_exists() must be of the type array, null given, called in /usr/share/php/openmediavault/system/filesystem/backend/manager.inc on line 284 and defined in /usr/share/php/openmediavault/functions.inc:140#012Stack trace:#012#0 /usr/share/php/openmediavault/system/filesystem/backend/manager.inc(284): array_keys_exists(Array, NULL)#012#1 /usr/share/php/openmediavault/system/filesystem/backend/manager.inc(130): OMV\System\Filesystem\Backend\Manager->enumerate()#012#2 /usr/share/php/openmediavault/system/filesystem/filesystem.inc(855): OMV\System\Filesystem\Backend\Manager->getBackendById('/dev/mapper/sda...')#012#3 /usr/share/openmediavault/engined/rpc/fstab.inc(178): OMV\System\Filesystem\Filesystem::getImpl('/dev/mapper/sda...')#012#4 [internal function]: OMVRpcServiceFsTab->getByFsName(Array, Array)#012#5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)#012#6 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod in /usr/share/php/openmediavault/functions.inc on line 140

Sent from my LM-G710 using Tapatalk

Link to post
Share on other sites
20 hours ago, sirleon said:

@Koen

Don´t know if this is the right direction for you but i had a similar problem trying to get docker running. I had to switch back to iptables-legacy like it is descriped here.

 

Also NetworkManager don´t get DNS via DHCP so i had to remove the line "dns = default" in /etc/NetworkManager/NetworkManager.conf to get name resolution to work. 

Yes, fixed with :

update-alternatives --set iptables /usr/sbin/iptables-legacy

apparently also needed if you want to use fail2ban.  So (currently) no need to convert rules and blabla.  I'm also wondering if nftables will stick around longer than the firewalld from before, nothing as annoying than learning new firewall speak, especially since security is tantamount.

Link to post
Share on other sites

@aprayoga

Maybe #1 is a result of removing the default en_US and only enabling localised version ?  Whatever i tried, i couldn't get it fixed, so went the manual conf file way and it vanished immediately (even within armbian-config everything then looked fine).

 

#4 yes, iptables-legacy works fine, apparently also required for fail2ban which doesn't (yet) support nftables.

Link to post
Share on other sites

Next i'm trying to get a LUKS encrypted system.   It looks okay.  Ish.

 

If i unlock over SSH via dropbear, logging in to serial console is buggy and terminal laggy.   Sometimes the login prompt line is all in green text rather than white.  First attempt always fails.  I seem to need to hit every key twice too.  I get these errors :

Cannot initialize device-mapper. Is dm_mod kernel module loaded?
Cannot use device sdcard, name is invalid or still in use.

In /etc/crypttab is (which hints at the 2nd line).

sdcard  /dev/mmcblk0p3  none    luks

If i login via SSH first, then the login via serial goes okay, but the first sudo authentication fails and those two lines appear.

 

Anyone know what's happening or how to fix ?

Link to post
Share on other sites
1 hour ago, Werner said:

The cryptoroot feature was added by user contribution and is broken for several month now. Therefore you might be on your own to fix this.

 

It uses standard debian packages ?  I can do (and have done) the same on x64 or raspbian.

 

Or is there some tool to generate custom images that has / had cryptoroot ?

Link to post
Share on other sites
16 hours ago, Werner said:

It was integrated into the build script. You can find more information here:

https://github.com/armbian/build/pull/1182

https://github.com/armbian/build/issues/1584

I don't know this build stuff.  And my issue isn't over ssh but serial console.

 

I worked the old fashioned way: booting a vanilla image, installing cryptsetup & dropbear-initramfs, deal with the first 2k bytes & /boot, making crypto partition, rsync'ing the system, configure initramfs & generate a new one, edit armbianEnv & generate new boot.cmd.  On ssh it automatically runs the "unlock" command and all i need to do is enter the password (over serial or SSH).

 

It's basically a minor nuisance, over serial console only.  But i rather have everything proper, to avoid issues later and in case of network unavailable.  It's a weird fluke, that seems related to authentication (whether that's login or sudo elevation).

Link to post
Share on other sites

After a long while I finally set this guy up!

 

Is it typical to get the RED Led (2) to blink when you are setting up a raid array. I'm creating a raid 6 array in OMV and when I create the raid the Led2 starts blinking. I canceled, wiped my drives, rebooted. Everything was fine until I tried to setup a raid array. Then the same issue happened. 

 

Is this normal? Or do i have a problem

Link to post
Share on other sites
5 hours ago, helios4noob said:

Is this normal? Or do i have a problem

 

Yes it's normal. As indicated on our wiki :

 

image.png.fd846680d96092fa1a7f5dd53ad8bc8d.png

 

I know red LED means error, but since it was difficult to distinguish between a the first sync during setup and a sync that is due to some error, we made it generic. Can find the script here which trigger the led.

 

https://github.com/armbian/build/blob/master/packages/bsp/helios4/mdadm-fault-led.sh

 

Link to post
Share on other sites

@gprovost

 

Hi, I'm having trouble with my Helios4, it doesn't turn on when I connect the power cable. The green led on the power supply brick blinks. The green led on the board next to the power input (LED8 ?) blinks too. The fans look like they're attempting to spin up but never do.

 

I measured voltages, based on other posts in this thread. Both pairs of +/- pins on the power supply cable show about 1.45V each. I also measured resistor C18 with the power cable plugged in, and got oscillating values that never went above 1V.

 

Help?

Link to post
Share on other sites
5 hours ago, Mangix said:

My kernel right now is 4.19.63-mvebu. Is this the latest version? It doesn't sound like it is.

Between middle-to end of November 2019, Armbian change the version and branch naming.

Version from something like 5.91 become something like 19.11.x, if i'm not mistaken Year.Month, like Ubuntu versioning.

Then the branch name,

  • DEFAULT become LEGACY
  • NEXT become CURRENT

To upgrade to new version, use armbian-config.

sudo apt-get update
sudo apt-get -y upgrade
sudo armbian-config

armbian-config_main.png.07bfc6c651dd386525f75139ab2b1926.png

 

Select System > Other, to switch to other kernel

armbian-config_system.png.81450d3b2716adb516b43436d83e1c6c.png

 

Confirm the action

armbian-config_other_kernel_confirmation.png.d1ff808ec66794597d81271e039bee53.png

 

And after some process, you will be presented by list of kernels

armbian-config_other_kernel_list.png.ed40b0a7e75e15825c42959f325023af.png

 

Select linux-image-current-mvebu. The system will install the new kernel and automatically reboot.

Confirm the kernel installed correctly and Armbian changed to new branch CURRENT by executing,

uname -a
grep "BRANCH" /etc/armbian-release

 

Link to post
Share on other sites

Hello friends! I am a happy owner of Helios4 NAS (3rd batch). I am running OpenMediaVault on it. Can somebody explain to me the way WOL works on it? When I put the system in standby via web interface of the OMV the fans are quiet and spinning very slow.. I can wake up the system without any problem. But if I shutdown the system in the webinteface I cannot wake it up using WOL. And the NAS remains on and the fans are spinning at full volume. It is the expected way as it should work? On my old NAS i could completey shut it down and start using WOL and it was off when i shut it down.  Here is my configuration.

http://ix.io/276n

Would be very thankful if somebody could help.

 

Edited by Vodalex
Link to post
Share on other sites
  • Werner locked this topic
Guest
This topic is now closed to further replies.