Hi,

I upgraded from 7.0.1 to 7.3.3 and 7 of my 10 array disks were flagged "wrong" (DISK_WRONG). When I downgraded to 7.0.1 everything was back to normal. I did not run New Config, format, or re-assign anything, and the data is intact on 7.0.1. I would like to upgrade safely and want to understand why this happens.

Diagnostics from both versions are attached (7.3.3 taken right after the upgrade, 7.0.1 after downgrading).

Hardware: LSI/Broadcom SAS2116 (9201-16e) HBA, driver mpt3sas in both versions. All 15 devices show up with the same serials and sizes in both versions, no controller/cable errors in the syslog.

What I see in the 7.3.3 syslog:

md: import disk1: (sda) ST20000NM007D-3DJ103_ZVT5JQD8 size: 19531823104
md: import_slot: 1 wrong
md: import_slot: 2 wrong
md: import_slot: 4 wrong
md: import_slot: 5 wrong
md: import_slot: 6 wrong
md: import_slot: 8 wrong
md: import_slot: 9 wrong

The disks marked wrong all report a data partition starting at sector 2048:

emhttpd: online: ST20000NM007D-3DJ103_ZVT5JQD8 (sda) ... gpt start: 2048 size: 19531823104
emhttpd: online: ST10000NM0016-1TT101_ZA28V9NB (sdj) ... gpt start: 2048 size: 9766434816
(same for WD60EFRX, 3x ST4000NE0025, disk2)

The disks that are accepted (parity, disk3, disk7, disk10) have a partition starting at sector 64:

emhttpd: online: ST20000NM007D-3DJ103_ZVT5KC0A (sde) ... gpt start: 64 size: 19531825100

On 7.0.1 all of these are imported with start 64 and the stored size, for example:

mdcmd (2): import 1 sdb 64 19531825100 0 ST20000NM007D-3DJ103_ZVT5JQD8
md: import disk1: (sdb) ... size: 19531825100

So the stored size for disk1 is 19531825100, but 7.3.3 sees 19531823104 and calls the slot wrong. Same pattern on the other six.

Questions:
1. Is this a known change in how 7.3.x validates the partition start/size of array disks? Is it expected?
2. What is the supported way to upgrade to 7.3.x with these disks without losing data or parity? For example, is there a setting, or do the disks need to be rebuilt one at a time?
3. Is there anything I should check or back up before trying again?

Thanks!

7-0-1.zip 7-3-3.zip

My reading of your diagnostics (a hypothesis, but I reproduced it on a 7.3.2 test server):

7.0.1 imports those disks with start 64 and the size from super.dat, and md1p1 gets exactly that size, so your data sits at sector 64. 7.3.3 is the first version that reads the partition table of a known disk on every start, and on those seven disks the GPT says the partition starts at 2048 with a non-standard end. Start and size don't match super.dat, so md flags the slot "wrong". That is a safety net: with the 2048 partition, md1p1 would begin 1 MiB after your file system. Unraid doesn't write such a layout itself, so something else probably rewrote those tables at some point.

Please don't run New Config on 7.3.3, don't accept a disk as a replacement, and don't format anything.

Verify on 7.0.1 (read-only) for one wrong disk and one good one:

sgdisk -p /dev/sdX
dd if=/dev/sdX bs=512 skip=64 count=1 2>/dev/null | od -c | head -1

Expected on a wrong disk: partition at 2048, but "X F S B" at sector 64. Please post the outputs.

If that matches, the fix is to rewrite only the partition table, with the array stopped, per affected disk (only the seven flagged "wrong"; check the serial behind each sdX on Main first, never the cache SSDs or the flash drive):

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

That is the command emhttpd itself uses for disks over 2 TB (partition from sector 64 to the last usable sector). It doesn't touch anything from sector 64 onwards, and for your 20 TB disks the resulting size is 19531825100, exactly what super.dat holds. Then start the array on 7.0.1, run a parity check, and upgrade. On my test server this brought the disk back with unchanged checksums and 0 parity errors. Backups first, as always.

The disks have a partition starting on sector 2048, but it's not a valid Unraid partition, meaning it's not using the entire disk. Because of this, previous Unraid versions are ignoring that and just using the disks as if they had a standard 64-sector starting partition. Newer Unraid release now always use the actual partition; the solution is creating a standard partition layout for all the affected disks, like mentioned above.

While still on 7.0.1, run sgdisk -o -a 8 -n 1:32K:0 /dev/sdX for every affected disk, then upgrade to 7.3 and reboot; the array should start normally.