Hello All,

I havebeen facing horrible instability of my Unraid system since the last 6 months. I have changed everything from RAM CPU MOTHERBOARD CACHE FLASH etc.

It seems to be running now but my logs show some weird things
Jan 19 18:32:21 Tower kernel: veth44e5217: entered allmulticast mode

Jan 19 18:32:21 Tower kernel: veth44e5217: entered promiscuous mode

Jan 19 18:32:21 Tower kernel: eth0: renamed from veth2e8f577

Jan 19 18:32:21 Tower kernel: br-15893e96a455: port 2(veth44e5217) entered blocking state

Jan 19 18:32:21 Tower kernel: br-15893e96a455: port 2(veth44e5217) entered forwarding state

Jan 19 18:32:45 Tower kernel: br-15893e96a455: port 3(vethbdc4a4b) entered disabled state

Jan 19 18:32:45 Tower kernel: veth09c7797: renamed from eth0

Jan 19 18:32:45 Tower kernel: br-15893e96a455: port 3(vethbdc4a4b) entered disabled state

Jan 19 18:32:45 Tower kernel: vethbdc4a4b (unregistering): left allmulticast mode

Jan 19 18:32:45 Tower kernel: vethbdc4a4b (unregistering): left promiscuous mode

Jan 19 18:32:45 Tower kernel: br-15893e96a455: port 3(vethbdc4a4b) entered disabled state

Jan 19 18:32:45 Tower kernel: br-15893e96a455: port 3(veth0608df3) entered blocking state

Jan 19 18:32:45 Tower kernel: br-15893e96a455: port 3(veth0608df3) entered disabled state

Jan 19 18:32:45 Tower kernel: veth0608df3: entered allmulticast mode

Jan 19 18:32:45 Tower kernel: veth0608df3: entered promiscuous mode

Jan 19 18:32:45 Tower kernel: eth0: renamed from veth0fda395

Jan 19 18:32:45 Tower kernel: br-15893e96a455: port 3(veth0608df3) entered blocking state

Jan 19 18:32:45 Tower kernel: br-15893e96a455: port 3(veth0608df3) entered forwarding state

Jan 19 18:33:00 Tower kernel: br-15893e96a455: port 4(vethee7ac57) entered disabled state

Jan 19 18:33:00 Tower kernel: veth4a18e32: renamed from eth0

Jan 19 18:33:00 Tower kernel: br-15893e96a455: port 4(vethee7ac57) entered disabled state

Jan 19 18:33:00 Tower kernel: vethee7ac57 (unregistering): left allmulticast mode

Jan 19 18:33:00 Tower kernel: vethee7ac57 (unregistering): left promiscuous mode

Jan 19 18:33:00 Tower kernel: br-15893e96a455: port 4(vethee7ac57) entered disabled state

Jan 19 18:33:00 Tower kernel: br-15893e96a455: port 4(veth718f0a8) entered blocking state

Jan 19 18:33:00 Tower kernel: br-15893e96a455: port 4(veth718f0a8) entered disabled state

Jan 19 18:33:00 Tower kernel: veth718f0a8: entered allmulticast mode

Jan 19 18:33:00 Tower kernel: veth718f0a8: entered promiscuous mode

Jan 19 18:33:01 Tower kernel: eth0: renamed from veth7e627c9

Jan 19 18:33:01 Tower kernel: br-15893e96a455: port 4(veth718f0a8) entered blocking state

Jan 19 18:33:01 Tower kernel: br-15893e96a455: port 4(veth718f0a8) entered forwarding state

Jan 19 18:33:11 Tower kernel: i2c i2c-4: sendbytes: NAK bailout.

Jan 19 18:33:34 Tower kernel: i2c i2c-4: sendbytes: NAK bailout.

Jan 19 18:33:34 Tower kernel: br-15893e96a455: port 5(veth2b5ea20) entered disabled state

Jan 19 18:33:34 Tower kernel: veth9f8a52a: renamed from eth0

Jan 19 18:33:34 Tower kernel: br-15893e96a455: port 5(veth2b5ea20) entered disabled state

Jan 19 18:33:34 Tower kernel: veth2b5ea20 (unregistering): left allmulticast mode

Jan 19 18:33:34 Tower kernel: veth2b5ea20 (unregistering): left promiscuous mode

Jan 19 18:33:34 Tower kernel: br-15893e96a455: port 5(veth2b5ea20) entered disabled state

Jan 19 18:33:35 Tower kernel: br-15893e96a455: port 5(vethad5b601) entered blocking state

