boot sector f*ed

[Roland Smith]

On Wed, Aug 12, 2009 at 07:34:49AM -0400, PJ wrote:
> I'm actually at the stage of doing the save/copy/transfer or whatever
> you can call it: here's what I am thinking and on which I need
> clarification.
> I ran HDD regenerator and it immediately flagged the very first sector
> as being Bad. 

Is this the program you're talking about?
http://store3.esellerate.net/store/ProductInfo.aspx?StoreIDC=STR793615240&SkuIDC=SKU9923428806&pc=

I'm not an expert on harddisks, but the claims that this program makes seem
too good to be true. I wonder what other on the list think of it? 

You may also find the following link about data recovery enlightening:
http://www.mjmdatarecovery.co.uk/data-recovery-articles/bad-sector-errors.html

Information encoding techniques on harddisks have changed dramatically over
the years to help enable the ever increasing densities. The link to HDD
regenerator talks about bad sectors showing.  Current harddisks have a number
of spare sectors available so that they can remap the data from unreadable
sectors, using the error correction bits to restore unreadable data. All this
is done in the harddisk itself, without even being visible to the user. AFAIK,
a harddisk will only start showing re-allocated sectors in the SMART
information after its spare sectors are exhausted. See
[http://en.wikipedia.org/wiki/Bad_sector] If this is the case, the common
advice it to decommission this drive ASAP.

You should use 'smartctl' from the sysutils/smartmontools port to check if
your harddisk is healthy or failing. 'smartctl -a /dev/<diskname>' should give
complete information. Look at a line containing the text
'Reallocated_Sector_Ct'. If the last number on this line is greater than zero,
the disk has run out of spare sectors, and it is time to get a new disk.

> On bootint, just before the crash, the boot process
> started... hesitated, lurched forward, hesitated and then proceeded to
> load only some minutes later closing down with a 177mb dump.
> I knew then there was a problem..  :-)

Yes. But probably not a problem with the boot sector. Because the machine
found and executed the boot code (because it booted). And it succeeded in
finding and loading the kernel (because it wrote a dump). Now it is important
to know _why_ the kernel dumped core. It could be that the kernel image was
corrupted on disk, pointing to a disk problem. But it can also be something
else.

So try and see if you can read the slice table with fdisk as described
below. If that works, the slice table should be OK.

> I have a 2nd disk just checked (with the regenerator - 12 hrs waiting on
> 2.4ghz cpu).
> If, indeed, the boot sector is the only thing mucked up, I should be
> able to copy the rest onto the 2nd(target) disk NP. The question, then,
> is how to deal with the boot sector. As I understand it, the boot sector
> has the partition information needed to run things for the rest of the
> disk. So, copying the damaged source disk will not give me the boot
> sector needed.

If your boot sector is truly buggered, read the manual pages for the following
utilities:
- fdisk(8)
- boot0cfg(8)

You can re-install the boot code in sector 0 easily with FreeBSD's
fdisk. E.g. if you are booting from the /dev/ad4 drive:
	'fdisk -B /dev/ad4'.

If you can boot from a FreeBSD livecd, try if you can read the slicetable
correctly with fdisk to check if it is really damaged. Again assuming the bad
drive is /dev/ad4, save the output of the following command to a file, and
post the contents here.

	'fdisk /dev/ad4'.

A tip for the future. If you have a newly sliced disk, save the slice table to
a file with 'fdisk -p /dev/ad4 >slicetable-ad4.txt', and save this file away
from the computer. If you ever damage the slice table, you can restore it
using the file that you saved with 'fdisk -f slicetable-ad4.txt -i /dev/ad4'.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~rsmith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090812/b2b156e2/attachment.pgp