JorgeB

Looks good, and the data on disk 7 should all be fine, since it was a partition issue, not the filesystem. If you are happy with the emulated disk9 contents, the main thing left is to rebuild it.

And did it mount correctly after array start?

The partition still isn't correct; do this, first, wipe the existing one (this won't wipe the data) wipefs -a /dev/sde then again sgdisk -o -a 8 -n 1:32K:0 /dev/sde You shouldn't see any errors this time; if so, reboot again.

If a different flash drive using a stock install still does' boot, it suggests some incompatibility between the newer kernel and the hardware. My suggestion would be to remain on 7.2.x for now and retest once a release with a newer kernel is out.

2026-06-27T17:42:28-07:00 ZimaCube kernel: usb 2-1.3: USB disconnect, device number 3 2026-06-27T17:42:28-07:00 ZimaCube kernel: device offline error, dev sda, sector 11716424 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 2026-06-27T17:42:28-07:00 ZimaCube kernel: I/O error, dev loop0, sector 115904 op 0x0:(READ) flags 0x800 phys_seg 4 prio class 2 2026-06-27T17:42:28-07:00 ZimaCube kernel: SQUASHFS error: Failed to read block 0x38936dd: -5 2026-06-27T17:42:28-07:00 ZimaCube kernel: device offline error, dev sda, sector 11697752 op 0x0:(READ) flags 0x80700 phys_seg 10 prio class 2 2026-06-27T17:42:28-07:00 ZimaCube kernel: device offline error, dev sda, sector 11697752 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 2026-06-27T17:42:28-07:00 ZimaCube kernel: device offline error, dev sda, sector 11715032 op 0x0:(READ) flags 0x80700 phys_seg 12 prio class 2 2026-06-27T17:42:28-07:00 ZimaCube kernel: device offline error, dev sda, sector 11715032 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 2026-06-27T17:42:28-07:00 ZimaCube kernel: device offline error, dev sda, sector 12924448 op 0x0:(READ) flags 0x80700 phys_seg 10 prio class 2 Flash drive is dropping offline, you can first try using a different USB port and/or recreating the flash drive, if the issue persists, replace it.

Post a photo/video showing at what point it reboots, you can also try booting with a different flash drive using a stock install; no key needed, just to see if that boots.

Try booting with a different flash drive using a stock install, no key needed, just to see if it boots.

That's an MBR partition, only using 2TB for an 8TB disk. With the array stopped type: sgdisk -o -a 8 -n 1:32K:0 /dev/sde Then reboot and see if that disk no longer shows as wrong, if it doesn't start the array and post new diags.

There have been other reports with those NICs and performance issues in one direction, see if this helps: https://forums.unraid.net/topic/123594-poor-ssd-cache-read-speed-25gbe/

It will never wotk with those 3 partitions; you can try Rufus if the USB tool is not working (though not sure why that is) Get the Unraid zip from https://docs.unraid.net/unraid-os/download_list/ - Open Rufus and change "Boot selection" to "Freedos" - Set the "Volume label" to UNRAID - set filesystem to FAT32 - click START - once done, unpack the Unraid ZIP to the flash drive If you are booting UEFI nothing else you need to do, if you are booting legacy/CSM, run the make_bootable.bat as administrator first.

Test must be made between a client and the server, a loop test is not really worth anything.

Why not just relogin using the correct account?

Run an iperf test between both PCs to confirm the LAN is all working at 2.5GbE

It will never work with the flash drive being detected without partitions; that should not happen if it was recreated with the USB tool. Post the output from fdisk -l /dev/sdn

Not sure what you mean; the link was up for many hours.

If you are logged in with a different account, you cannot use the same trial; you must use the same account that was used to create the trial.

That suggests a problem with the flash drive, enable the syslog server and set it to save to a share, then post that after it happens again.

Jun 13 14:26:47 DockOfTheBay kernel: i40e 0000:b5:00.3 eth5: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None Jun 13 14:26:47 DockOfTheBay kernel: i40e 0000:b5:00.3: Added LAN device PF3 bus=0xb5 dev=0x00 func=0x03 Jun 13 14:26:47 DockOfTheBay kernel: i40e 0000:b5:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 8 RSS FD_ATR FD_SB NTUPLE VxLAN Geneve PTP VEPA Jun 14 13:32:52 DockOfTheBay kernel: i40e 0000:b5:00.3 eth5: NIC Link is Down Jun 14 13:33:32 DockOfTheBay kernel: i40e 0000:b5:00.3 eth5: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None Jun 14 15:15:46 DockOfTheBay kernel: i40e 0000:b5:00.3 eth5: NIC Link is Down Jun 14 15:15:54 DockOfTheBay kernel: i40e 0000:b5:00.3 eth5: NIC Link is Up, 10 Gbps Full Duplex, Flow Control: None Jun 24 18:06:44 DockOfTheBay kernel: i40e 0000:b5:00.3 eth5: NIC Link is Down Link is initially up, but then it keeps going up and down.

That log is over 1GB, I'm sorry, but not even trying to open that. Get just the syslog or start a new persistent log syslog server just for the last boot, also try to stop all the extra spam

Jun 28 11:02:09 Plex emhttpd: /mnt/disk7 mount error: Unsupported partition layout Disk is not mounting due to the partition; the filesystem should be OK, with the array stopped post the output from: fdisk -l /dev/sdh

If it starts with 01- it's TPM, if it starts with a XXX-XXXX format, it's the flash drive, the latter should allow downgrading.

I'm unable to reproduce, see if you can repro the issue (using test data) with a couple of the folders with the same or similar names as you had before.

Possibly it was using the TPM for the GUID, and if that's the case, it's not supported by 7.2, you could start a new trial with 7.2.

The server is not getting an IP from the DHCP server, typically your router. Post the diagnostics to see if there's something more visible.

The first thing you will need to resolve are the hardware errors: Jun 28 10:42:47 TicK-Unraid kernel: mce: [Hardware Error]: Machine check events logged Jun 28 10:42:47 TicK-Unraid mcelog: CPU 0 on socket 0 received Bus and Interconnect Errors in Other-transaction Jun 28 10:42:47 TicK-Unraid mcelog: Location: CPU 0 on socket 0 This is most likely a CPU or board problem.