JorgeB

If the latest version shows as an update from 6.9 you can update directly, but create a full flash drive backup first. Also, recommend reading the release notes for all the minor versions in between, 6.10.0, 6.11.0, etc

When you create a snapshot, a local qcow2 file is created to reference it. Getting rid of those files, and restoring only the vdisk should resolve the issue.

We seem to be going in circles. I already told you before how to add a slot to an existing pool, but the pool you posted a screenshot from already had 2 members; you can create a new one if you like using the wizard (after rebooting from a flash drive)

SHould be in the docs below, and you would only lose the snapshot, not the current data. https://docs.unraid.net/unraid-os/using-unraid-to/create-virtual-machines/vm-setup/#vm-snapshots

This is not the correct procedure to create a boot pool, you don't start the array or format anything, just run the wizard and let Unraid configure the internal boot pool, and it will then automatically reboot.

Thanks, the new logs are very useful. They confirm that this is broader memory-management corruption rather than an isolated shfs, XFS, BTRFS, or Plex problem. Before the later crashes, the kernel reports bad RSS counters, non-zero page-table accounting, and BTRFS pages that are still mapped while being deleted. Oopses #2 through #12 then fault at the same location in mas_ascend(), with the repeated state strongly suggesting that lsof, another task, and later khugepaged are encountering the same damaged process address-space tree. The repeated trailing xfs_iget() register block matches the original August 20 oops and does not appear to be a new XFS crash each time. The fault while unmounting /var/lib/docker occurs after the system has accumulated all this corruption, so it is more likely a secondary failure than a separate BTRFS unmount bug. After the reboot, unrelated .NET and dynamic-loader processes start segfaulting again within approximately 50 minutes and on both CPU sockets. The later Plex message requesting about 94.5 TB is not genuine memory exhaustion, the diagnostics still show approximately 77.5 GB available, but likely another indication of a corrupted process state. This suggests a real kernel/MM corruption issue, but it still does not establish whether the underlying cause is the 7.3.2 kernel, an optional/out-of-tree module, or hardware/ platform instability. There are still no recorded MCE, EDAC, PCIe AER, OOM, storage-reset, or filesystem-corruption errors. The latest diagnostics show another normal-mode 7.3.2 boot, so the most useful next test would be: 1. Boot in Safe Mode with Docker and VM autostart disabled. 2. If that remains stable, enable Docker while still in Safe Mode and start the workload/container groups incrementally. 3. Also provide the results of Dell’s extended hardware/memory diagnostics, multiple complete memory-test passes, and the iDRAC/Lifecycle Controller SEL. 4. If those tests remain clean, compare 7.3.2 with 7.2.8 while keeping the BIOS settings, memory population and workload unchanged. Ideally, return to 7.3.2 afterward to confirm whether the corruption recurs. Keep remote syslog enabled. After the first new kernel oops or bad-page/RSS warning, preserve the log and reboot rather than continuing workloads on the already-corrupted kernel.

Please use the wizard to create the pool, not the CLI

Try this first https://forums.unraid.net/topic/118286-nvme-drives-throwing-errors-filling-logs-instantly-how-to-resolve/?do=findComment&comment=1165009

See below for the first issue, it's a know bug. Some workarounds there: Missing ? docker icon log spam - General Support - Unraid

I created and recreated many boot pool, if it's failing for you it's not a general problem. need to see the diags after the attempt.

Flash drive doesn't have the correct layout, 7.3.x is more strict about that, backup the current flash drive, recreate it using the USB tool, then restore only the config folder from the backup

The references may be related to the snapshots; you can remove and consolidate the snapshot in the main vdisk, that should get rid of the references.

Feature requests are now tracked here; make sure it exists there: https://product.unraid.net/b/unraid-os-feature-requests

The boot pool already has two devices assigned; Multimedia is just the data part of the boot pool. They are not two separate pools, though I see that the pool wasn't created correctly, since only the data partition is mirrored. Suggest recreating it.

The diagnostics confirm a genuine kernel oops in xfs_iget() while shfs was performing a filesystem lookup. However, shfs is only the process context in which the fault surfaced; this does not currently establish an shfs or XFS-specific bug. More importantly, the same boot contains 26 userspace segfaults and an invalid-opcode fault across several unrelated components, including Python, .NET, PHP, Node, smartctl, Radarr, and Sonarr. These faults occurred on 21 different logical CPUs and were split evenly across both CPU sockets. Some occurred before the xfs_iget() oops and others continued afterward. There was plenty of available memory, no OOM event, and no accompanying XFS corruption, storage I/O, controller-reset, MCE, or EDAC error. The absence of MCE/ECC events does not completely rule out a marginal DIMM, CPU memory controller, motherboard, or power issue. The separate log archive unfortunately does not contain the reported kswapd0/shadow_lru_isolate crash. Twelve of its thirteen daily files are empty, and the only populated file contains routine activity rather than a crash. At this point, it doesn't look to me like this is a 7.3.2 kernel regression. Hardware/platform instability is the leading possibility, although a broader kernel memory-management issue remains possible. My recommended next steps: - Verify that remote syslog is actually receiving and retaining a test message. Use TCP instead of UDP if the receiver supports it. - Export the iDRAC/Lifecycle Controller hardware and SEL logs. - Run Dell’s extended CPU and memory diagnostics, followed by multiple complete passes of a boot-time memory test. - If necessary, test matched RDIMM sets separately according to the T420 memory-population rules. - Test Unraid Safe Mode with Docker and VM autostart disabled. - Reboot promptly after any further kernel oops; avoid continuing write-heavy array, VM, or database activity on an already-corrupted boot. Downgrading to 7.2.8 can be useful as a controlled A/B test, but stability on an older kernel alone would not prove a 7.3.2 bug because changing kernels also changes memory layout and timing. Ideally, hardware testing should be completed first, followed by a controlled 7.3.2 → 7.2.8 → 7.3.2 comparison with the same hardware, workload, and logging configuration.