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

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

    Einmal editiert, zuletzt von Frepke ()

  • look at the files in /var/log


    use mc for this if working via ssh


    you can also view the log files via the web gui but this is more time consuming IMO

    Thanks DHGE,


    I'll look into the log-files tonight. Is there something specific to look at, or is this too early to say?

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

  • 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)

  • 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?

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

  • 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).

  • 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

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

  • 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.

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

  • Well, then if you want RPi-Monitor you need to follow the manual installation instructions you'll find on the net.

    RPi-Monitor is running, now we wait :)
    Armbianmonitor is also working again.

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

  • Now my system wasn't accessible, couldn't ping also.


    RPi-Monitor was installed, what now ;(

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

    Einmal editiert, zuletzt von Frepke ()

  • 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.

  • 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

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

    Einmal editiert, zuletzt von Frepke ()

  • 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)

  • 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

    HP t630 Thin Cliënt (AMD Embedded G-Series GX-420GI | QuadCore | 8GB)
    7.0.4-2 (Sandworm) | 64 bit | pve-kernel-6.5 | omvextrasorg 7.0

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!