JorgeB

That looks like a bad flash drive, you can try recreating it first, if the issues persist, best to replace it.

Yep

Make sure this has been taken care of: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

There's a problem with the flash drive layout, 7.3.x is more strict about that.

To fix it, first backup the current flash drive, then recreate it using the USB tool, restore only the /config folder from the backup overwriting any existing files.

Diags only have a no-correcting check, reboot to clear the logs, run a correcting check, then another one (correct or non correct) right after and without rebooting.

I assume these are the pool members? And they are all from the same pool?

/dev/nvme0n1p1: UUID="299134d5-d2d5-41d9-9bfa-3e98d1e3f1d5" TYPE="crypto_LUKS" PARTUUID="e414749a-01"
/dev/nvme2n1p1: UUID="8416d39f-e189-42e1-a1b8-956a23215ce8" TYPE="crypto_LUKS" PARTUUID="b660afb9-01"
/dev/nvme3n1p1: UUID="2d3fcb77-83de-48a1-b4c2-11d4fe5ba331" TYPE="crypto_LUKS" PARTUUID="0262e045-35e3-48a5-8af5-47f862bab439"
/dev/nvme4n1p1: UUID="b2d6b8d5-d4db-4938-a66b-907cd3ffa1ee" TYPE="crypto_LUKS" PARTUUID="d8fe2adb-7f6b-4fbc-9866-3daf82e56b31"

If yes, on main, create a new pool with the name you like and 4 slots
assign the pool devices, leave the filesystem set to auto
It should ask for the encryption key/passphrase, then start the array to import the pool

If it fails to mount, post the diags with the array started

Note as far as I know, only root has SSH access.

RAM is overclocked, start here: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/#findComment-819173

I don't think so, to rule out a FM issue, try using Mindnight COmmender (mc on the console).

Macvlan is no longer an issue since 6.12.11, kernel panics should always show in the syslog.

This would be my main suspect, since it's one of the more affected models by the Intel 13/14 gen issues, lot of users with stability issues with this and similar CPUs, look for a BIOS updatye, it can sometimes help if the CPU is not too far gone.

Don't see those erros logged, there is a container running out of RAM, something related to Bambu.

Type reboot in the CLI and see if it reboot after 5 minutes, if not you may need to force it.

When using the CLI you must use the correct md device, but if the result above was from the GUI, the filesystem appears to be damaged beyond repair, best bet is to use a file recovery app like UFS explorer, the free trial should show if it can recover the data.

Flash drive problem, 7.3.x is more strict witht he flash drive partition layout, easiest way to fix is to backup the flash drive, recreate it with the USB tool and 7.3.1, restore only the config folder from the backup.

You should be able to remove it by hovering the mouse on the top-right corner of that server's card, then clicking "customize"

Does it boot with a different PC?

It amy also be worth trying with the Limine boot loader, in case the BIOS os not cmpatible with the stock one https://forums.unraid.net/topic/196349-black-screen-after-usb-boot-msi-x870e-carbon-ryzen-9950x-rtx-4070-ti-super/?do=findComment&comment=1607672

You should never use those, a SATA plug should never be split into more than two max.

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

Delete /boot/config/pools/cache.cfg on the flash drive, reboot and the GUI should be back, you will need to reimport the pool, can post the steps for that if you need them.

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.

Sounds good, you can also keep all the assignments when doing the new config, the missing disks won't show

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

Rename the libvirt.img to, for example, libvirt.bak, and Unraid should create a new one after the service starts.

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.

Parity disk doesn't have a partition; open a terminal window and type

sgdisk -o -a 8 -n 1:32K:0 /dev/sdX

Replace X with the correct parity identifier, sdg from the diags, but this can change if you reboot.

After that, reboot the server and see if it now works.