The issue you will face if change the HPA now, since those two disks are part of your array, is that they will be detected as different disks since their sizes will have changed when you remove the HPA.

 

That means the partition table will not be correct, and the odds are very high the disk will not even be recognized as being an unRAID formatted disk.  (It will want to reformat those disks, as it will think they are foreign)

 

Whatever you do, do it to only one disk at a time.  That way, the remaining ones can be used to rebuild the one it thinks is foreign.

 

You'll eventuall have to deal with /dev/sde, since it is your parity disk.  You will NEVER be able to add another 2TB disk to your array at full size (without an HPA) since it will be bigger than your parity drive.

 

If you trust your hardware to run without parity for a while, do this

1. Stop the array

2. Save a copy of the config/super.dat file.  It can be used to revert back if needed to the same old config.

3. un-assign the parity drive

4. Start the array with it un-assigned.

5. Stop the array once more. (These two steps will cause the array to forget the model/serial number of the parity disk)

6. Run the hdparm command to see the current HPA on /dev/sde (your parity disk).

hdparm -N /dev/sde

 

7. Run the hdparm command to reset the HPA on /dev/sde (your parity disk) to get it to be full size.

hdparm -N p3907029168 /dev/sde

 

8. Run the hdparm command to see the new HPA has been set to the full size of the drive

hdparm -N /dev/sde

9. Re-assign the parity drive

10. Start the array to allow it to fully calculate parity on the array to the newly resized parity disk.

 

Then, once you have the parity disk handled properly, you can try the same with the data disk. 

Stop the array, un-assign the disk5 data drive  (sdc)

Start the array without it.

Stop the array once more.

This time use this hdparm command to see the current HPA on /dev/sdc (your data disk).

hdparm -N /dev/sdc

 

For the data disk, use this hdparm command to reset the HPA on /dev/sdc (your data disk) to get it to be full size.

hdparm -N p2930277168 /dev/sdc

 

Lastly, use the hdparm command to see the new HPA has been set to the full size of the drive

hdparm -N /dev/sdc

 

Now, assign the re-sized disk to disk5 in the array.

Even though it is the same disk, unRAID will think you are replacing the old (slightly smaller) disk  with the new (without the HPA) disk and re-size the partition for you, and then re-construct the old contents onto it. 

Again, you MUST use the "Start" button to begin the reconstruction process.  DO NOT USE the button labeled as "restore" as it will immediately invalidate parity and forget the un-assigned/re-assigned data drive ever existed.

 

Good Luck.  Those Gigabyte HPAs cause hair loss. 

 

Joe L.

Whew...thanks so much for the detailed instructions, Joe.  Very appreciative of someone who takes other people's data seriously   Not sure if I'll be able to tonight, but hopefully by tomorrow I will follow these instructions to the letter and report back.

 

Thanks again.

Hey Joe,

One last thing to check before I go ahead with the HPA removal stuff you described, these are the results of the hdparm -N commands:

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

/dev/sdc:
max sectors   = 18446744072344859375/11041584, HPA setting seems invalid
root@Tower:~# hdparm -N /dev/sde

/dev/sde:
max sectors   = 18446744073321611375/14715056, HPA setting seems invalid

 

I believe this is what Blade saw when you told him it was effectively the same thing, but I wanted to double check.  For what it's worth, I ran it on some of the other drives (which syslog did not complain had HPA), and saw pretty much the same thing:

 

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

/dev/sda:
max sectors   = 18446744072344861488/11041584, HPA setting seems invalid
root@Tower:~# hdparm -N /dev/sdb

/dev/sdb:
max sectors   = 1465149168/5531376, HPA setting seems invalid
root@Tower:~# hdparm -N /dev/sdd

/dev/sdd:
max sectors   = 18446744072344861488/11041584, HPA setting seems invalid

 

Searching around the forums, I can't find too many other examples of people seeing "HPA setting seems invalid".  Should I go ahead and only perform the hdparm commands to remove the HPA on the disks that unRAID mentions having HPA in the logs?

Searching around the forums, I can't find too many other examples of people seeing "HPA setting seems invalid".  Should I go ahead and only perform the hdparm commands to remove the HPA on the disks that unRAID mentions having HPA in the logs?

It happens on some of my drives... (even though they do not have an HPA)

 

See...

hdparm -N /dev/sdb

 

/dev/sdb:

max sectors  = 18446744072344861488/11041584, HPA setting seems invalid

 

Try it on one drive first.  You'll know if it works when you run the subsequent hdparm -N /dev/sdX command.

Ugh...looks like the hair loss will continue.  After trying it on /dev/sde, I get this:

 

root@Tower:/boot# hdparm -N p3907029168 --yes-i-know-what-i-am-doing /dev/sde

/dev/sde:
setting max visible sectors to 3907029168 (permanent)
SET_MAX_ADDRESS failed: Input/output error
max sectors   = 18446744073321611375/14715056, HPA setting seems invalid

 

