Hello, I just upgrade my unraid twice, first from 7.0.0 to 7.10, reboot and success but I set my array to not automatically start but all the disks is recognizeable, so I continue to updated it to 7.12 version, after I reboot , 2 of my disks read wrong disks, I cannot start the array, So I setup new config, with all the same drive and start the array, Then 2 drives unmountable. As can be seen in the pictures both drives are the same as before.
The diagnostics attached,
Thanks

tower-diagnostics-20250522-1500.zip

Edited May 30, 20251 yr by jolma
adding information

Partitions for those disks appear not to be using the whole disk, post the output from:

fdisk -l /dev/sdb and fdisk -l /dev/sde

5 minutes ago, JorgeB said:

Partitions for those disks appear not to be using the whole disk, post the output from:

fdisk -l /dev/sdb and fdisk -l /dev/sde

Here is the output
root@Tower:~# fdisk -l /dev/sdb

Disk /dev/sdb: 9.1 TiB, 10000831348736 bytes, 19532873728 sectors

Disk model: TOSHIBA MG06ACA1

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disklabel type: dos

Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type

/dev/sdb1 64 3907029167 3907029104 1.8T 83 Linux

root@Tower:~# fdisk -l /dev/sde

Disk /dev/sde: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors

Disk model: ST4000VN006-3CW1

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disklabel type: dos

Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type

/dev/sde1 64 3907029167 3907029104 1.8T 83 Linux"

"

Yep, partitions are MBR and only 1.8T, they should be GPT and use the whole disk, with the array stopped copy/paste:

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

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

Then reboot, those disks will again show as wrong, do another new config, and they should then mount.

45 minutes ago, JorgeB said:

Yep, partitions are MBR and only 1.8T, they should be GPT and use the whole disk, with the array stopped copy/paste:

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

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

Then reboot, those disks will again show as wrong, do another new config, and they should then mount.

root@Tower:~# sgdisk -o -a 8 -n 1:32K:0 /dev/sdb

***************************************************************

Found invalid GPT and valid MBR; converting MBR to GPT format

in memory.

***************************************************************

Non-GPT disk; not saving changes. Use -g to override.

root@Tower:~# sgdisk -o -a 8 -n 1:32K:0 /dev/sde

Caution: invalid backup GPT header, but valid main header; regenerating

backup header from main header.

Warning! One or more CRCs don't match. You should repair the disk!

Main header: OK

Backup header: ERROR

Main partition table: OK

Backup partition table: OK

Invalid partition data!

Information: Creating fresh partition table; will override earlier problems!

Warning! Mismatched GPT and MBR partition! MBR partition 1, of type 0x83,

has no corresponding GPT partition! You may continue, but this condition

might cause data loss in the future!

The operation has completed successfully.

This is result of the command, is it okay? to restart?

For sdb you need to override with -g:

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

For sde leave it for now, we can check again after rebooting, and if needed, try to repair the backup header, but creating the new partition should fix it.

5 minutes ago, JorgeB said:

For sdb you need to override with -g:

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

For sde leave it for now, we can check again after rebooting, and if needed, try to repair the backup header.

How to fix backup header for sde?

started the array, Disk 3 still unmountable, diagnostics attached

tower-diagnostics-20250522-1827.zip

Looks like the new partition didn't get created, post again: fdisk -l /dev/sde

2 minutes ago, JorgeB said:

Looks like the new partition didn't get created, post again: fdisk -l /dev/sde

here is the output, Thanks

Yep, it's still the old one, try again with the array stopped:

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

Post the output

14 minutes ago, JorgeB said:

Yep, it's still the old one, try again with the array stopped:

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

Post the output

Here is the result

I restarted and using command -g also didn't work.. the disk 3 is still unmountable.. here is the new diagnostics

tower-diagnostics-20250522-2017.zip

Edited May 22, 20251 yr by jolma
adding new details

It's still not creating the new partition, we can try one more thing, if it doesn't work, you will need to downgrade and rebuild the disk.

Stop the array, type wipefs -a /dev/sde then sgdisk -o -a 8 -n 1:32K:0 /dev/sde one more time, after that post fdisk -l /dev/sde

42 minutes ago, JorgeB said:

It's still not creating the new partition, we can try one more thing, if it doesn't work, you will need to downgrade and rebuild the disk.

Stop the array, type wipefs -a /dev/sde then sgdisk -o -a 8 -n 1:32K:0 /dev/sde one more time, after that post fdisk -l /dev/sde

Here is the new output

reboot then unmount?

Should be good now, reboot and do a new config.

8 minutes ago, JorgeB said:

Should be good now, reboot and do a new config.

All Good, Thank you very much @JorgeB

Trying to summarize
1. After upgrading 2 of my drives unmountable

2. Check using fdisk -l /dev/sdb and fdisk -l /dev/sde, both drives detected 2 TB, real capacity is 10TB and 4TB so next step.

3. Using command from this post

   4 hours ago, JorgeB said:

   Yep, partitions are MBR and only 1.8T, they should be GPT and use the whole disk, with the array stopped copy/paste:

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

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

   Then reboot, those disks will again show as wrong, do another new config, and they should then mount.

4. Check again with step number 2, if didn't work try this post

   3 hours ago, JorgeB said:

   For sdb you need to override with -g:

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

   For sde leave it for now, we can check again after rebooting, and if needed, try to repair the backup header, but creating the new partition should fix it.

5. If the problem still persist then try this step

   1 hour ago, JorgeB said:

   It's still not creating the new partition, we can try one more thing, if it doesn't work, you will need to downgrade and rebuild the disk.

   Stop the array, type wipefs -a /dev/sde then sgdisk -o -a 8 -n 1:32K:0 /dev/sde one more time, after that post fdisk -l /dev/sde

6. if the drives already detected with the real capacity, then do this

   13 minutes ago, JorgeB said:

   Should be good now, reboot and do a new config.

   7. Then all is good :D
      Thank you hope it helps for someone that have the same problem with me

6 minutes ago, jolma said:

Thank you hope it helps for someone that have the same problem with me

It may, but it's always best for people to start a new thread and ask for help, some cases may look similar but not be the same issue, and running commands that were meant for a specific case may cause damage.