Losing network connection over time, reboot is the only fix every time

1st Official Post

    OMV 6.5.0-3 (Shaitan) is running on a BananaPi Armbian 23.02.2 Bullseye with Linux 5.15.93-sunxi and it freezes (lost network connection) after a certain period (sometimes some minutes, sometimes hours). It's not possible to connect by web, ssh, telnet and all services are down. The only way to reanimate it is through the hardware reboot.

    It has never had this issue with OMV 4.x version and it started when i move to 4 to 5.

    The issue remain also with the OMV 6.x


    I read a lot but I didn't find a solution.

    The OS free space is around 700MiB

    IP is static

    Let me know if you need more info


    Thanks

    Filippo

    • Official Post
    Quote from filo.m

    The OS free space is around 700MiB

    That is not a lot.

    Quote from filo.m

    It has never had this issue with OMV 4.x version and it started when i move to 4 to 5.

    The issue remain also with the OMV 6.x

    Maybe a hardware problem?

    Thanks for the reply

    The free space is 28 GiB... my mistake, I copied and paste the memory free space!


    I have been thinking of an hw issue... but why disappear after reboot?


    Thanks

    Filippo

    I analyzed them more than one time the syslog and the last lines before the "freezing" are always the same

    Check the missing lines between Jul 30 15:58:03 and Aug 2 22:05:57 when I rebooted
    I

    Thanks
    Filippo

    Code
    ...
Aug 20 23:24:28 bananapi chronyd[1160]: chronyd exiting
Aug 20 23:24:28 bananapi systemd[1]: Stopped Daily rotation of log files.
Aug 20 23:24:28 bananapi avahi-daemon[1069]: Got SIGTERM, quitting.
Aug 20 23:24:28 bananapi systemd[1]: phpsessionclean.timer: Succeeded.
Aug 20 23:24:28 bananapi avahi-daemon[1069]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::6:3ff:fe02:d21c.
Aug 20 23:24:28 bananapi systemd[1]: Stopped Clean PHP session files every 30 mins.
Aug 20 23:24:28 bananapi avahi-daemon[1069]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.178.Aug 20 23:24:28 bananapi systemd[1]: systemd-tmpfiles-clean.timer: Succeeded.Aug 20 23:24:28 bananapi avahi-daemon[1069]: avahi-daemon 0.8 exiting.Aug 20 23:24:28 bananapi systemd[1]: Stopped Daily Cleanup of Temporary Directories.Aug 20 23:24:28 bananapi systemd[1]: Stopped target System Time Synchronized.Sep 21 09:42:19 bananapi blkmapd[312]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directorySep 21 09:42:19 bananapi systemd-modules-load[306]: Failed to find module 'softdog'Sep 21 09:42:19 bananapi fake-hwclock[280]: Current system time: 2023-09-21 07:42:08Sep 21 09:42:19 bananapi fake-hwclock[280]: fake-hwclock saved clock information is in the past: 2023-09-21 07:17:01Sep 21 09:42:19 bananapi fake-hwclock[280]: To set system time to this saved clock anyway, use "force"Sep 21 09:42:19 bananapi systemd[1]: Starting Flush Journal to Persistent Storage...Sep 21 09:42:19 bananapi systemd[1]: Finished Flush Journal to Persistent Storage.Sep 21 09:42:19 bananapi systemd[1]: Finished Create Static Device Nodes in /dev.Sep 21 09:42:19 bananapi systemd[1]: Starting Rule-based Manager for Device Events and Files...Sep 21 09:42:19 bananapi systemd[1]: Finished Set the console keyboard layout.
...

    I'm still facing the same problem....

    The Syslog file is strange as it jumps from 20 Aug to 21 Sep despite being on the whole interval.

    How can i detect a hardware issue as suggested by macom?


    I cutted part of the log file in the "code". Attacched the complete file

    syslog(3).txt


    I notice now that Trasmission in working but i can reach OMV, Plex, Portainer and so on..


    thanks
    Filippo

    This is an update regarding the issue.

    After a fresh installation of omv7, everything is working properly.

    The issue was likely a software problem, not a hardware one


    Thanks for your support

    Filippo

    • Official Post
    Quote from filo.m

    How can i detect a hardware issue as suggested by macom?

    Unfortunately, you can't. Logs, more or less, are the only indicator.

    While there are some Stress Test distro's for X86 platforms, that are designed to induce CPU overheating, cycle through memory, etc., there's very little for ARM platforms. The fault, itself, is "the indicator". If you think about it; asking software to detect faults on the hardware it's running on, borders on unrealistic.

    If you think there's a chance it's heat related, you could try putting a fan on the Banana Pi and it's power supply as a test. Other than that:

    Things you could do in order of cost:

    1. A clean rebuild from scratch. (Make sure to test the downloaded image against it's SHA hash and test the SD-card before burning it.)
    If you haven't used it before, here's a detailed -> install process to follow. (There's a process for OMV6 on the same site.)
    2. Try another SD-card
    3. Try another power supply.

    4. A new Banana Pi (This might be the time to try another SBC, if you chose.)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login