JorgeB

I would try a clean install with a different USB just to see if it boots, also look for a BIOS update and/or try both CSM and UEFI boot.

Jul 6 21:38:14 kunraid kernel: BTRFS: device fsid 0ecc5969-4afc-4b9a-a299-3fab30cf63d9 devid 1 transid 153079 /dev/sdb1 scanned by udevd (1244) Jul 6 21:38:14 kunraid kernel: BTRFS: device fsid 0ecc5969-4afc-4b9a-a299-3fab30cf63d9 devid 2 transid 147224 /dev/sdc1 scanned by udevd (1234) devid 2 is on an older generation than devid 1, this can sometimes fix it: btrfs-select-super -s 1 /dev/sdc1 If you rebooted since the diags check that ssdcache2 is still sdc, then reboot and if it still doesn't mount post new diags.

Jul 5 08:41:10 duck kernel: macvlan_broadcast+0x10e/0x13c [macvlan] Jul 5 08:41:10 duck kernel: macvlan_process_broadcast+0xf8/0x143 [macvlan] Macvlan call 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)), 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/

Yes, except with some RAID controllers.

Are you sure they were both correct? If you didn't reboot yet post the diags.

That works, just make sure files are not in use.

Not necessarily bad but that's not normal, could be a BIOS config or problem.

Apple and Samba..., several Samba errors in the log, see if disabling the SMB macOS specific options helps or not.

Looks like the typical Ryzen onboard controller issue, it's quite common with some Ryzen servers, usually mostly under load, look for a BIOS update but best option might be to use an add-on controller.

Yes, it won't affect the rebuild, check filesystem on disk2 when it's done.

CPU usage is still very high for just two disks going at those speeds: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 2 0.0 0.0 0 0 ? S 22:22 0:00 [kthreadd] root 92867 94.9 0.0 0 0 ? R 22:31 3:35 \_ [unraidd0]

9211 could limit performance a little in an x4 slot with 6 fast disks, other 2 options will be the same.

Sounds good to me.

First thing to try is booting in safe mode to rule out any plugin, you can also disconnect the power button just to make sure there's not a problem there.

That would be unrelated, 6.10.3 doesn't blacklist any NICs like some previous 6.10 releases, please post the diagnostics.

Best bet is to use the container's existing support options:

Enable mover logging, run the mover and when it stops post diags.

Run another parity check without rebooting and post new diags if sync errors are found.

There appears to be issues with the flash drive, not sure it's related,. you should also update Unraid since you're on an ancient release.

Make a backup of the flash drive just in case but usually there's not much to it, just update and reboot.

Did rsync finish the transfer? Incomplete transfer folders might have the wrong permissions, if it did finish also check folder permissions and compare with a working one

You can still use the data in the other disks, just need to do a new config and re-sync parity.

Cache2 SSD appears to be failing, you can run an extended SMART test to confirm.

Found the other thread but there's no clear solution, some things to try though: https://forums.unraid.net/topic/123903-slow-parity-rebuild/?do=findComment&comment=1130584

I believe there's a plan for Unraid to soon have an option to easily install out of tree drives, this is the best bet for issues like these, since compiling the various out of tree drivers with every Unraid release was becoming very difficult for LT.