Unraid fails during parity check

[Helio667]

Hi All,

 

Over the past few days I've noticed Unraid failing when I get home from work and first thing in the morning. First Docker services start failing then the unraid web server becomes unresponsive and eventually wont respond to pings.

 

Rebooting fixes it for a while but as the parity check at boot continues on during the day, the cycle repeats.

I've attached diagnostics if anyone can help. 

 

Cheers!

helios-diagnostics-20231217-1318.zip

[trurl]

Have you done memtest?

 

Setup syslog server.

[Helio667]

Haven't run memtest since original install over 6 months ago now.

 

It's running a parity check at the moment, so I'll set up a syslog server now and if/when it falls over again I'll run memtest again.
 

[Helio667]

Ok, so I've run memtest86+ and got the all clear. 
 

Attached syslog. time of restart: Dec 19 @ 20:53

syslog-10.10.10.10.log

[Helio667]

last entries before I lost access to the server were to do with the trim function on my cache:

 

Dec 19 20:02:51 HELIOS root: /etc/libvirt: 125.7 MiB (131764224 bytes) trimmed on /dev/loop3
Dec 19 20:02:51 HELIOS root: /var/lib/docker: 1017.2 MiB (1066659840 bytes) trimmed on /dev/loop2
Dec 19 20:02:51 HELIOS root: /mnt/cache: 429.5 GiB (461217300480 bytes) trimmed on /dev/mapper/nvme0n1p1
Dec 19 20:53:38 HELIOS root: Delaying execution of fix common problems scan for 10 minutes

[JorgeB]

Dec 19 08:37:53 HELIOS kernel: macvlan_broadcast+0x10a/0x150 [macvlan]
Dec 19 08:37:53 HELIOS kernel: ? _raw_spin_unlock+0x14/0x29
Dec 19 08:37:53 HELIOS kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]

Macvlan call traces will usually end up crashing the server, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), then reboot.
 

[Helio667]

I needed to switch to macvlan for nginx proxy manager official to work

[itimpi]

1 minute ago, Helio667 said:

I needed to switch to macvlan for nginx proxy manager official to work

In which case as mentioned in the release notes you need to ensure that bridging is disabled on eth0.

 

[Helio667]

9 minutes ago, itimpi said:

In which case as mentioned in the release notes you need to ensure that bridging is disabled on eth0.

 

Sorry not really getting it yet. Maybe this is the issue, when I was configuring the server originally I bonded the 2 x 2.5 g links (br0), then changed to macvlan when NPMO wasn't working. That worked fine for about 2-3 months.

Should I unbind the ports? or...?

[itimpi]

Just now, Helio667 said:

Sorry not really getting it yet. Maybe this is the issue, when I was configuring the server originally I bonded the 2 x 2.5 g links (br0), then changed to macvlan when NPMO wasn't working. That worked fine for about 2-3 months.

Should I unbind the ports? or...?

The release notes say that you need to disable bridging if you do not want Macvlan crashes to eventually crash the server when using Macvlan.   Why if have no idea.

[Helio667]

OK, so since that option is greyed out and unchangeable, I'm assuming that I have to separate the two NICs to disable bridging

[Helio667]

14 minutes ago, itimpi said:

The release notes say that you need to disable bridging if you do not want Macvlan crashes to eventually crash the server when using Macvlan.   Why if have no idea.

 

I was able to disable bridging after turning of VMs while keeping the bonded interface AND still set to macvlan.... 

for anyone else that might end up here, turn off VMs and disable bridging seems to work

 

See how it goes!