JorgeB

This is one of the known controllers that this can happen to, but only because it's using a very old firmware: May 26 09:42:16 ES-unRaid kernel: mpt3sas_cm0: LSISAS3008: FWVersion(05.00.00.00), ChipRevision(0x02), BiosVersion(08.11.00.00) If you updated the firmware while on an older Unraid release you'd see the same thing, and note that you should still update the firmware now, since many issues have been fixed since that one, IIRC current release is 16.00.12.00

This is only for servers using a NIC that uses the tg3 driver, this assuming I'm right and the NIC, or more likely the NIC driver, is the problem when VT-d is enabled, if that's the case there's not much LT can do, they can't fix the driver, what they can do for now is to block loading the tg3 NIC driver if one is found during boot and VT-d/IOMMU is enable, this should at least protect anyone updating without being aware of the possible issues. Even if the NICs are the problem it's not clear all different NIC models supported by this driver are affected, so it should also be possible to force Unraid do still use it when VT-d is enable, for anyone that wants to or believes they are not affected by this issue and doesn't want to lose VT-d.

Your should update to v6.10.1, also your server should be affected by this issue, so please disable VT-d now, if it boots OK then post new diags after array start.

Data Metadata System Id Path single single single Unallocated -- --------- --------- --------- -------- ----------- 1 /dev/sdg1 397.00GiB 2.00GiB 32.00MiB 48.10GiB -- --------- --------- --------- -------- ----------- Total 397.00GiB 2.00GiB 32.00MiB 48.10GiB Used 364.44GiB 314.58MiB 80.00KiB They confirm only cache1 is being used, you can usually fix it doing this: -stop the array -unassign cache2 -start array -stop array -re-assign cache2 -start array You should now see activity for cache2, in case of doubt post new diags.

Diags are incomplete, only the config folder is there, please grab new ones.

If it's a Dell server see here: https://forums.unraid.net/topic/119502-bzimage-checksum-error/?do=findComment&comment=1108354

Those moves should be done server side, without using the LAN, assuming same server and Windows 8 or later.

Most likely is only using one device, Please post the diagnostics to confirm.

Looks related to this, but full syslog should confirm: See if this applies to you, if yes, switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info.: https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

Start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=819173

Diags are after rebooting, but disk looks healthy, you mentioned swapping the SATA cable, swap the power cable also and rebuild, if it happens again post new diags before rebooting.

If the extended SMART test passed most likely it's a power/connection, diagnostics might give more clues.

Do you mean the server turned off? If yes that's almost certainly hardware related, or something invoking the shutdown command, and unfortunately the log shows nothing of note.

Log shows some OOM and ATA issues, but mainly Nvidia related errors, and those appear to be the main issue since after the last of those you get this: May 24 04:11:56 Tower kernel: Fixing recursive fault but reboot is needed! And right after that nginx also stopped working.

What you describe is not a direct replacement, the part you quoted is for direct replacing a single device, direct replacement always requires the old device connected, though it should still work, but not something I tested much, if you can't have both new and old devices connected I would suggest first removing one device, shutdown and a connect the new device, then add the new device to the pool.

It's not, IT mode uses the mpt3sas driver, not megaraid_sas. 9341-8i is also megaraid, you'd need the 9300-8i firmware, but likely it will require crossflashing, it probably won't accept direct flashing, try googling "lsi 9340 it mode", instructions on how to should be easy to find.

Enable the syslog server and post that after a crash, though if it's a hardware issue, and by the description it might be, possibly nothing will logged.

It's working for me, VNC window should auto open and connect immediately after VM creation.

Updated for next time

It's an old screenshot I have saved for this.

You can upgrade one at a time. No. See here for more info, if you're still on v6.9.x update to v6.10 first since it's broken on that release: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480419

Yes, as long there are no issues with the appdata folder.

It is, needs to be replaced.

Only issue I see for now is with the docker image, delete and re-create.

The part were the emulated disk had filesystem corruption, likely the result of parity not being 100% in sync. Like mentioned this is usually a RAM problem, unfortunately memtest is only definite if errors are found, not the other way, but like mentioned it could also be for example a disk issue, those are much more difficult to diagnose since basically you need to remove/replace one disk from the array at a time and run a coupe of parity checks to see if it helped or not, that's why I suggested: