Unraid 7.2.4. I'm stuck getting a disabled array disk to rebuild, and I'd appreciate a sanity check before I do anything that might risk parity.

***The system was migrated from an OpenMediaVault setup previously which is why the format of the drives is EXT4. I did this to preserve the data that was on the drives for the migration.*** - EDIT

Sequence of events:

1. Disk 1 (Toshiba HDWG21E, 14TB) became disabled (red X, contents emulated). Root cause was the drive briefly dropping off my LSI HBA - kernel showed device_block then mpt3sas_transport_port_remove, and it re-enumerated as a new device. So a connection/transport event, not a media failure.

2. I confirmed the drive is healthy: SMART PASSED, 0 reallocated / 0 pending / 0 offline-uncorrectable / 0 CRC, and a full extended SMART self-test completed without error.

3. I powered down and reseated the HBA, cables and card. Clean boot afterward - all disks present, no mpt2sas errors, Disk 1 correctly assigned and showing disabled/emulated, parity green.

4. Starting the array did not trigger a rebuild (Disk 1 stayed disabled, no rebuild prompt).

5. I then stopped the array, set Disk 1 to "No device", started (Disk 1 now missing/emulated), stopped, and reassigned the same Toshiba to Disk 1.

6. Now the array won't start: "Stopped. Disk in parity slot is not biggest."

The disks are the same size. fdisk -l shows both at exactly 14000519643136 bytes:

• Parity = WD Ultrastar WUH721414AL4204 (sde): 3,418,095,616 sectors × 4096-byte sectors

• Disk 1 = Toshiba HDWG21E (sdh): 27,344,764,928 sectors × 512-byte sectors

Different sector sizes, identical byte capacity. They coexisted fine for weeks before this — the error only appeared after the unassign/reassign of Disk 1.

HPA check is inconclusive on the parity disk. All my array drives are behind an LSI SAS2008 HBA (mpt2sas). hdparm -N:

• sdh (Toshiba): max sectors = 27344764928/27344764928, HPA is disabled - clean.

• sde (WD parity): SG_IO: bad/missing sense data and max sectors = 0/513, HPA is enabled- which looks like hdparm failing to query through the HBA rather than a real HPA.

Questions:

1. Is my parity still valid here, and is the emulated Disk 1 data safe?

2. What's the correct way to get Disk 1 rebuilding without risking parity? (I have not touched New Config or moved any disk into the parity slot.)

3. Is the "not biggest" being caused by the unassign/reassign rather than a real size/HPA issue, and if so how do I clear it safely?

Diagnostics attached. Thanks - I'd rather get this confirmed than guess with parity involved.

motherboard (MSI PRO B760M-P DDR4), CPU (i3-12100), the LSI SAS2008 HBA, and the array drives are all behind that HBA

pingunas-diagnostics-20260606-0858.zip

Edited June 16Jun 16 by fatp1ngu
Added some details of the system to the bottom. Added about OMV Migration. Re-opened

According to the syslog in the diagnostics the new disk1 is slightly larger than the parity!

Jun 6 08:55:19 PinguNAS kernel: mdcmd (1): import 0 sde 2048 13672381420 0 WUH721414AL4204_9JHKS0LT_35000cca25858a0e4

Jun 6 08:55:19 PinguNAS kernel: md: import disk0: (sde) WUH721414AL4204_9JHKS0LT_35000cca25858a0e4 size: 13672381420

Jun 6 08:55:19 PinguNAS kernel: mdcmd (3): import 1 sdh 64 13672382412 0 TOSHIBA_HDWG21E_93L0A09TFP7G

Jun 6 08:55:19 PinguNAS kernel: md: import disk1: (sdh) TOSHIBA_HDWG21E_93L0A09TFP7G size: 13672382412

This is probably caused by the fact that the new disk1 has an existing partition starting at offset 64 whereas the others start at 2048. @JorgeB can probably tell you the best way to resolve this.

I also notice that many of them seem to be formatted as ext4 rather than one of the standard Unraid formats such as xfs. Were they previously used in a Linux system and therir existing partitions not erased before using them in Unraid?

2 hours ago, itimpi said:

According to the syslog in the diagnostics the new disk1 is slightly larger than the parity!

Jun 6 08:55:19 PinguNAS kernel: mdcmd (1): import 0 sde 2048 13672381420 0 WUH721414AL4204_9JHKS0LT_35000cca25858a0e4

Jun 6 08:55:19 PinguNAS kernel: md: import disk0: (sde) WUH721414AL4204_9JHKS0LT_35000cca25858a0e4 size: 13672381420

