Date: Tue, 20 May 2014 13:17:32 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: freebsd-geom@freebsd.org Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Message-ID: <38378.1400617052@server1.tristatelogic.com> In-Reply-To: <20140520185935.GS43976@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20140520185935.GS43976@funkthat.com>, John-Mark Gurney <jmg@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. 1) HDDErase. This is a DOS-based tool which is provided either as a stand-alone DOS .EXE file or as a CD image (.ISO). I've used this is the past with great success, but it stopped being supported or updated in 2008, and I haven't used in in so long that I can't even figure out how to make the bootable CD image work anymore... and in fact it doesn't seem to work at all on my 2 main systems here. In short, this is a dead end. (However people more clever than me could probably still get it to work, even on newer motherboards.) 2) There is a commercial program called "Parted Magic" which also allegedly has a capability to perform the ATA "secure erase" operation, but the version that I have of this... which is integrated into the free "Ultimate Boot CD".. doesn't seem to actually have this working. When I tried to use this feature, no matter what drive I had installed the thing just kept telling me that the drive didn't support the feature. And I tried several different drives. (Perhaps I just need a updated copy of UBCD or else I need to pay for the commercial version of Parted Magic, although I'm not sure either of those would help any, quite frankly.) 3) There is also the standard Linux program called "hdparm" which has a special -N option for dealing with these kinds of problems. Using -N with no options is supposed to show you the supposed current capacity of the drive and then also the actual physical size of the drive. And then you can re-invoke "hdparm -N' with an argument for the -N option which will cause the supposed current capacity of the drive to be set to anything you want. But when I ran the program (which fortunately is accessible from within a shell window in the Gparted LiveCD) it told me that the logical and physical sector counts for my goofed up drive were exactly the same! So I'm suspicious that this doesn't work right either. The good news is that if anybody figures out how to make this work properly, then, in theory, one should be able to reset the drive capacity to the real capacity *without* having to do a "secure erase" operation, which can take up to several hours for a large drive. 4) Finally, there is a free program out there called HDAT2 which seems to me to be dedicated to dealing with low-level disk issues exactly like this. It has built-in functionality to entirely remove either a Host Protected Area (HPA) or a Device Configuration Overlay (DCO) or both from a drive. I seem to be having some trouble getting that to work right just now, but that may be because I've been (foolishly) trying to use it on the same *&^%$#@ bloody Gigabyte-based system that caused the bleedin' problem in the first place. Sigh. I'll have to take down my main server in order to try running HDAT2 again, on that system, and against the specific corrupted 1TB drive that, for the moment, still remains all goofed up. (Note that HDAT2 is also an option that does not necessitate performing a time consuming "secure erase" operation on the drive.) In short, of all of the above options for getting the drive un-hosed, HDAT2 appears the most promising at the present time, but I need to investigate further. And I don't have time for that at the moment. 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... Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38378.1400617052>