[mythtvnz] HPA - more information

[Nick Rout]

On Fri, Mar 14, 2014 at 2:39 PM, Stephen Worthington
<stephen_agent at jsw.gen.nz> wrote:
> On Fri, 14 Mar 2014 10:04:28 +1300, you wrote:
>
>>ok - I've done some more reading of HPA and know a little more about how it
>>works.  As usual, Wikipedia is pretty good:
>>    http://en.wikipedia.org/wiki/Host_protected_area
>>
>>The OS is perfectly capable of detecting when HPA is in use - indeed the
>>dmesg log will indicate if HPA is enabled for any particular drive.  Also
>>[sudo hdparm -N /dev/sdX] will give details.
>>
>>The problem with Gigabyte motherboards is that on startup, they apparently
>>look at the first disk initialised (not necessily the disk on the first
>>port) to see if a copy of the BIOS is saved on the end of the disk.  If
>>not, then the BIOS will enable HPA, steal the last few megabytes of the
>>disk, and overwrite it with a copy of the BIOS.  This is obviously bad and
>>could very easily corrupt any existing the filesystem on that disk.
>>
>>Apparently newer Gigabyte motherboards have this feature disabled by
>>default.  As mentioned in my last post, looks like some older motherboards
>>had a bug where instead of reserving a few megabytes off the end of the
>>disk, it actually reserved a full 1TB.  There is no way to disable this
>>feature on older Gigabyte motherboards.  There are a large number of posts
>>and articles on the internet talking about corrupted filesystems and RAID
>>arrays caused by this bug.  General consensus seems to be to avoid older
>>Gigabyte motherboards completely.
>>
>>I'm now wondering if the kernal version had nothing to do with the issue.
>>Maybe the system drive on my Myth box was just a bit slow starting up and
>>meant that the BIOS decided to use my 3TB drive for the BIOS backup?  I did
>>reboot several times while trying to fix the issue, but still...
>>
>>Also, assuming that my motherboard did in fact write a BIOS copy to the end
>>of the disk - why didn't xfs_repair find any issues once I got my partition
>>back?
>
> The data areas for the xfs filesystem are a relatively small portion
> of the data on an xfs partition, and that is all that xfs_repair will
> be checking.  So if the BIOS write did not hit any of the xfs data
> areas, then xfs_repair will not see any problem.  But the BIOS data
> may still have overwritten part of a file somewhere, especially if the
> partition was full (as MythTV recording partitions tend to be after a
> while).
>
> BTW You must have actually been using the command "apt-get
> dist-upgrade" to get a new kernel - "apt-get upgrade" will not install
> anything new, just upgrade things that are already installed.

Yes it WILL upgrade a kernel, but not to a new major version.

And please posters, it is kernel, not kernal.