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)
Description: PGP signature