GEOM_PART: Integrity check failed (ada2, MBR)

[John-Mark Gurney]

Ronald F. Guilmette wrote this message on Tue, May 20, 2014 at 13:17 -0700:
> 
> In message <20140520185935.GS43976 at funkthat.com>, 
> John-Mark Gurney <jmg at funkthat.com> wrote:
> 
> >Ronald F. Guilmette wrote this message on Sat, May 17, 2014 at 17:00 -0700:
> >> I had forgotten all about this, until now, but there is apparently a
> >> known problem where older (pre-2010) Gigabyte motherboards will in
> >> fact create a Host Protected Area (HPA) on the ``first'' ATA drive
> >> in a given system, *and* that in cases where the drive is 1TB or larger,
> >> the result will be a drive that self-identifies as being only 31 (or 32)
> >> megabytes big.  (You can google for this known problem and you'll find a
> >> _lot_ of references to it.)
> >> ...
> >
> >Wow, this is sooo BAD...
> 
> Yes.  It is.  Perfectly awful behavior.
> 
> >Motherboards should never touch a HD like
> >this w/o consent from the user...
> 
> I can only agree.
> 
> >but this does sound like your issue though, glad you found it...
> >
> >And this is useful info for others too, Thanks.
> 
> Here is some more useful info for others who find themselves faced
> with this problem, and who struggle, as I have, to try to get the
> affected/afflicted drive back to normal...
> 
> There are a number of tools out there which claim to provide some
> assistance in dealing with this specific problem, but some of them
> are actually appearing to me to be non-useful at the present time.
> 
> The first two of these, listed below, can, in theory, correct the problem
> by performing what's called a "secure erase" operation on the drive.
> This is a special feature of some (most?) newer vintage pATA and sATA
> drives.  They have a built-in special ATA "secure erase" command which,
> I gather, when it can be made to work, should... as a side effect...
> also set the drive capacity back to equal the actual physical capacity.

[...]

> I wanted to post all of the above info for the benefit of others who,
> like me, get bitten by this sort of problem and then... as I have...
> spend hours and hours googling and flailing around, looking for a way
> to just simply get the drive back to normal.
> 
> I still haven't succeeded at that, but neither have I given up.  And
> I won't, because I have no intention of throwing an otherwise perfectly
> good and near-new 1TB drive into the trash.  I'm gonna fix that drive,
> come hell or high water.  I just need to find the time...

Have you tried camcontrol on FreeBSD-HEAD... It may also be in 10.0-R,
as the manpage for camcontrol has it too:
     hpa         Update or report Host Protected Area details.  By default
                 camcontrol will print out the HPA support and associated set-
                 tings of the device.  The hpa command takes several optional
                 arguments:

https://www.freebsd.org/cgi/man.cgi?query=camcontrol&manpath=FreeBSD+10.0-RELEASE

There are memstick images to make testing this out easier...

It also looks like camcontrol has the option to do the secure erase
you were talking about...

If the bios does some of this, it may be easiest to hot plug the drive
so the BIOS never gets a chance to touch it before you run the
commands...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."