Jump to content

Helios4 Support


gprovost

Recommended Posts

14 hours ago, tuxd3v said:

It needs to be created has a 64bit Filesystem, from the beginning, I think..

If turned ON, in a 32 bits one,

I think it will Damage the FileSystem.. 

 

What you say concern people mounting on a 64bit Kernel a File System created on 32 bit Kernel.

 

This is not the issue we are talking about. Our limitation is that simply you cannot address a File System > 16TB with a 32bit Kernel because of page cache limitation. I'm not aware of possible work around even with other File System than EXT.

 

The only solution is to use a FUSE union file system to merge two or more partitions into one big volume.

MergerFS : https://github.com/trapexit/mergerfs (It's available as a Debian package.)

 

@9a3eedi @fpabernard You guys don't want to give a try to MergerFS ?

 

 

 

Link to comment
Share on other sites

7 hours ago, gprovost said:

 

What you say concern people mounting on a 64bit Kernel a File System created on 32 bit Kernel.

 

This is not the issue we are talking about. Our limitation is that simply you cannot address a File System > 16TB with a 32bit Kernel because of page cache limitation. I'm not aware of possible work around even with other File System than EXT.

 

The only solution is to use a FUSE union file system to merge two or more partitions into one big volume.

MergerFS : https://github.com/trapexit/mergerfs (It's available as a Debian package.)

 

@9a3eedi @fpabernard You guys don't want to give a try to MergerFS ?

 

 

 

Thanks !

 

MergerFS seems to be nice !

 

I am questioning about performance and the algorithm for moving files across filesystems is rather tricky, and does not eliminate totally errors, as they say here.

 

For now I stay with my bind mounts, and manage to copy/remove the few files which fails when moving (which can occur as I use syncovery which tries to move files when possible). Note anyway that rsync does not move files, it copies/deletes.

 

The advantage of MergerFS is that it manages space on the merged FS, but this is not yet a problem for me, the balance between my 2x16To is OK for now.

 

I will reconsider when free space become a problem and needs to be equally shared between both FS.

Link to comment
Share on other sites

Hi @gprovost, in https://wiki.kobol.io/wol/ wiki page (very nice wiki btw !), there is a mention to a "Wake on GPIO", but on the GPIO wiki page (https://wiki.kobol.io/gpio/) I could not find any mention of the PIN allowing to wakeup a suspended system. Is this GPIO exposed on the J12 header (I would like to implement a timer based wakeup).

Thanks, a future "batch 3" user.

 

Update: I just checked the R1 schematics, and it seems that J12 header is unrelated to the Armada GPIO, but maybe wake on timer is already supported by the kernel (Armada 3xx functional spec mentions Wake on Timer support) ?

Edited by MarcC
Link to comment
Share on other sites

@MarcC Yes Helios4 supports Wake on Timer. It's true that it's a feature we forgot to advertise in our wiki, will need to had a page on the Real Time Clock and Wake on Time features.

 

You can use rtcwake command to put your system in suspend mode until a specified wakeup time. Example :

sudo rtcwake -m mem -s 30

Put system in suspend-to-ram mode and will wake up after 30 sec

 

sudo rtcwake -m mem --date '2019-03-25 08:27'

Put system in suspend-to-ram mode and will wake up on March 25 2019 at 08:27

 

For more information man rtcwake and man hwclock are your friends.

 

 

On your early question regarding "Wake on GPIO" : To implement WoL we used "Wake on GPIO" feature. The Ethernet PHY interrupt pin is connected to SoC GPIO (MPP18) that is configured as a wakeup-source. When you enable WoL on the PHY, the PHY will trigger the MPP18 on reception of magic packets, which in turn will wake up the system. Any GPIO can be configured as wakeup-source.

As you figured, the GPIO header J12 on the board is not direct SoC GPIO, but provided through an I2C IO expander. However this IO expander, like the Ethernet PHY, has also an interrupt pin connected to a SoC GPIO (MPP23), any event on header J12 will trigger MPP23. MPP23 could be also configured as wakeup-souce. Actually IO expander pins could be also configured as wakeup source, it would set the upstream interrupt as wakeup capable automatically.

Edited by gprovost
Link to comment
Share on other sites

On 9/18/2018 at 7:20 PM, gprovost said:

