JorgeB

These traces are usually the result of having dockers with a custom IP address, upgrading to v6.10 and switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)).

It's worth trying, you can also boot the server in safe mode with all docker/VMs disable, 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.

I would say that if you've been running v6.10.0 for a few days without issues you are likely fine, of course if don't need vt-d it's a no brainer to leave disabled for now.

Affected by the NIC being blacklisted or call traces/corruption issue? There's one report from another Z800 user and so far no signs of being affected by the actual issue: https://forums.unraid.net/topic/124237-nics-gone-after-upgrade/

Jun 2 12:01:08 CicioneServer kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jun 2 12:01:08 CicioneServer 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 should 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 should return normal results once the disk has being fully written at least once, after that actual used capacity used should not be important.

It's possible with WD SMR disks that haven't been fully written, when the disks knows there's no data there it returns zeros from the controller, doesn't read the disk surface, hence the higher speeds, once the disk has been fully written you should see normal results.

Lets see if @bonienlcan help, but he will likely need the diags from v6.10.2

Strange, not seeing an attempt to start docker after the rebuild started, once the rebuild finishes reboot and post new diags if it still doesn't start.

Yes, it will list them in the syslog.

Yes, you should be fine after unblacklisting the NIC, no evidence so far of this issue with any Dell server.

Yes, also remembered there's already a thread about those drives with lots of actual data:

Could still be, if for example you're suing a controller or other hardware that has known issues.

This means the folder already exists, you can reboot, remove that one or create a different named folder.

You can try with a a new clean flash drive, don't even need a key to test.

Yes. No need if it's already a booting flash, but it will never hurt.

I suspect something was already wrong with the pool pre-update, like it was only one of the devices.

This is a BIOS problem, look for an update, though it's safe to ignore As for the ATA error, swap disk5 cables with a another disk and see if the error follows or stays with disk.

Pool looks OK now, and syslog is normal, as for the VM it's not my specialty and can't really help with that, I would suggest making a new post in the KVM section.

You can try recreating the flash drive, manually or using the USB tool, before doing it backup the config folder, then restore it. If that doesn't help and you want to go back to v6.9.2 just copy the all the bz* files from the v6.9.2 download overwriting existing files on flash.

There are some recommended models on the first post:

Enable the syslog server and post that after the next time it happens.

Second device is not being decrypted, like if it's not encrypted, I assume both were part of the pool? If yes post the output of: cryptsetup luksOpen /dev/nvme0n1p1 nvme0n1p1

Everything looks good so far, log spam is gone and the rebuild is going without errors.

RAM would still be my #1 suspect, run memtest for a few more passes.