Jan 19 18:33:35 Tower kernel: br-15893e96a455: port 5(vethad5b601) entered disabled state

Jan 19 18:33:35 Tower kernel: vethad5b601: entered allmulticast mode

Jan 19 18:33:35 Tower kernel: vethad5b601: entered promiscuous mode

Jan 19 18:33:35 Tower kernel: eth0: renamed from vethfaf6e2f

Jan 19 18:33:35 Tower kernel: br-15893e96a455: port 5(vethad5b601) entered blocking state

Jan 19 18:33:35 Tower kernel: br-15893e96a455: port 5(vethad5b601) entered forwarding state

Jan 19 18:33:46 Tower kernel: br-15893e96a455: port 6(vethfa24a54) entered disabled state

Jan 19 18:33:46 Tower kernel: vethda43b85: renamed from eth0

Jan 19 18:33:46 Tower kernel: br-15893e96a455: port 6(vethfa24a54) entered disabled state

Jan 19 18:33:46 Tower kernel: vethfa24a54 (unregistering): left allmulticast mode

Jan 19 18:33:46 Tower kernel: vethfa24a54 (unregistering): left promiscuous mode

Jan 19 18:33:46 Tower kernel: br-15893e96a455: port 6(vethfa24a54) entered disabled state

Jan 19 18:33:46 Tower kernel: br-15893e96a455: port 6(veth79153f7) entered blocking state

Jan 19 18:33:46 Tower kernel: br-15893e96a455: port 6(veth79153f7) entered disabled state

Jan 19 18:33:46 Tower kernel: veth79153f7: entered allmulticast mode

Jan 19 18:33:46 Tower kernel: veth79153f7: entered promiscuous mode

Jan 19 18:33:47 Tower kernel: eth0: renamed from vethe11f8f1

Jan 19 18:33:47 Tower kernel: br-15893e96a455: port 6(veth79153f7) entered blocking state

Jan 19 18:33:47 Tower kernel: br-15893e96a455: port 6(veth79153f7) entered forwarding state

Jan 19 18:33:57 Tower kernel: i2c i2c-4: sendbytes: NAK bailout.

How do i fix this issue?
Thanks in advance

tower-diagnostics-20260119-1834.zip

44 minutes ago, asim2202 said:

Jan 19 18:33:46 Tower kernel: veth79153f7: entered allmulticast mode

Jan 19 18:33:46 Tower kernel: veth79153f7: entered promiscuous mode

Jan 19 18:33:47 Tower kernel: eth0: renamed from vethe11f8f1

Jan 19 18:33:47 Tower kernel: br-15893e96a455: port 6(veth79153f7) entered blocking state

Jan 19 18:33:47 Tower kernel: br-15893e96a455: port 6(veth79153f7) entered forwarding state

These are normal when containers are started or restarted, not normal if they keep showing 24/7

45 minutes ago, asim2202 said:

i2c i2c-4: sendbytes: NAK bailout.

This should be harmless, but a BIOS update may help.

So my unraid just crashed after about 7 hours. The whole system goes unresponsive and needs a hard shut down. All i got from it are the below logs.

syslog-previous

Nothing relevant logged; this typically means a hardware issue. First, I would stop overclocking the RAM, and if that doesn't help, and because memtest is only definitive if it finds errors, since you have multiple RAM sticks, try using the server with just one pair, if the same try with the other one, that will basically rule out bad RAM.

I have already tried 3 different sets of RAM. It eventually ends up crashing the same with no evidence. So far i have swapped. CPU, MOBO, PSU, RAM, CACHE DRIVE, FLASH DRIVE. I've also ordered another HBA to see if thats causing the issue.

One other thing you can try is to boot the server in safe mode with all docker containers/VMs disabled, let it run as a basic NAS for a few days, if it still crashes it's likely a hardware problem, if it doesn't start turning on the other services one by one, including the individual docker containers.

Update few months later.

I found that the server was stable with no dockers running. (i wasnt running VMs anyways). So I was using it as just an SMB server for a few months because it hosts some important files for me.

I then cleared out everything docker related and rebuilt itwith just core dockers that i needed. arr*, nzbget, Jellyfin, NPM, and a few others. And it would keep crashing again even with brand new docker setup.

I then started eperimenting with each docker 1by1. and found that jellyfin was the issue but still it was intermittent and couldnt figure out what was wrong. Now i thinkive narrowed it down to iGPU transcode. I think this crashes the server. But i dont know why.

Any one have experiecne with this?