@nemo19 Sorry to hear that now you are facing some other instability with the board. Please next time it occurs, can you send me your syslog files along the link generated by armbianmonitor -u

 

 

Hi,

My second Helios4 box also randomly hangs/stalls at unexpected times. It does not seem load-dependent, as today it stalled while the system was not doing anything (all load intensive tasks are running overnight).

 

The Helios4 boxen are both connected to a Raspberry Pi2b via USB/serial console to check if anything odd had happened, but unfortunately, the serial console of the stalled box always shows nothing but the login prompt. No oops, no "bug on" or any other "error" message.

 

Symptoms:

  • The heartbeat LED stops blinking.
  • NIC LEDs are still show activity.
  • Fans remain on constant speed, not regulated anymore.
  • Serial console is unresponsive.
  • /var/log/* and /var/log.hdd/* shows nothing out of the ordinary - the logging just stops at some point. Most likely armbian-ramlog prevents the interesting bits from being flushed to /var/log.hdd/...

 

I will now watch (a customized) sensors + armbianmonitor -m the serial console. Also, disable armbian-ramlog for now.

 

Do you have any idea what else I can redirect to serial console periodically to check if anything out of the ordinary is happening?

 

Groetjes,

Link to comment
Share on other sites

@djurny Yeah normally kernel message should be output to serial. Well let us know if you catch anything with your monitoring setup.

BTW which HDD models are using ? Do you have USB devices connected ? I'm wondering if it could a power rail issue.

Link to comment
Share on other sites

6 hours ago, gprovost said:

@djurny Yeah normally kernel message should be output to serial. Well let us know if you catch anything with your monitoring setup.

BTW which HDD models are using ? Do you have USB devices connected ? I'm wondering if it could a power rail issue.

Hi,

Box #0 (4x WD Red 4TB):

  • /dev/sda  30  WDC  WD40EFRX-68N32N0  WD-WCC7K1KS6EUY
  • /dev/sdb  32  WDC  WD40EFRX-68N32N0  WD-WCC7K2KCR8J9
  • /dev/sdc  31  WDC  WD40EFRX-68N32N0  WD-WCC7K1RVY70H
  • /dev/sdd  31  WDC  WD40EFRX-68N32N0  WD-WCC7K6FE2Y7D
     

Box #1 (4x WD Blue 2TB):

  • /dev/sda  32  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M2VFJPP7
  • /dev/sdb  31  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M0JNZ8EX
  • /dev/sdc  31  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M6HPXZFZ
  • /dev/sdd  29  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M6HPX4AP

No other devices connected to either box. The 2nd colum is HDD reported temperature in Celcius, it's always around 30~35. 
 

Spoiler

 

I've sligthly modified fancontrol to link the top fan (-j10) to maintain the average HDD temperature around between 30~45 Celcius. Bottom fan (-j17) is linked to CPU temperature (/dev/thermal-cpu/temp1_input).

 

 

Groetjes,

Link to comment
Share on other sites

On 4/1/2019 at 9:04 PM, djurny said:

Hi,

Box #0 (4x WD Red 4TB):

  • /dev/sda  30  WDC  WD40EFRX-68N32N0  WD-WCC7K1KS6EUY
  • /dev/sdb  32  WDC  WD40EFRX-68N32N0  WD-WCC7K2KCR8J9
  • /dev/sdc  31  WDC  WD40EFRX-68N32N0  WD-WCC7K1RVY70H
  • /dev/sdd  31  WDC  WD40EFRX-68N32N0  WD-WCC7K6FE2Y7D
     

Box #1 (4x WD Blue 2TB):

  • /dev/sda  32  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M2VFJPP7
  • /dev/sdb  31  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M0JNZ8EX
  • /dev/sdc  31  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M6HPXZFZ
  • /dev/sdd  29  WDC  WD20EZRZ-00Z5HB0  WD-WCC4M6HPX4AP

No other devices connected to either box. The 2nd colum is HDD reported temperature in Celcius, it's always around 30~35. 
 

  Hide contents

 

I've sligthly modified fancontrol to link the top fan (-j10) to maintain the average HDD temperature around between 30~45 Celcius. Bottom fan (-j17) is linked to CPU temperature (/dev/thermal-cpu/temp1_input).

 

 

Groetjes,

Hi,

 

could you append  extraargs=no_console_suspend ignore_loglevel to /boot/armbianEnv.txt and set loglevel to 8?


echo "extraargs=no_console_suspend ignore_loglevel" | sudo tee -a /boot/armbianEnv.txt
sudo sed -i 's/exit 0/dmesg -n 8\nexit 0/g' /etc/rc.local

then reboot the system to apply the changes.

Those command would disable log filtering and print some debug info when the system entering suspend mode.

 

Edited by aprayoga
dmesg command has to be executed every boot
Link to comment
Share on other sites

Bad news... It took almost over a week, but: My 2nd box froze today, last output on the serial console:

17:41:22:  800MHz  0.19  10%   2%   0%   1%   5%   0% 67.0°C  0/0
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
17:41:28: 1600MHz  0.17  14%   6%   0%   4%   3%   1% 67.5°C  0/0
17:41:33:  800MHz  0.16   6%   2%   0%   1%   1%   0% 67.0°C  0/0
17:41:38: 1600MHz  0.31  15%   6%   0%   3%   2%   1% 67.5°C  0/0
17:41:43: 1600MHz  0.36   7%   2%   0%   1%   2%   1% 68.0°C  0/0
17:41:48: 1600MHz  0.33  15%   6%   0%   5%   1%   0% 67.5°C  0/0
17:41:53: 1600MHz  0.31   6%   2%   0%   1%   1%   0% 68.5°C  0/0

Same symptoms, NIC is blinking,  heartbeat LED is off, serial console is unresponsive.

 

Any thoughts?

 

Groetjes,

Link to comment
Share on other sites

Well I don't know what happened but a few days ago I started getting SMART warnings from one of my drives.  Then the next day seek errors on all 4 drives.  They are older so i figured nothing out of the ordinary.  I ordered new drives to start replacing these.  Last night the entire system died.  And what's weird is it took the external USB drives I had plugged in down as well.  They were on, but they were just clicking their heads.

 

I plugged the externals into my own PC and they turned out to be OK, for some reason they aren't getting enough power from the USB of the helios4.  Well I went and disconnected the NAS drives and on a hunch i plugged the external back in, and put the helios to power without any NAS in it and the external drive worked again and was detected!

 

So I figured some malfunction in the 3.5" drives must have caused other issues like the externals not working.  I tried a different 3.5" drive I had laying around.  Was never detected.  Tried another brand new drive, still not detected.

I plugged a 2.5" drive in just to see what would happen and it was detected fine!

I plugged one of the brand new WD reds i just bought and still nothing.  I don't even think it's even spinning up.  I tried all 4 power connectors, and even reseated the cables into the board to make sure they were secure...

I don't think they're getting any or enough power :\

Link to comment
Share on other sites

@djurny We not sure what it could be. BTW is it a system from batch1 or batch2 ? We are asking because if it's batch2 and as you said the fan still spin after system has hanged, then it means PWM it is running, so the system is not completely hang. In order to narrow down the issue, could you swap the PSUs between your 2 Helios4 systems, to see if it could be a faulty PSU ? In any case, if we can't figure out the root cause, then we will proceed to a replacement of the board.

 

@seawolfssn Sounds like power budget issue, the overall peripherals current consumption exceed the max power budget of Helios4. I'm a bit lost at some point in your explanation, what combination you tried with which HDD and in which order. Maybe a table would help that also show the exact HDD brand + model you are testing.

 

Please note there are 2 power rails for the SATA HDDs, the 5V and the 12V. While the 12V rail is directly coming from the AC/DC PSU, the 5V rail is generated by a buck converter (step-down converter). This buck converter has several protection (over current, over voltage, temperature, etc..) that will switch off the buck converter if something wrong and latch it in this state until a full power cycle. So if by plugging in and out devices you triggered the buck converter protection, plugging/swapping devices might not work because the buck is latching in off state... you need to do a full power cycle (unplug / plug PSU).

The same things apply for USB devices, there is a dedicated 5V rails for the USB ports with the same kind of protection and behavior described above.

 

Link to comment
Share on other sites

8 hours ago, gprovost said:

@djurny We not sure what it could be. BTW is it a system from batch1 or batch2 ? We are asking because if it's batch2 and as you said the fan still spin after system has hanged, then it means PWM it is running, so the system is not completely hang. In order to narrow down the issue, could you swap the PSUs between your 2 Helios4 systems, to see if it could be a faulty PSU ? In any case, if we can't figure out the root cause, then we will proceed to a replacement of the board.

Hi,

They are both from batch #2. I will check try and swap the PSU with the other box over the weekend and indeed see if it still happens.

Thanks,

Groetjes,

Link to comment
Share on other sites

Hi, I seem to have a problem with my batch 2 Helios4 that I'm unable to figure out why it happens.
every time I put it in standby mode, it does not stay in standby but restarts after approx. a minute.

 

I've tested it with 2 different SD-cards, one with a clean install.
During the standby I also tested it with disconnecting the network cable, so it seems the it's an internal trigger or crash
which makes the Helios4 restart.

 

I'm using the latest Armbian version: 5.77 and kernel 4.14.106.

 

One thing I've noticed is that the system time is always incorrect after the forced restart.
after a normal restart the time is correct. Could it be related? I don't know, I'm out of ideas
and it's driving me crazy for the last few days. Hope you guys can help.

Link to comment
Share on other sites

@gprovost   To be clear, once i disconnected the external USB drives and plugged them into my PC and saw them power up and run just fine i decided to power down the whole helios4 and disassemble it to get ready for new drives.

  Then i just tried to plug one 2 of the 3.5" SATA drives in to see what would happen when i put power back on and nothing spun up.  Then i tried a single drive alone, once in each of the 4 power connectors after powering down and up each time.  no spinning up.  Then I tried a brand new WD Blue drive, and then a brand new WD Red drive and nothing powered up on any single attempt.

 

If i took a random 2.5" drive and plugged it in to the SATA connections, then it worked no problem. and was detected by the OS.  So that's what led me to think that there's a problem getting enough power supplied to the 3.5" drives now and from that it can't power USB drives with anything connected either, hence the total system went down and stays down.

 

Each time just to be clear, i completely powered down the device and then powered up with a different slot or drive connected and only the 2.5 connected by SATA worked

Link to comment
Share on other sites

11 hours ago, uzair said:

Hi, I seem to have a problem with my batch 2 Helios4 that I'm unable to figure out why it happens.
every time I put it in standby mode, it does not stay in standby but restarts after approx. a minute.

 

I've tested it with 2 different SD-cards, one with a clean install.
During the standby I also tested it with disconnecting the network cable, so it seems the it's an internal trigger or crash
which makes the Helios4 restart.

 

I'm using the latest Armbian version: 5.77 and kernel 4.14.106.

 

One thing I've noticed is that the system time is always incorrect after the forced restart.
after a normal restart the time is correct. Could it be related? I don't know, I'm out of ideas
and it's driving me crazy for the last few days. Hope you guys can help.

 

Could you do the following and connect the serial console

On 4/2/2019 at 2:13 AM, aprayoga said:

Hi,

 

could you append  extraargs=no_console_suspend ignore_loglevel to /boot/armbianEnv.txt and set loglevel to 8?


echo "extraargs=no_console_suspend ignore_loglevel" | sudo tee -a /boot/armbianEnv.txt
sudo sed -i 's/exit 0/dmesg -n 8\nexit 0/g' /etc/rc.local

then reboot the system to apply the changes.

Those command would disable log filtering and print some debug info when the system entering suspend mode.

 

 

We need more info what event causing the system to wake up.

and how did you put the system to standby?

Link to comment
Share on other sites

@djurny Ok thanks, keep us updated.

 

@uzair Even though it's most probably unrelated to the standby issue on which Aditya will help you.

What's the hardware time and the system time before you put your system in standby ? Do the following command :

 

System time

$> date

 

Hardware Clock time (RTC)

$> hwclock -r

 

@seawolfssn Ok understood, well it looks like your PSU is faulty unable to provide 12V while still providing enough voltage for the different buck converters (5V and 3.3V rails) to operate. Please PM me and will arrange to send you a new PSU.

 

 

Link to comment
Share on other sites

@gprovost This is what I get:

 

root@helios4:~# date
Tue Apr 23 10:38:43 CEST 2019
root@helios4:~# hwclock -r
2019-04-23 10:38:47.165966+0200

 

@aprayoga

 

5 hours ago, aprayoga said:

We need more info what event causing the system to wake up.

 

That's the whole point. I've been checking logs, uninstalling plugins and stopping services to find out
what event causes the system to reboot but from what I've seen there doesn't seem to be anything
that's logged anywhere that says "Hey I'm causing the reboot", atleast from my perspective.

 

I executed the 2 lines you mentioned and this is what I got from the serial interface:

 

Spoiler

 

root@helios4:~# systemctl suspend
root@helios4:~# [  124.919318] PM: suspend entry (s2idle)
[  124.923143] PM: Syncing filesystems ... done.
[  130.221985] Freezing user space processes ... (elapsed 0.003 seconds) done.
[  130.232542] OOM killer disabled.
[  130.235778] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[  130.246838] sd 3:0:0:0: [sdd] Synchronizing SCSI cache
[  130.247334] sd 2:0:0:0: [sdc] Synchronizing SCSI cache
[  130.252076] sd 1:0:0:0: [sdb] Synchronizing SCSI cache
[  130.257307] sd 2:0:0:0: [sdc] Stopping disk
[  130.262359] sd 3:0:0:0: [sdd] Stopping disk
[  130.266610] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  130.276023] sd 1:0:0:0: [sdb] Stopping disk
[  130.276030] sd 0:0:0:0: [sda] Stopping disk
[  131.106394] mvneta f1070000.ethernet eth0: Link is Down

 

And then the system restarts.

 

U-Boot SPL 2018.11-armbian (Mar 14 2019 - 06:43:44 +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-17.10.4
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

 

 

6 hours ago, aprayoga said:

and how did you put the system to standby?

 

I've used OMV's standby mode, in RTCwake Standby - ACPI state S1 and Suspend-to-RAM - ACPI state S3, 
autoshutdown's suspend and systemctl suspend in the CLI.
All have the same problem.

 

I can send the syslog, boot, daemon and authorization logs if that's helpful.

Link to comment
Share on other sites

@uzair Ahhh we found the issue :P

 

OMV install watchdog service by default. When the system is put in standby / suspend mode the watchdog is not stopped, therefore since nothing will be kicking the watchdog in that state, the watchdog will reset the system after 60sec.


You will need to disable watchdog service.

 

$> sudo systemctl disable watchdog

Note: you will need to reboot after you disable the watchdog in order to ensure the watchdog is stopped.


 

It's quite odd that systemctl doesn't try to stop the watchdog before doing the suspend... and then restart the watchdog when waking-up. But well at the same time some would say it's odd to have a watchdog on a system that is meant to be put in suspend mode. Also it seems there is a hardware limitation on Armada SoC watchdog (orion_wdt) that doesn't allow the watchdog to be stop during runtime for security reason... so will need to investigate more.

Link to comment
Share on other sites

On 4/23/2019 at 11:48 AM, gprovost said:

@djurny Ok thanks, keep us updated.

Hi,

Yesterday evening, the second box froze up again. This time I had the other PSU connected, to rule out any PSU failure.

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU  C.St.
23:40:16: 1600MHz  0.10   5%   2%   0%   0%   2%   0% 67.5째C  0/0
23:40:21: 1600MHz  0.09  15%   6%   0%   3%   3%   1% 68.0째C  0/0
23:40:26: 1600MHz  0.09   7%   2%   0%   0%   1%   1% 67.5째C  0/0
23:40:31:  800MHz  0.16  13%   6%   0%   4%   2%   0% 67.0째C  0/0
23:40:36: 1600MHz  0.23   6%   2%   0%   1%   2%   0% 68.0째C  0/0
23:40:41: 1600MHz  0.21  14%   6%   0%   3%   3%   0% 67.5째C  0/0
23:40:47: 1600MHz  0.19   6%   2%   0%   1%   1%   0% 67.5째C  0/0

Same symptoms.

 

First box is still going strong after the PSU swap:

 11:37:11 up 3 days, 14:18,  8 users,  load average: 1.43, 1.55, 1.60

Groetjes,

Link to comment
Share on other sites

I also wanted to post a little update regarding the issue reported by @uzair which ended up being a conflict between OMV standby mode and watchdog service. It is an issue unrelated to Helios4, however we committed a change to OMV official repo to finally address the issue that was actually impacting any user of any platform.

 

https://github.com/openmediavault/openmediavault/issues/343

Link to comment
Share on other sites

Hi all,

 

I own a CloudShell2 with Odroid XU4Q, however I am unhappy with it, because of constant issues with drives unmounting during high load of the system. Something about power supply when using USB3 via that clunky USB/SATA interface they provide. I was never able to resolve those issues and honestly I'm done fighting with it.

 

So I was looking at Helios4 as something that I may purchase, however before I actually do so I'd like to ask current owners if they ever encountered any deal breaking issues. Since Helios4 has proper SATA intefaces rather than USB3 I assume power supply won't be an issue, however I want to be sure I'm packing myself into another regretable purchase :)

 

I'm gonna be using this with OMV as a home storage for video files which will be played using KODI on a Nvidia ShieldTV via Samba. Most stuff will be 1080p, however I wonder if 4K playback would work on it as well (no transcoding on the fly obviously, but just playback)?

 

Would appreciate your thoughts on anything I should be aware of.

Edited by Buster Dogg
added more details
Link to comment
Share on other sites

Hi @Buster Dogg,

I have an Helios4 from batch 2 with 4 SATA HDD which are all used by a RAID6 array. The RAID6 device is then encrypted using Luks. And the encrypted device is formatted using btrfs. I don't use OMV because it requires a Debian system, and I use ArchLinux on my Helios4. So all services are manually configured, including Samba. I didn't notice any issue to read large files through Samba shares from other devices (including a Raspberry Pi 3B+).  Also no problem of drives unmounting during high load of the system, but I do not have a high system load usually.

Link to comment
Share on other sites

Hi all,
 
I own a CloudShell2 with Odroid XU4Q, however I am unhappy with it, because of constant issues with drives unmounting during high load of the system. Something about power supply when using USB3 via that clunky USB/SATA interface they provide. I was never able to resolve those issues and honestly I'm done fighting with it.
 
So I was looking at Helios4 as something that I may purchase, however before I actually do so I'd like to ask current owners if they ever encountered any deal breaking issues. Since Helios4 has proper SATA intefaces rather than USB3 I assume power supply won't be an issue, however I want to be sure I'm packing myself into another regretable purchase
 
I'm gonna be using this with OMV as a home storage for video files which will be played using KODI on a Nvidia ShieldTV via Samba. Most stuff will be 1080p, however I wonder if 4K playback would work on it as well (no transcoding on the fly obviously, but just playback)?
 
Would appreciate your thoughts on anything I should be aware of.


The Helios will keep up for that just fine. DLNA might be another option to consider over samba


Sent from my iPad using Tapatalk
Link to comment
Share on other sites

I have a batch 1 board, I just recently got to setting it up and I'm facing considerable issues. I've done a debian install with OMV. I followed the wonderful wiki guide carefully however I am unable to access the drive from either my mac or pc. It shows up but when I click on it I get the common error - network path not found. MAC has the same issue - even for the apple file sharing. 

 

I can ping the NAS without issues, just can't map or access the device. 

 

I can also access the backend (helios4.local)

 

I also find the nas stalls. This happens at least one a day so far. Becomes inaccessible from putty or OMV backend.  

 

I'm a bit out of my depths here and spent some time on OMV Forums and tried a few things but nothing worked. 

 

Would greatly appreciate support for the small community! 

Link to comment
Share on other sites

53 minutes ago, helios4noob said:

 

I can ping the NAS without issues, just can't map or access the device. 


Have you created the filesystem, share, and the added the share to a service (SMB or NFS) and then enabled the service?  (it's kind of a long chain)

 

54 minutes ago, helios4noob said:

I also find the nas stalls. This happens at least one a day so far. Becomes inaccessible from putty or OMV backend.  


can you run

armbian-monitor -u 

and share the link?

Link to comment
Share on other sites

Hey guys, the kobol's team redirected me here.

I'm interested in the helios4, as a replacement for odroid H2, for a glusterfs infrastructure.

Since the helios4 is ECC that would be a way more resilient solution.

But since it only have a dual core i'm puzzled about the performance.

I've seen some reddit comment talking about 30MBps with erasure coding involved.

 

Do any of you guys tried to make a gluster cluster with helios4?

Link to comment
Share on other sites

Yes I followed the wiki quite closely and created a logical volume, and file system and then an SMB share folder. 

 

I tried to run it and i got the following message 

 

Could not find the database of available applications, run update-command-not-fo     und as root to fix this
armbian-monitor: command not found

Annotation 2019-06-13 205032.png

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines