JorgeB

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.

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.

From what I can see there are only 3 drives connected to the JMB controller, all 3 are being detected, the two that aren't are connected to the onboard SATA ports, though can't see why they aren't working, if there's space connect all 5 devices devices to the JMB controller, or try using the other two onboard SATA ports.

2 of the SATA ports are set to IDE, go to the BIOS and change them to AHCI/SATA, usually ports 5/6, that's where disks 2 and 4 are connected, if after doing that they are still unmountable run xfs_repair, don't run before correcting that.

Disk is not giving a SMART report, check replace cables and post new diags after array start.

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

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/

Cache filesystem is corrupt, best bet is to copy all important data elsewhere then re-format and restore the data.

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/

Didn't read the entire post, if you're getting an IP that's not the problem, please post the diagnostics.

00:17.0 RAID bus controller [0104]: Intel Corporation Device [8086:43de] (rev 11) DeviceName: Onboard - Other Subsystem: ASUSTeK Computer Inc. Device [1043:8694]  
No SATA controller being detected, only this, see if there's an option in the BIOS to change it to AHCI/SATA

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

Try this:
https://forums.unraid.net/topic/124055-unraid-6101-fails-to-boot-bzroot-checksum-error/?do=findComment&comment=1131675
 

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

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.

If it works in safe mode it suggests one of the plugins is the problem, uninstall or rename the plg files to see if you can find the culprit.

Prefail is just the type os some SMART attributes, also disk4 looks healthy, most likely not a disk problem.

Change /mnt/user0/ to /mnt/user/, user0 doesn't include contents from any pool.

See my reply to your other post, you need to remove device 81 from the VM XML:
 
-device vfio-pci,host=0000:81:00.0,id=hostdev0,bus=pci.4,addr=0x0 \  

Server was rebooted in the middle so can't see everything that happened, current cache is mounting, but it's empty, possibly some error during the replacement.
 
Also note that you have device 81:00 bound to vfio-pci, 81 is now one of the NVMe devices and although it's a different device and it wasn't bound it still brought the device offline, so delete that bind and run a correcting scrub on the pool.
 
As for the old data, I assume this device was part of the original pool?
 
C300-CTFDDAC128MAG_00000000102202FBC295 (sdl)  
If yes this also suggests the replacement wasn't done correctly since there's still a btrfs filesystem there, and it should have been wiped during the replacement, if this was part of the old pool and the pool was redundant you should be able to mount it if you assign alone to a new pool (not with UD), if it doesn't mount in a new pool post new diags, maybe it can be mounted manually.

Looks like the docker image ran out of space, the system share exists on both disk1 and cache, if the docker image is on disk1 the disk is completely full, if that's the case I would recommend deleting that one and recreating the image on cache.

See here:
 
 

Disk does appear to be failing, you can run an extended SMART test to confirm.

Check that it's well seated, if errors persist you likely have a bad CPU.

That's good news!
 
UD historical devices don't really matter for this, but you can remove it now or later, I assume you plan do re-add the other device o the pool?
 
If yes first make sure backups are up to date, then you'll need to wipe the other device before adding it back to the pool, you can do it like this:
 
-check that array auto start is disable, shutdown server
-reconnect the other NVMe device
-power on the server, don't start the array
-wipe the unassigned device with
blkdiscard /dev/nvme#n1 Replace # with correct number, not sure if 6.9.2 needs -f for blkdiscard if a data is detected, if yes use it.
-assign it back to the pool
-start array to begin balance