JorgeB

That will be a plugin.

This suggests a hardware issue; recommend addressing this first. Read errors on disk1 are logged as a disk problem; run an extended SMART test.

You should have backups of anything important either way, if you have good backups and they are easy to restore, RAIDZ1 is less of a risk, but even with RAIDZ2, backups are still needed.

This is the boot pool, these two disks, if those are the one you wanted to use, it's correct. It is. Post the diagnosis to confirm a TPM device is not being detected, or if it is but there'sa problem..

Try the open files plugin.

You can, or you will need to resync parity. Either way, the new disk will need to be formatted in the end.

It would mostly depend on how good the backups are. The extra I/O should not be a big deal for healthy drives.

Probably some change in the kernel. What is the time zone set to in Settings - Date and Time?

Click on reset stats, then scrub the pool and if there are any errors found, post the scrub result.

You can ignore that.

If this is a dedicated boot pool, the easiest way is to boot from the flash again and recreate the boot pool using another device: https://forums.unraid.net/topic/198440-73xx-version-moving-boot-drive-nvmessd-to-another-drive-nvmessd/#findComment-1619744

Try recreating the flash drive, first backup the current one, then recreate it using the USB tool, confirm the flash drive boots with the stock install, and if yes, restore only the /config folder from the backup overwriting any existing files. If that doesn't work or you need more help, please start a new thread in the general support forum.

Try just closing it, if you can't reboot and close it when it first shows

There are issues with multiple devices, and I see you are using a controller with SATA port multiples. Those are not recommended and can cause a lot of issues. It could also be the reason for the unresponsive issues with newer versions due to kernel updates. I recommend replacing it with one from here:Recommended controllers for Unraid - Storage Devices and Controllers - Unraid

Reimporting the pool will keep all the data. Any shares that were using that pool you can edit and reapply with the new pool name, if you have multiple shares configured the same way, you can copy the setting from one to many, in the Share settings page.

If you have space on the array, you can also use the mover to empty an array disk, format it with the new filesystem, then move on to the next one

May 15 09:49:53 nas emhttpd: Error: (/dev/sda) not known There's a problem with the flash drive partition or layout; 7.3 is more strict about that. Back up the flash drive, recreate it using the USB tool, then restore only the config folder from the backup

This is likely a disk that has a FAILING NOW SMART attribute; unrelated to the upgrade, just showed now because of the reboot. You should be able to press F1 to continue booting, or disable SMART monitoring in the BIOS; still, then you need to find which disk is bad. If none of those work, you can also disconnect one of the disks at a time until you find the culprit.

With 7.3 you cannot have a pool name that starts with mirror, it's reserved by zfs, and no longer allowed. To reimport the old pool, add a new pool with two slots using a new non-reserved name, assign the devices, let the filesystem in auto, and start the array to reimport the pool

Look in the syslog and there should be one or more files listed during the scrub that are corrupt. Those files should be deleted/restored from a backup , then run another scrub to confirm 0 errors. Since memtest didn't detect any issues, they may be old errors, but note that memtest is only definitive if it finds errors, so keep monitoring the mpool. If new corruptions are detected, there's still a problem. The xfs issue could or could not be related to the issues that caused the data corruption on btrfs, but if xfs_repair can't fix it and you don't have a backup, best bet is to use a file recovery app like UFS Explorer to recover the data and then reformat the disk.

Check/replace both cables and retest.

Wipe the device(s) you plan to use for boot with blkdiscard -f /dev/nvme#n1 Then reboot, and try again

You can mount it with the Unassigned Devices plugin and then use the File Manager or your favorite tool to copy the data from that disk to the array.

By not boot, do you mean it doesn't finish or start the boot process? Post a photo of what you see. And if it boots, but you just cannot access the GUI, but you can access the server over SSH or using a keyboard and monitor, please post the diagnostics

You cannot format a disk to change the filesystem while keeping the data, but if you still have the old disk, you can mount it with the Unassigned Devices and copy the data to the new one.