MellowLizard Posted December 11, 2019 Posted December 11, 2019 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?
gprovost Posted December 12, 2019 Author Posted December 12, 2019 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) ?
gprovost Posted December 12, 2019 Author Posted December 12, 2019 @MellowLizard I didn't pay attention that you provided the key ID, that's effectively ours which means you download an image that we built ourselves on our wiki. Please find attached our PGP PUB key that was used to sign the image. kobol-pgp-pub.key
smith69085 Posted December 20, 2019 Posted December 20, 2019 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
NickS Posted December 20, 2019 Posted December 20, 2019 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/+/ /')
sirleon Posted December 22, 2019 Posted December 22, 2019 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)
Koen Posted December 29, 2019 Posted December 29, 2019 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.
aprayoga Posted December 29, 2019 Posted December 29, 2019 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. 2
sirleon Posted December 29, 2019 Posted December 29, 2019 @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...
sirleon Posted December 30, 2019 Posted December 30, 2019 @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.
aprayoga Posted December 30, 2019 Posted December 30, 2019 (edited) 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. 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 December 30, 2019 by aprayoga added ssh from ubuntu test 1
Igor Posted December 30, 2019 Posted December 30, 2019 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. 1
sirleon Posted December 30, 2019 Posted December 30, 2019 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 1
jimandroidpc Posted December 30, 2019 Posted December 30, 2019 I originally posted this on the OMV forums but got no replies as I figured it was more likely related the their software. AnywayI 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 openmii openmediavault 4.1.30-1 all openmediavault - The open network attached storage solutionii openmediavault-flashmemory 4.2.1 all folder2ram plugin for OpenMediaVaultii openmediavault-keyring 1.0 all GnuPG archive keys of the OpenMediaVault archiveii openmediavault-luksencryption 3.0.5 all OpenMediaVault LUKS encryption pluginii openmediavault-lvm2 4.0.7-1 all OpenMediaVault Logical Volume Manager (LVM2) pluginii openmediavault-netatalk 4.0.7-1 all OpenMediaVault netatalk (AppleTalk Protocol Suite) pluginii openmediavault-nut 4.0.13-1 all OpenMediaVault Network UPS Tools (NUT) pluginii openmediavault-omvextrasorg 4.1.16 all OMV-Extras.org Package Repositories for OpenMediaVaultii 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.ThanksSent from my LM-G710 using Tapatalk
jimandroidpc Posted December 30, 2019 Posted December 30, 2019 I originally posted this on the OMV forums but got no replies as I figured it was more likely related the their software. AnywayI 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 openmii openmediavault 4.1.30-1 all openmediavault - The open network attached storage solutionii openmediavault-flashmemory 4.2.1 all folder2ram plugin for OpenMediaVaultii openmediavault-keyring 1.0 all GnuPG archive keys of the OpenMediaVault archiveii openmediavault-luksencryption 3.0.5 all OpenMediaVault LUKS encryption pluginii openmediavault-lvm2 4.0.7-1 all OpenMediaVault Logical Volume Manager (LVM2) pluginii openmediavault-netatalk 4.0.7-1 all OpenMediaVault netatalk (AppleTalk Protocol Suite) pluginii openmediavault-nut 4.0.13-1 all OpenMediaVault Network UPS Tools (NUT) pluginii openmediavault-omvextrasorg 4.1.16 all OMV-Extras.org Package Repositories for OpenMediaVaultii 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.ThanksSent from my LM-G710 using TapatalkFrom my syslogDec 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 140Sent from my LM-G710 using Tapatalk
Koen Posted December 30, 2019 Posted December 30, 2019 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.
Koen Posted December 30, 2019 Posted December 30, 2019 @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.
Koen Posted January 2, 2020 Posted January 2, 2020 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 ?
Werner Posted January 2, 2020 Posted January 2, 2020 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.
Koen Posted January 2, 2020 Posted January 2, 2020 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 ?
Werner Posted January 3, 2020 Posted January 3, 2020 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
Koen Posted January 3, 2020 Posted January 3, 2020 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).
helios4noob Posted January 5, 2020 Posted January 5, 2020 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
gprovost Posted January 6, 2020 Author Posted January 6, 2020 5 hours ago, helios4noob said: Is this normal? Or do i have a problem Yes it's normal. As indicated on our wiki : 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
GMR Posted January 7, 2020 Posted January 7, 2020 @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?
gprovost Posted January 8, 2020 Author Posted January 8, 2020 @GMR I replied to your email you sent me. This is definitively a dying PSU. Better you stop trying to use it. Let's carry on by email for the after sale support. ;-)
Mangix Posted January 10, 2020 Posted January 10, 2020 My kernel right now is 4.19.63-mvebu. Is this the latest version? It doesn't sound like it is.
Heisath Posted January 10, 2020 Posted January 10, 2020 Yes it is the latest (current) version. Work is still underway for kernel 5.4.y... (You can build an image yourself if you want to try it)
aprayoga Posted January 10, 2020 Posted January 10, 2020 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 Select System > Other, to switch to other kernel Confirm the action And after some process, you will be presented by list of kernels 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 1
Vodalex Posted January 12, 2020 Posted January 12, 2020 (edited) 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 January 12, 2020 by Vodalex
Recommended Posts