JorgeB

Copy all the bz* files from the older release to the flashdrive overwriting the existing ones and reboot.

Not done anything, but if it's kernel related going to the previous release you were using will solve the problem.

If the same thing happens it wasn't because of the update.

You might need to wait for a newer kernel, a board bios and/or HBA firmware upgrades might also help.

Macvlan call traces are usually related to dockers with custom IP addresses.

Kernel oops during device discovery, possibly a kernel issue: Jun 30 23:54:59 unWejaton kernel: sas: phy-14:0 added to port-14:0, phy_mask:0x1 (5003048001dfecff) Jun 30 23:54:59 unWejaton kernel: sas: DOING DISCOVERY on port 0, pid:2363 Jun 30 23:54:59 unWejaton kernel: BUG: unable to handle kernel paging request at ffff8880ffa7b360 Jun 30 23:54:59 unWejaton kernel: PGD 2401067 P4D 2401067 PUD 0 Jun 30 23:54:59 unWejaton kernel: Oops: 0000 [#1] SMP PTI Jun 30 23:54:59 unWejaton kernel: CPU: 11 PID: 2363 Comm: kworker/u112:1 Not tainted 4.19.56-Unraid #1 Jun 30 23:54:59 unWejaton kernel: Hardware name: ASUSTeK COMPUTER INC. Z10PE-D16 WS/Z10PE-D16 WS, BIOS 3305 06/22/2016 Jun 30 23:54:59 unWejaton kernel: Workqueue: 0000:82:00.0_disco_q sas_discover_domain [libsas] Jun 30 23:54:59 unWejaton kernel: RIP: 0010:pm80xx_chip_smp_req+0x22d/0x36c [pm80xx] Jun 30 23:54:59 unWejaton kernel: Code: c7 c6 10 1e 13 a0 48 c7 c7 8f 5b 13 a0 e8 3f 25 f6 e0 49 8d 44 24 1c 45 31 ff 48 89 44 24 08 41 39 ef 73 87 8b 83 48 44 00 00 <47> 0f b6 44 3d 00 83 e0 08 41 83 ff 0f 77 18 85 c0 47 88 44 3c 0c Jun 30 23:54:59 unWejaton kernel: RSP: 0018:ffffc9000812bbf8 EFLAGS: 00010093 Jun 30 23:54:59 unWejaton kernel: RAX: 0000000000000001 RBX: ffff88905a6f0000 RCX: 0000000000000080 Jun 30 23:54:59 unWejaton kernel: RDX: 00000000ffa7b360 RSI: 0000000000000001 RDI: ffff88885f027200 Jun 30 23:54:59 unWejaton kernel: RBP: 0000000000000008 R08: 0000000000000040 R09: 0000000000000002 Jun 30 23:54:59 unWejaton kernel: R10: ffff889059bff4e0 R11: ffff88885a4d0e00 R12: ffffc9000812bc0c Jun 30 23:54:59 unWejaton kernel: R13: ffff8880ffa7b360 R14: ffff889044801080 R15: 0000000000000000 Jun 30 23:54:59 unWejaton kernel: FS: 0000000000000000(0000) GS:ffff88885f6c0000(0000) knlGS:0000000000000000 Jun 30 23:54:59 unWejaton kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 30 23:54:59 unWejaton kernel: CR2: ffff8880ffa7b360 CR3: 0000000001e0a001 CR4: 00000000003606e0 Jun 30 23:54:59 unWejaton kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jun 30 23:54:59 unWejaton kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Jun 30 23:54:59 unWejaton kernel: Call Trace: Jun 30 23:54:59 unWejaton kernel: pm8001_task_exec.isra.2+0x2ba/0x3c1 [pm80xx] Jun 30 23:54:59 unWejaton kernel: ? smp_task_timedout+0x44/0x44 [libsas] Jun 30 23:54:59 unWejaton kernel: smp_execute_task_sg+0xf8/0x224 [libsas] Jun 30 23:54:59 unWejaton kernel: smp_execute_task+0x52/0x6e [libsas] Jun 30 23:54:59 unWejaton kernel: sas_discover_expander.part.6+0x7d/0x542 [libsas] Jun 30 23:54:59 unWejaton kernel: sas_discover_root_expander+0x46/0xd2 [libsas] Jun 30 23:54:59 unWejaton kernel: sas_discover_domain+0x4a5/0x59b [libsas] Jun 30 23:54:59 unWejaton kernel: process_one_work+0x16e/0x24f Jun 30 23:54:59 unWejaton kernel: ? pwq_unbound_release_workfn+0xb7/0xb7 Jun 30 23:54:59 unWejaton kernel: worker_thread+0x1dc/0x2ac Jun 30 23:54:59 unWejaton kernel: kthread+0x10b/0x113 Jun 30 23:54:59 unWejaton kernel: ? kthread_park+0x71/0x71 Jun 30 23:54:59 unWejaton kernel: ret_from_fork+0x35/0x40 Jun 30 23:54:59 unWejaton kernel: Modules linked in: acpi_cpufreq(-) sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate ipmi_ssif intel_uncore pm80xx(+) mxm_wmi wmi_bmof igb libsas intel_rapl_perf mlx4_core(+) sr_mod ahci i2c_i801 scsi_transport_sas i2c_algo_bit i2c_core libahci cdrom wmi ipmi_si pcc_cpufreq acpi_power_meter acpi_pad button Jun 30 23:54:59 unWejaton kernel: CR2: ffff8880ffa7b360 Jun 30 23:54:59 unWejaton kernel: ---[ end trace 30c9b447b115a633 ]---

Yep

Try booting in safe mode (also stop docker service) and use it like that for a few days to see if there's still a problem, if yes it's likely hardware related.

You can only connect one cable (single link) or two cables (dual link and max link speed for best performance) to the backplane, hence why no point in having an HBA with more ports.

That backplane has a bultin expander, you just need an HBA with 2 miniSAS connectors, like 9300-8i, no point in buying anything with more ports.

No, I was just giviing some examples of the most common ones, the 9305-24i will also work fine, you can always google Unraid + HBA model you want and are likely to get some hits

You should start by running memtest

Any LSI with a SAS2008/2308/3008 chipset in IT mode, e.g., 9201-8i, 9211-8i, 9207-8i, 9300-8i, 9400-8i, etc

Because exFAT doesn’t understand permissions, owners, or groups.

Both images are corrupt, you'll need to recreate them, libvirt should be restored from a backup if available or you'll lose the XML for the VMs , corruption most likely caused by one of you cache drives (cache1) dropping out in the past: Jun 26 15:38:58 unraid kernel: BTRFS info (device sdk1): bdev /dev/sdk1 errs: wr 469514164, rd 255940664, flush 10036587, corrupt 0, gen 0 These are read and writes errors, and a lot of them so it dropped out for some time, or multiple times, see here for more info on how to better monitor a pool.

Not at this time, sorry, but I believe the HBA should work normally if you just use one of the standard PCIe slots, not the storage slot.

Check the VM config and make sure "Initial Memory" and "Max Memory" are set to the same value.

If current cache is btrfs you can do an online replacement, and can even continue to use it normally during it.

I would run a few days in safe mode with all docker disable, if stable try turning on the dockers on by one, if still unstable it's likely a hardware problem, like PSU, etc.

There are known issues with Ryzen and Linux, there are workarounds that work for most users, they are discussed here:

OK, I see that: Jun 15 03:02:51 Tower root: Creating new image file: /mnt/user/system/libvirt/libvirt.img size: 1G Unraid is trying to create libvirt.img but it never gets created, there aren't also any errors or reason why it's failing to do it, weird issue, if possible I would try connecting the disk to the onboard controller and trying again, or make sure libvirt is created on a device using the onboard controller, like a cache device.

Disk1 is mounting correctly: Filesystem Size Used Avail Use% Mounted on /dev/mapper/md1 3.7T 25G 3.7T 1% /mnt/disk1 Is is not available on the shares or what is exactly the problem?

You need to check/swap connections for the missing disks, check if they are detected in the bios, very unlike two disks would die at the same time. A new config would allow you to start the array but by losing the data on both missing disks.