JorgeB

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.

So it worked? I thought the plan was using both devices

Partition for one of the devices is invalid May 15 16:53:07 Orion mkbootable: writing GPT on device (nvme1n1), with boot area size 16384 MiB May 15 16:53:07 Orion root: #007Caution: invalid backup GPT header, but valid main header; regenerating May 15 16:53:07 Orion root: backup header from main header. May 15 16:53:07 Orion root: May 15 16:53:07 Orion root: Caution! After loading partitions, the CRC doesn't check out! May 15 16:53:07 Orion root: #007Warning! Main partition table CRC mismatch! Loaded backup partition table May 15 16:53:07 Orion root: instead of main partition table! May 15 16:53:07 Orion root: May 15 16:53:07 Orion root: Warning! One or more CRCs don't match. You should repair the disk! May 15 16:53:07 Orion root: Main header: OK May 15 16:53:07 Orion root: Backup header: ERROR May 15 16:53:07 Orion root: Main partition table: ERROR May 15 16:53:07 Orion root: Backup partition table: OK May 15 16:53:07 Orion root: May 15 16:53:07 Orion root: Invalid partition data! Try this: wipe both devices first: blkdiscard -f /dev/nvme0n1 blkdiscard -f /dev/nvme1n1 Reboot and try again, if it still fails, post new diags

For single pool, you can use XFS, btrfs or ZFS. It will delete all the data on the cache pool, nothing else.

What do you mean by this? Both SMART reports look perfect to me.

May 14 17:30:18 PeppeRAID kernel: ntfs3(nvme0n1p1): MFT: r=38, expect seq=1 instead of 7! May 14 17:30:18 PeppeRAID kernel: ntfs3(nvme0n1p1): MFT: r=1877, expect seq=36 instead of 2! May 14 17:30:18 PeppeRAID kernel: ntfs3(nvme0n1p1): MFT: r=49, expect seq=32 instead of 31! May 14 17:30:18 PeppeRAID kernel: ntfs3(nvme0n1p1): MFT: r=19de, expect seq=1 instead of 1b! There are filesystem issues with the cache pool, you should not use NTFS with Unraid, Linux support is limited for that. Back up the pool and reformat it with a Linux filesystem.

If xfs_reapir cannot fix the fileystem and you don't have backups, you can try a file recovery app, like UFS explorer, then reformat the disk.

You can do that on Tools - Registartion is a valid TPM device is detected. Yes Yes, same as before. If it's an fTPM, changing the CPU will require a new key, if it's a dedicated TPM module, only changing the board will, BIOS updates are typically not a problem.