JorgeB

Does it show the Unraid boot menu or not even that? Also, post a photo of the BIOS boot menu

The upgrade should not change anything regarding that, most likely it was the reboot, and it sounds like a hardware/BIOS problem to me. Unraid never supported Secure Boot

You can try using iotop to see which process are causing the io activity.

Don't see any obvious issues, both the array and nginx are started, did you try in safe mode to rule out a plugin issue? Also, are you trying to access the server by name or IP? If the former try the IP http://192.168.1.25

All storage devices count for licensing purposes, except a boot or licensing only flash drive, internal boot pool counts.

It would be similar; basically, you need to back up that pool, then use the wizard to recreate it as a split boot pool, then restore the data to the data partitions.

There's a lot of data corruption being detected on disks 1 and 3, but looks like you are using ECC RAM? Is disk1 the one you were trying to check/repair? I would start by scrubbing disk1 and disk3 and checking the results.

I forgot to mention, once you can, I would recommend resyncing parity with the default partition layout, so that you don't get stuck if a disk actually fails. There would still be some options to recover but would be more complicated, like copying/moving the data from the emulated disk first. To make sure the default layout is used, you could do this: stop array unassign parity start array stop array type wipefs -a /dev/sdX (replace X with the correct parity disk identifier) re-assign parity start array to begin parity sync The data disks would still remain using 1 MiB alignment partitions, but as long as parity is 4 KiB aligned, that should no longer be a problem, even with the 4Kn parity; at least it's not according to my tests.

Check/replace cables for disk1, then run another correcting check and post new diags

You can use this https://forums.unraid.net/topic/198440-73xx-version-moving-boot-drive-nvmessd-to-another-drive-nvmessd/#findComment-1619744

I don't see a cause for the problem; in safe model plugins, it should not make any difference, but maybe there's a config problem somewhere, my suggestion would be to first upgrade to 7.3.1, if the issues persists there, try redoing the flash drive, backup the current one first and then recreate it using the USB tool and just restore the bare minimum, like the key, super.dat and the pools folder for the assignments, also copy the docker user templates folder (\config\plugins\dockerMan\templates-user), if all works you can then reconfigure the server or try restoring a few config files at a time from the backup to see if you can find the culprit.

btrfs is detecting data corruption; start by running memtest.

Yep, nothing else logged, I'm afraid there may be an issue with the pool, a device, or it's hitting some btrfs raid5 bug. My recommendation would be to back up and recreate the pool, and if you still want raid5, use zfs raidz i nstead, btrfs raid5/6 is still considered experimental.

It can be that one.

You can use this: https://forums.unraid.net/topic/198440-73xx-version-moving-boot-drive-nvmessd-to-another-drive-nvmessd/#findComment-1619744

Check to see if their templates exist on the flash drive (\config\plugins\dockerMan\templates-user)

That, to me confirms the upgrade wasn't the issue, if multiple clients are still failing to access the shares, I suspect a config problem.

See if this shows anything more: dmesg | grep -i btrfs | tail -n 10 Also post the output from btrfs device stats /mnt/cache

The error suggests an i/o error with one of the remaining pool devices, but I don't see anything logged. If you try the command again, does it show the same error?

Jun 16 13:41:34 Unraid kernel: mt7925e 0000:03:00.0: Message 00020016 (seq 9) timeout Jun 16 13:41:34 Unraid kernel: mt7925e 0000:03:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260414153001a Jun 16 13:41:34 Unraid kernel: Jun 16 13:41:34 Unraid kernel: mt7925e 0000:03:00.0: WM Firmware Version: ____000000, Build Time: 20260414153105 Jun 16 13:41:35 Unraid dhcpcd[2634]: wlan0: carrier lost Same issue as before, possibly a hardware or firmware issue

Hmm, will need to do some testing, but it looks like there's also a bug with the parity swap, and not only because of the 4Kn disk, but there's another one because of that , so possibly two separate but related bugs. Since this may take some time for LT to fix, my recommendation would be to re-enable the disk (assuming that disk is still intact). If you copied any data to disk1 after it got disabled you will need to copy that first, then do a new config, reassign all the disks to their original slots, if you haven't been using the array with the disabled disk, parity should be mostly valid, so you can use it and then just run a correcting check Tools -> New Config -> Preserve current assignments: All -> Apply Raising disk1 and parity as they were origianlly Check "parity is already valid" if that is the case Start the array Run a correcting check.

It does not, boot in safe mode and start a new check from the GUI, if that still fails, please post new diags.

hmm, post new diags or just the syslog after running that command

Try upgrading again and post the diagnostics after that (before rebooting)

It is also odd to me, but I think it may be related to having pool activity with such a large pool, try to avoid new reads and writes as much as possible, and it should again continue the resilvering. At least I don't see anything that would suggest a slow disk or disks, downgrading the resilver speed.