Roland Smith wrote:
> 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?
It sure looks like it. Don't recall the version.
> 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:
I'll look at it for sure.
> 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
> [] 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.
Will try it, too.
>> 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.
Well, I've been looking at the disk(s) and I have found some interesting
"shei**e" that doesn't make sense.
1. The fbsd minimal installation that I had set up for recovery of the
previous crash does not boot... Now, why in Hades is that? I hadn't
touched the disk since last using it to look at the corrupted disk
through an usb connection. The current crashed installetion was done
afterwards and the only change was in the bios to set the boot disk to
the new installation. The installation was finally completed with all
the programs working fine... and then BOOM!
2. I tried booting from all the disks on the machine (4 disks) and only
the current crashed one booted!... so, it's not the boot sector at
all... something is screwy on this machine; either the motherboard is
buggered (which I doubt, but not entirely), the disks are finished or
theres some kind of gremlin lurking in the confines of the box.

So, I will proceed to do some more reading and research on all this and
then check out the procedures you've suggested below. I may not be able
to respond too quickly as I've got a few other devils circling my
head... like organizing and adjusting normal living conditions which
include garbage, house repairs, sometimes sleeping and often running
around the city getting stuff for just plain survival... :-( ;-) :'( 

I appreciate your response and have already learned quite a lot... it's
rather heavy for my little brain, but I'll try to deal with it.. :-)
>> 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

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to