15 hours ago, trurl said:

why that first photo you posted yesterday said disk3 was wrong since it is displaying the same serial number. I am guessing it got moved to another port

If it were moved to another port and that changed its mode IDE/AHCI could that explain it?

1 hour ago, trurl said:

If it were moved to another port and that changed its mode IDE/AHCI could that explain it?

That should never change the disk capacity, a RAID controller could, but that wasn't the case.

What about the old 2.2TB limit for some old controllers? Can you tell what the capacity changed to? Could that affect some ports and not others?

It must have been a minimal difference, if the disk was being detected as 2.2T it would be visible here:

 

8 hours ago, JorgeB said:

The other question, is how was this resolved, next screenshot shows the array started with that disk but unmountable.

What I did was I did a new config for the sever. I had read somewhere that when adding new drive you had to do that so thats why the server was able to start again.

 

New Config is not the normal way to add disks, but as long as you didn't need to recover any data probably didn't hurt anything. 

 

Are all disks mountable now? 

 

34 minutes ago, trurl said:

Are all disks mountable now? 

no thats the whole issue, the two drives are not mountable even though I changed nothing with them

1 hour ago, Smoketrain said:

What I did was I did a new config for the sever.

Probably not the best option in this case, you should have posted those diags, but it still may be recoverable, pretty sure this is the problem:

 

Mar 26 17:09:16 Tower kernel: ata5.00: HPA detected: current 19532871615, native 19532873728

Mar 26 17:09:16 Tower kernel: ata6.00: HPA detected: current 7814035055, native 7814037168

 

See below for how to disable the BIOS backups function in your board that creates the HPA, and how to remove them from the disks, when that is corrected you will then need to do another new config, and hopefully both disks will mount again, and they should:

 

 

27 minutes ago, JorgeB said:

you will then need to do another new config

P.S: In case you are not aware, doing a new config will stop emulating the disabled disk2, but looks like it's empty anyway.

I was just checking the HPA link you gave us, that works fine, but the actual removal guide links for the HPA does not work anymore. Im just going to throw this out there but we have a Gigabybye GA-EX58-UD5P motherboard and we checked and we could not find an HPA setting in the bios, We are running original firmware. There is new firmware that we are upgrading to in order to see if that fixes things.

Update: We did update the bios and we did find in the updated setting the place to turn off HPA (Bios to HDD). We verified that it is disabled. We then started up unraid and the 2 drives were still unmounted. Attached are the latest diagnostics.

tower-diagnostics-20250327-2212.zip tower-diagnostics-20250327-2212.zip

Disabling HPA in the BIOS is only so that it doesn't get created on new/same disks, it won't remove the current ones, to confirm the disks with the issue post the output from:

 

hdparm -N /dev/sdc

and

hdparm -N /dev/sdd

 

And then don't reboot for now.

HPA kept me away from Gigibyte until they realized this was a bad idea.

here is the output

It would be easier if you had copy/pasted, you will need to type the exact number, or copy past from the terminal, it's the 2nd number, the larger one

 

hdparm -N p195..728 /dev/sdc

and

hdparm -N p781..168 /dev/sdd

 

Then again output from:

hdparm -N /dev/sdc

and

hdparm -N /dev/sdd

 

root@Tower:~# hdparm -N /dev/sdc

/dev/sdc:
 max sectors   = 19532871615/19532873728, HPA is enabled
root@Tower:~# hdparm -N /dev/sdd

/dev/sdd:
 max sectors   = 7814035055/7814037168, HPA is enabled

Sorry about that, so you want me to do the commands

hdparm -N p19532873728 /dev/sdc

and

hdparm -N p7814037168 /dev/sdd

Are you saying that doing these commands will remove the HPA partition and then by doing the other commands again, we will see if the HPA partition has been removed?

Correct.

root@Tower:~# hdparm -N p19532873728 /dev/sdc

/dev/sdc:
 setting max visible sectors to 19532873728 (permanent)
 max sectors   = 19532873728/19532873728, HPA is disabled
root@Tower:~# hdparm -N p7814037168 /dev/sdd

/dev/sdd:
 setting max visible sectors to 7814037168 (permanent)
 max sectors   = 7814037168/7814037168, HPA is disabled
root@Tower:~# hdparm -N /dev/sdc

/dev/sdc:
 max sectors   = 19532873728/19532873728, HPA is disabled
root@Tower:~# hdparm -N /dev/sdd

/dev/sdd:
 max sectors   = 7814037168/7814037168, HPA is disabled

 

Now refresh the GUI, and both disks should show as wrong, you can do a new config again, but note that you will lose the emulated disk2, so make sure it's still empty:

 

Post new diags with the array started.

tower-diagnostics-20250328-1407.zip

It's still trying to access beyond the end of the device, possibly the partition is still not resized to max or damaged

 

Mar 28 13:54:51 Tower kernel: mount: attempt to access beyond end of device
Mar 28 13:54:51 Tower kernel: md3p1: rw=4096, sector=19532873623, nr_sectors = 1 limit=19532871512

 

Post output from 

 

gdisk /dev/sdc

 

root@Tower:~# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.10

Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
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: ERROR

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Command (? for help): 

 

That confirms the partition is damaged, you can try creating a new partition with the standard Unraid layout and the correct size, this should be fairly safe, but there's always some risk, and cannot guarantee it will work, if you have a spare disk, you can clone it with dd first, then try it on the clone:

 

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

 

After that do a new config again, just to make sure the new layout is loaded, or just see if it mounts with the UD plugin in read only mode.