OMV not accessible after a few days

    • OMV 4.x

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • OMV not accessible after a few days

      Hello,

      I've OMV-4 (updated to the latest version) running on my Odroid HC1, but since a few weeks my system disappears from my network after a few days. I can no longer reach OMV's GUI and not by SSH.
      Unplug and replug the power-cord is the only option for me.

      Is there a way to find out what causes this problem?

      kr.,
      Frepke

      The post was edited 1 time, last by Frepke ().

    • New

      DHGE wrote:

      look at the files in /var/log

      Useless on OMV installations with enabled flashmemory plugin ;)

      Logs remain in RAM and with an unsafe shutdown everything is lost.

      @Frepke you need to execute /sbin/folder2ram once to get the options then disable folder2ram and check using 'df' prior and after. Then to really get something into the logs which might show a root cause you need to also edit /etc/fstab, remove the commit=600 option and use the sync option (check carefully what you do since every mistake you make here will brick your installation)
    • New

      tkaiser wrote:

      DHGE wrote:

      look at the files in /var/log
      Useless on OMV installations with enabled flashmemory plugin ;)

      Logs remain in RAM and with an unsafe shutdown everything is lost.

      @Frepke you need to execute /sbin/folder2ram once to get the options then disable folder2ram and check using 'df' prior and after. Then to really get something into the logs which might show a root cause you need to also edit /etc/fstab, remove the commit=600 option and use the sync option (check carefully what you do since every mistake you make here will brick your installation)
      Thanks @tkaiser,

      Looks a bit scary,

      I think I understand everything you wrote, except the sync option. Is this also in the fstab?
      In case of bricking my installation, I've to burn a new image on the sd-card and start over again?
    • New

      Frepke wrote:

      I think I understand everything you wrote, except the sync option. Is this also in the fstab?
      Yep, but I forgot that the image you're using relies on btrfs for the rootfs so simply remove the commit=600 entry there and reboot after disabling folder2ram.

      Another possibility is to install RPi-Monitor to get a clue whether there is high load prior to the device becoming unavailable. On the ARM OMV images it's a simple 'armbianmonitor -r' (details).

      But this will permanently write to its RRD databases so when troubleshooting is over I would deinstall RPi-Monitor (same with re-enabling folder2ram and increasing fs commit interval).
    • New

      tkaiser wrote:

      Frepke wrote:

      I think I understand everything you wrote, except the sync option. Is this also in the fstab?
      Yep, but I forgot that the image you're using relies on btrfs for the rootfs so simply remove the commit=600 entry there and reboot after disabling folder2ram.
      Another possibility is to install RPi-Monitor to get a clue whether there is high load prior to the device becoming unavailable. On the ARM OMV images it's a simple 'armbianmonitor -r' (details).

      But this will permanently write to its RRD databases so when troubleshooting is over I would deinstall RPi-Monitor (same with re-enabling folder2ram and increasing fs commit interval).
      Okay, I'll take a look tonight. I hope it gets me to the root cause.


      kr.,
      Frepke
    • New

      Frepke wrote:

      tkaiser wrote:

      Frepke wrote:

      I think I understand everything you wrote, except the sync option. Is this also in the fstab?
      Yep, but I forgot that the image you're using relies on btrfs for the rootfs so simply remove the commit=600 entry there and reboot after disabling folder2ram.Another possibility is to install RPi-Monitor to get a clue whether there is high load prior to the device becoming unavailable. On the ARM OMV images it's a simple 'armbianmonitor -r' (details).

      But this will permanently write to its RRD databases so when troubleshooting is over I would deinstall RPi-Monitor (same with re-enabling folder2ram and increasing fs commit interval).
      Okay, I'll take a look tonight. I hope it gets me to the root cause.

      kr.,
      Frepke
      @tkaiser,

      I've disabled folder2ram en removed the entry "commit=600" in the fstab and rebooted my HC1.
      but armbianmonitor -r doesn't do anything :(

      The folder /etc/armbianmonitor/ only contains a folder: datasources with soctemp in it.
    • New

      Frepke wrote:

      RPi-Monitor was installed
      Well, you could now have a look whether there's high load on the system prior to it not being available any more. RPi-Monitor logs load and temperatures so it should give a clue whether a crash/freeze is related to high activity or to something else.

      But looking into logs especially /var/log/syslog (or providing them via pastebin.com) might be more interesting.
    • New

      tkaiser wrote:

      Frepke wrote:

      RPi-Monitor was installed
      Well, you could now have a look whether there's high load on the system prior to it not being available any more. RPi-Monitor logs load and temperatures so it should give a clue whether a crash/freeze is related to high activity or to something else.
      But looking into logs especially /var/log/syslog (or providing them via pastebin.com) might be more interesting.
      Thanks tkaiser,

      Yesterday, 17:00u. the HC1 was accessible and working normally, 20:00u. it was over.
      I looked in RPi-Monitor but there's nothing strange, no high system load or temps.
      /var/log/syslog only contains entries from today.

      kr.,
      Frepke

      The post was edited 1 time, last by Frepke ().

    • New

      Hmm... no idea. Could be related to undervoltage (PSUs getting older) and without a serial console it's close to impossible to really get a clue what's going on. AFAIK on the XU4 you can not use those cheap $1 USB serial dongles from Aliexpress or eBay but need the official one from Hardkernel (due to different voltage levels -- but I might be wrong so better check Hardkernel's wiki for information)
    • New

      tkaiser wrote:

      Hmm... no idea. Could be related to undervoltage (PSUs getting older) and without a serial console it's close to impossible to really get a clue what's going on. AFAIK on the XU4 you can not use those cheap $1 USB serial dongles from Aliexpress or eBay but need the official one from Hardkernel (due to different voltage levels -- but I might be wrong so better check Hardkernel's wiki for information)
      Okay,

      Thank you for your time/help anyways :)


      I think I do a fresh OMV-4 install on a different SD-card and see what happens.



      kr.,
      Frepke
    • Users Online 4

      4 Guests