JorgeB

Don't think so, if it crashes during bz* files loading, try v6.11.0-rc2 just to make sure it's not some kernel compatibilty, v6.11 includes a much newer kernel.

That looks like a hardware issue, assuming that changing the flash drive didn't help.

Look for a lost+found folder and any files there.

You can also try a BIOS update and/or update to Unraid v6.11.0-rc2, sometimes just a BIOS/kernel change can help, if it keeps dropping it's likely hardware related, but not necessarily bad hardware.

Repair the filesystem and then depending on the result you can see if the old disk can still be used to recover data if needed.

Very strange, since the cache device is in a controller with other devices and those are not affected, do you have any other free SATA port you could use for the cache device?

It dropped again, try a different M.2 slot if available, failing that try a different brand/model NVMe device (or a different board).

Basically the only option is to fix the filesystem, this corruption after a rebuild suggests parity wasn't 100% in sync, do you still have the old disk intact or it failed/died?

Check filesystem on disk2.

Yes, and check that in the end there are no uncorrectable errors.

There might be some config issue with the GPU, suggest you recreate de flash drive using the default settings, you should then be able to boot and register.

Click on Update OS, then on the top right side:

Disk was already disabled at boot time, if it happens again grab the diags before rebooting. This indicates that the cache SATA device dropped offline some time ago: Jul 27 11:41:21 Icaria kernel: BTRFS info (device nvme0n1p1): bdev /dev/sdd1 errs: wr 231821, rd 56307, flush 14833, corrupt 820, gen 0 Run a scrub and then see here to reset the stats and for better pool monitoring. There's also data corruption detected on the other pool, Ryzen with overclock RAM like you have is known to in some cases corrupt data, see here.

Did you click check for updates?

In what part of the boot does it stop? Make sure UEFI boot is enabled, if there's an EFI- folder in the flash drive rename it to EFI and try again.

There's usually a BIOS option for that, but then you can't use the Nvidia for VM pass-trough, or at least it will be much more difficult.

199 UDMA_CRC_Error_Count -O--CK 200 171 000 - 2468648 Disk was already disabled at boot, but there are still constant errors, the above attribute suggests an issue with he SATA cable.

As long as it's up to date it's fine. That's the easy part, you can even keep the old array config, certainly it's not that causing the issues.

I had the same issue a few hours ago, also noticed the plugin install took an unusually long time to install, especially for the first lines to appear, windows was blank for a long time, though it appeared to install correctly, I now removed the plugin from the flash drive, rebooted, re-installed, install was quick and now it's working.

If you unticked "allow UEFI" boot it won't boot UEFI, you can just rename EFI- to EFI. Those boards won't boot CSM with the iGPU as the main GPU.

Backup current flash, recreate it then restore the config folder, if there are still issues do it again but don't restore the complete config folder, starting restoring a few files at a time to see if you can find the problem, or just reconfigure the server.

You can try making a post about that in the KVM section.

Link detected: no No link on the NIC.

Delete the file manually, on the console type: rm /mnt/disk4/system/docker/docker.img

Like mentioned it's default, not sure it's possible to remove, you don't need to use it.