Searched around and found another thread http://lime-technology.com/forum/index.php?topic=4239.0 (between you and Blade, no less!) and it looks like I'm going to have to try the 'ultimate boot disk' option mentioned in that thread, as I can't pull the 'swap-the-parity-disk' trick that Blade did.

 

Bummer!  The tinkering continues...

It appears the newer version of unRAID is ignoring the HPA, due to that HPA command you added, and has reset the drive data to the full size of the drive. That's why the drive appears to be the too small when you roll back to the older version or remove that HPA part from the cfg file. So, remove that part again and reboot and then use the "restore" button and see what happens. Once the HPA is recognized by unRAID and the disks are put back to being the size that is available the array should be OK again. The parity appears trashed anyways.

 

I downloaded the http://www.ultimatebootcd.com/  iso and created a disk. I then used the HDAT2 utility to remove the HPA. I can't remember the steps but it wasn't hard to do.

 

I recall trying the commands Joe posted but it wouldn't work.

 

Yes, you can only set the HPA once per power cycle. If the motherboard is still accessing it then you won't be able to get rid of it. My unRAID board is not a Gigabyte but I tried connecting the drive back to my Gigabyte HTPC that it came from and the board kept accessing it on boot. I finally connected a optical drive to the server board and did it there first try.

 

Peter

 

 

 

Finally got around to buying another USB thumb drive so I could get UBCD loaded.  I booted into it and selected the first disk that it detected HPA on, went into 'Set Max Address' and get the following error: "Second non-volatile command after power-on or hardware reset".  Sonnova!  I'm guessing at this point I'm going to need to pull the hard drive out and connect it to another machine to remove the HPA?

Ok!  I was able to boot the machine into UBCD with the parity drive unplugged.  Once UBCD started, I plugged the drive back in and was able to remove the HPA!  Re-assigned the parity disk and then re-sync'd parity and all went well.

 

Joe,

If I repeat this process with the other drives reporting parity, are my woes finally over?  I just read your Gigabyte 'ticking time bomb' comments from another thread and am wondering...is this a permanent solution or will the Gigabyte mobo be waiting in the wings to screw things up?  I'm hoping that the HPA removal will be permanent and I'll no longer have to worry about it...

I believe the error you got was because the motherboard was still accessing the HPA. So, it might just go re-create it again. Make sure the setting is off in the BIOS and check for new HPA's after booting a few times.

 

Other than that, you did fine and you should now repeat with the other disks one at a time.

 

Peter

 

Unfortunately I was unable to find a setting to disable the HPA in the BIOS.  However, after rebooting a few times it has yet to reappear...

Unfortunately I was unable to find a setting to disable the HPA in the BIOS.

However, after rebooting a few times it has yet to reappear...

This motherboard created HPA on your disks once, it will do it again.  Don't kid yourself.

If you can't disable the HPA in the BIOS then you can't use this motherboard with unRAID.

 

Unfortunately I was unable to find a setting to disable the HPA in the BIOS.

However, after rebooting a few times it has yet to reappear...

This motherboard created HPA on your disks once, it will do it again.  Don't kid yourself.

If you can't disable the HPA in the BIOS then you can't use this motherboard with unRAID.

 

I'll add, you are fooling yourself.  If by chance it is detecting the remnants of the HPA, or perhaps it thinks all your drives are formatted, it is lying in wait for your array to suffer a hard disk failure.  Then when it sees the brand new drive it will add one, just when you need it the least. when you are trying to recover from a disk failure, and now the replacement is not big enough.. because of the added HPA.

 

You've got a basic time-bomb on your hands if you are using a Gigabte MB and cannot disable the Bios-Copy to Disk that creates an HPA.  ... it is waiting for a disk failure to show itself and cause you to pull out your hair.  Contact Gigabyte for a BIOS update.  If they have none, let them know the board will be replaced with one of their competitors.

Thanks for all the help, guys.

 

I've done a bit more research and found that my board has a 'Xpress Recovery2' feature which basically causes the HPA.  I've tried digging into it to see if I could disable it, but the software claims that it isn't installed to begin with (I tried setting up a backup to see if it would let me set a zero size or something).  I'm going to try and call Gigabyte to confirm that it can be disabled and any instructions on how to do so so I can be sure.

 

Man, what a pain.

I'm going to try and call Gigabyte to confirm that it can be disabled and any instructions on how to do so

Finding a way to disable it is NOT what you want!

What you want is a BIOS in which that "feature" is disabled by default.

Otherwise, when your CMOS battery dies, the mobo will revert to its default settings, and you will be screwed.

 

Well, I recently bought a new 2TB disk and installed it without any problems.  I feel somewhat confident that the board would continue to work, but, all the warnings here definitely make me nervous.  After reading through the Supermicro X7SPA L/H/HF ATOM serverboards (Level 1 Tested) thread, I got pretty excited about the board and I ordered it today, so I think it'll all work out.  I'll take the gigabyte board and throw it in one of my desktops.

 

It's a shame...the gigabyte board has been good to me for quite some time (and hopefully will continue)...I wish they were more friendly about disabling HPA...