gustovier

Yup, was thinking the same thing, and that worked. Did a power cycle and I can see my data once again. I also went ahead and disconnected all other drives completely but let my cache SSD hooked up to the onboard SATA controller, hoping that the bios would pick it for creating HPA, but upon boot up it did not. So now I'm a little worried the bios will pick another data drive or worse Parity drive to install HPA on... I'm about to try plugging back in all my other drives and if everything is good, then only thing left should be to reset Array config and let Parity rebuild. I'm going to need to get a new motherboard... I've had this box for about 10+ years now and never ran into this problem

Sorry. I understood. The drive that I was able to remove HPA from is not using one of the onboard sata controllers (this MB has 2 on board). The other drive where I keep on getting the SG_IO error was already still using the onboard sata controller.

No i took it off onboard sata and put onto my sata add on card. I still can’t figure out how to fix this other drive still with HPA on it. The hdparm command is failing as shown in the previous post. Does anyone have some guidance on how to resolve it? My research has not turned up much

Yeah I saw that post. I have GA-EP35-DS3R motherboard, and from what I can tell I will need to actually downgrade the bios. Of course gigabyte has the bios in some .exe file(assuming self extracting) and of course I'm on a Mac, so gotta figure out a way to extract out the bios. I was able to remove HPA from one of the disks and I can now see all my data. ... the other drive I'm getting this following error... (apparently SD<letter> assignments can change as the impacted drive went from sdb to sdg) root@Tower:~# hdparm -N /dev/sdg /dev/sdg: max sectors = 7814035055/7814037168, HPA is enabled root@Tower:~# hdparm -N p7814037168 /dev/sdg /dev/sdg: setting max visible sectors to 7814037168 (permanent) SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0a 10 51 40 01 21 00 00 00 a0 af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 max sectors = 7814035055/7814037168, HPA is enabled

To add ran these commands, which is really making me think the bios has caused this problem as listed in the message above... As you can see disk sdb and idc have HPA enabled... and these are the 2 disks with the problems.. /dev/sdb: max sectors = 7814035055/7814037168, HPA is enabled root@Tower:/dev# hdparm -N /dev/sdc /dev/sdc: max sectors = 15628051055/15628053168, HPA is enabled root@Tower:/dev# hdparm -N /dev/sdd /dev/sdd: max sectors = 19532873728/19532873728, HPA is disabled root@Tower:/dev# hdparm -N /dev/sde /dev/sde: max sectors = 19532873728/19532873728, HPA is disabled root@Tower:/dev# hdparm -N /dev/sdf /dev/sdf: max sectors = 937703088/937703088, HPA is disabled root@Tower:/dev# hdparm -N /dev/sdg /dev/sdg: max sectors = 11721045168/11721045168, HPA is disabled root@Tower:/dev# hdparm -N /dev/sdh /dev/sdh: max sectors = 19532873728/19532873728, HPA is disabled root@Tower:/dev# hdparm -N /dev/sdi /dev/sdi: max sectors = 11721045168/11721045168, HPA is disabled root@Tower:/dev# hdparm -N /dev/sdj /dev/sdj: max sectors = 19532873728/19532873728, HPA is disabled root@Tower:/dev# hdparm -N /dev/sdk /dev/sdk: max sectors = 19532873728/19532873728, HPA is disabled root@Tower:/dev#

After some sleuthing ... something is telling me I'm being hit by this bug on my rather old gigabyte motherboard I'm using that is incorrectly reseting the drive size on the disks... http://www.users.on.net/~fzabkar/HDD/HDD_Capacity_FAQ.html

How would I repair with GPT so the partition shows up again?

Anyone else have some ideas? Desperate for some help.

The problem is that there is no partition. It’s like they disappeared.

All, Need some big time help. I was trying to repair a drive, replaced a few sata cables and did a few reboots all of a sudden one of my drives (/dev/sdb) showed up as "wrong" although I didn't do anything to it. I then unplugged the data cable to that drive, rebooted. Following another drive (/dev/sdc) showed up as "wrong". I then plugged /dev/sdb sata cable back in and both drives continued to show as "wrong". At this point I figured something was just up with the array config, and I decided to do a "New Configuration" and I preserved all assignments, and restarted the array. Both drives were not seen by the array and I can't even mount them with unassigned drives (it only gives a Format option). I tried doing an XFS_repair, and that went no where root@Tower:/dev# xfs_repair -v /dev/md8 Phase 1 - find and verify superblock... xfs_repair: error - read only 0 of 512 bytes Also tried doing fdisk -L root@Tower:/dev# fdisk -l /dev/sdb Disk /dev/sdb: 3.65 TiB, 4000785948160 bytes, 7814035055 sectors Disk model: WDC WD40EZRZ-00G 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 1 4294967295 4294967295 2T ee GPT I also tried running gdrisk... see below.. But at this point I've decided to not do anything more until advised by the experts here root@Tower:/dev# gdisk /dev/sdb GPT fdisk (gdisk) version 1.0.4 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. **************************************************************************** tower-diagnostics-20210926-2047.zip