Jun 6 08:55:19 PinguNAS kernel: mdcmd (3): import 1 sdh 64 13672382412 0 TOSHIBA_HDWG21E_93L0A09TFP7G

Jun 6 08:55:19 PinguNAS kernel: md: import disk1: (sdh) TOSHIBA_HDWG21E_93L0A09TFP7G size: 13672382412

This is probably caused by the fact that the new disk1 has an existing partition starting at offset 64 whereas the others start at 2048. @JorgeB can probably tell you the best way to resolve this.

I also notice that many of them seem to be formatted as ext4 rather than one of the standard Unraid formats such as xfs. Were they previously used in a Linux system and therir existing partitions not erased before using them in Unraid?

Correct - all these disks were migrated from OpenMediaVault (OMV 7) with their existing ext4 filesystems and partitions kept intact, rather than being freshly partitioned in Unraid. So Disk 1's sector-64 partition offset is a leftover from its prior Linux setup. Given that, what's the safe way to rebuild Disk 1 with a standard partition while preserving the emulated data via parity? And can you confirm parity is valid so the rebuild restores the contents?

6 hours ago, fatp1ngu said:

stopped the array, set Disk 1 to "No device", started (Disk 1 now missing/emulated)

At that point, the (emulated) disk contents should be accessible for reading (and even writing), assuming it is a mountable filesystem.

Thanks - I've started the array with Disk 1 unassigned/emulated for now so I have access. For the permanent fix: hoping there is a safe procedure to rebuild Disk 1 back into the array with a standard 2048-aligned partition, and a way to confirm my parity is valid so the rebuild restores the emulated contents intact?

If no one comes up with a way to rebuild disk1 with a 2048 start sector then the Parity Swap procedure could be used to get the disk with a 64 start sector in as parity and the old parity replacing disk1.

Unraid 7.2.x will automatically create a 2048 starting partition for the rebuilt disk if one of the parity devices is the same size and is also using a 1MiB aligned partition, I think the issue here may be the fact that parity is 4Kn, I never tested in that scenario. I will make some tests to confirm, hopefully today if I have the time.

7 minutes ago, JorgeB said:

Unraid 7.2.x will automatically create a 2048 starting partition for the rebuilt disk if one of the parity devices is the same size and is also using a 1MiB aligned partition, I think the issue here may be the fact that parity is 4Kn, I never tested in that scenario. I will make some tests to confirm, hopefully today if I have the time.

Thank you very much. I really appreciate any help / support that you are able to give.

I did a quick test and confirmed the 4Kn parity is indeed the issue.

It still works if the replacement disk is also 4Kn, in case you have one available, the other option would be doing a parity swap.

I'll raise this with LT, it should be a pretty rare occurrence, but if it's an easy fix, it would be worth doing it, IMO.

3 hours ago, JorgeB said:

I did a quick test and confirmed the 4Kn parity is indeed the issue.

It still works if the replacement disk is also 4Kn, in case you have one available, the other option would be doing a parity swap.

I'll raise this with LT, it should be a pretty rare occurrence, but if it's an easy fix, it would be worth doing it, IMO.

Thanks for testing that - really appreciate it. I don't have a spare 4Kn disk, so the Parity Swap looks like my route. Before I start: anything specific about the Parity Swap procedure I should watch for given the 4Kn parity, or is it the standard flow in the docs?

Thanks again for all your efforts!

It should be the standard procedure, for that the 4Kn parity should not change anything.

On 6/8/2026 at 7:23 AM, JorgeB said:

It should be the standard procedure, for that the 4Kn parity should not change anything.

I set up the parity swap exactly as advised - Toshiba (the sector-64 disk) TFP7G to the Parity slot, old WD parity S0LT to Disk 1, all other disks unchanged. But no "Copy" button appears. The Parity row shows the Toshiba on top with the old WD serial underneath labelled "Wrong," and the array still says "Disk in parity slot is not biggest." So the swap isn't being recognised / the size check is still blocking. What am I missing - is the Toshiba's sector-64 partition also defeating the check in the parity slot?

I started the array again with WD parity S0LT in Parity Slot 1 and Toshiba unassigned, then stopped array again and tried the steps as described (remove Unassign WD Parity drive, Set Toshiba to Parity Slot, Set WD to Disk 1) but there is again no copy showing. It just says 'Disk in parity slot is not the biggest' again.

Appreciate any help

Post new diags with the disks assigned for the parity swap.

Diagnostics attached

pingunas-diagnostics-20260616-1333.zip

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.

New Config worked so I have done this to get the Array back up and the Parity Check is running.

Thank you for all your support

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.