JorgeB

Continue like if you were installing Windows, when it asks for the installation destination add the KVM storage driver, you will now see the VM disk(s), just cancel the install and go back to the repair option, the drivers will still be loaded.

May 26 20:25:52 Marvin shutdown[9676]: shutting down for system halt Something is invoking the shutdown, try booting in safe mode, also make sure power button is working correctly or just temporarily disconnect it, a single press will initiate a shutdown.

With btrfs it's easier to see if there have been issues, it records any corruptions found and it usually quickly goes read-only if the issue is bad enough, with XFS only the most severe case might notice problems, like unmountable filesystem or a lost+found appearing after running xfs_repair, running a parity check is also a good idea.

I wouldn't say definitely, there have been multiple cases, but as expected we mostly hear form people that had issues, so unclear if all are affected, also some cases are much serious than others, I would say that it's a good sign if you've been running the server for a few days without noticing any issues, like docker stopping working, etc, if want post the diagnostics or pm them to me, might be able to give you a better idea.

Either disable vt-d or unblacklist the NIC as described above, if you want post the diagnostics, it might help us say what option is recommended.

Was just going to post that if the NIC was being blacklisted the driver won't appear, if you don't mind please post the diagnostics just to check your hardware.

First check this, if it doesn't help enable the syslog server and post that after a crash.

First would recommend connecting the SSDs to the Intel SATA ports, if that's not possible at least update LSI firmware to latest to see if all the errors go away, then enable the mover logging, run it and post new diags.

Unclear for now if all servers using those NICs are affected, mostly have been HP servers for now, but there's also one IBM/Lenovo, you can still use the NIC with vt-d enable, how to is in the release notes, just be aware that until we find exactly what's causing the issue there are some risks.

May 25 20:58:07 Skrumpy kernel: macvlan_broadcast+0x116/0x144 [macvlan] May 25 20:58:07 Skrumpy kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, 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/

It's in the release notes, since that server is known to have issues with vt-d enable you should disable it, you can do that in the BIOS or by adding 'intel_iommu=off' to syslinux.cfg

Can't answer that, never used those, just delete one of them.

See my reply above, v6.10.2 will block loading that NIC driver if vt-d is enable, so your server will be affected by that, for now doesn't look like it's affected by the possible corruption issues, but can't say for sure. To use the NIC with v6.10.2 and vt-d enabled see the release notes:

Forgot to mention, most of the errors were detected in the docker image, for that best just to delete and re-create: https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564309

Start by running a scrub, if uncorrectable errors are found look in the syslog for the affected files, if no errors are found or they are corrected reset the counters and keep monitoring, more info here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=700582

No signs of any corruption so far, yours is the first Dell server I see using the tg3 driver, maybe it's not affected? So far mostly HP servers have been affected, but there was also an IBM/Lenovo, so it's not limited to HP servers, if you don't need vt-d I would still recommend disabling it, if you do you can unblacklist the NIC with v6.10.2 and monitor the logs for any future issues, or go back to v6.9.2 is you want to play it safer for now.

If the diags don't download after a couple of minutes they won't, try getting at least the syslog for now: cp /var/log/syslog /boot/syslog.txt

If the problem like suspected comes from the tg3 NIC driver not much LT can do for the moment until a fix is released.

Btrfs already found some corruption and there are the typical call traces logged, you should disable vt-d now, if you really need it you should go back to v6.9.2 for now, note that you can still run VMs with vt-d disabled, just not able to pass-through any devices to one.

Btrfs already found some corruption, so you're likely affected, recommend only running v6.10.x with vt-d disabled, if you really need it enabled you should go back to v6.9.2 for now.

VMs still work, but without vt-d you won't be able to pass-through any devices, like a NIC, GPU, etc.

File exists Mover won't move any files that already exist on destination, you should compared them manually and delete on of them.

Please check the release notes, if a NIC using the tg3 driver is found and vt-d is enabled the NIC will be blacklisted to avoid stability and even possible corruption issues, you can always enable the NIC again manually if you think you're not affected:

Please post the diagnostics with v6.10.2, hopefully they will give some clues.

It doesn't, you can run an extended SMART test to confirm, but likely you'll need to replace that drive.