Re: [gentoo-user] recovery from /var corruption?

[Mark Knecht]

On Fri, Feb 26, 2010 at 9:59 AM, Volker Armin Hemmann
<volkerarmin@××××××××××.com> wrote:
> On Freitag 26 Februar 2010, Mark Knecht wrote:
>
>>
>> The machine _mostly_ crashed while running badblocks. I say mostly
>> because the mouse is still alive but I can no longer ssh in and cannot
>> open a terminal on my wife's desktop or get to the console.
>
> because it is not crashed but waiting for the ide timeouts.

So if I let it continue running is it going to come back in the next
hour or two? I am assuming the IDE timeouts are because the drive is
having trouble, correct? That's the theory here? If so then unless the
software can mark them bad and somehow create good files out of bad
then I'm still left with a machine that is going to need serious work
done before it's a happy box again, correct?

On the other hand, because I have reasonably good user backups
(although no real system backups) right now if I bite the bullet and
build the machine then when my wife gets it back it's hopefully going
to be more reliable, wouldn't it?

I'm thinking that maybe I just copy a little stuff off the box - /etc
and the like - and then boot the machine with the Gentoo install CD or
System Resuce CD and see what the drive is doing?

That doesn't cost me anything to look around, but if SMART won't turn
on and badblocks is suggesting the drive is having trouble maybe
running something like badblocks and actually __marking__ blocks as
bad and then reloading Gentoo would work in the long run? (A lot of
work though.)

I'm really not interested in buying new drive because the machine is
ATA100/133 and if it's not the drive then the money is wasted for a
new machine. The cheapest at NewEgg is about $40. Why spend the buck
for an old Intel Centrino machine?

>
>>
>> I tried to Ctrl-C out out of badblocks here (this is running shelled
>> in) before I figured out it was a total crash which messed up the
>> terminal a bit but you can see what it was reporting before the crash
>>
>> dragonfly ~ # badblocks -sv /dev/hda
>> Checking blocks 0 to 156290903
>> Checking for bad blocks (read-only test): 89360960done, 35:00 elapsed
>> 89360961done, 35:09 elapsed
>> 89360962
>> 89360963
>> ^C^C18% done, 35:27 elapsed
>>
>> So, there seem to be problems, possibly with the drive, or maybe it's
>> some sort of overheating problem on the processor and this was just
>> the way the processor failed before the crash?
>>
>> I ran memtest86 night before last for 8 hours and had no memory
>> problems. I'll remove memory and PCI cards, reseat everything, and
>> then see what happens.
>
> protip: if you are running badblocks (or ddrescue) on a probably damaged
> device - attach it with an usb adapter. That way your box is still usable.
>
> /me hates linux kernel for making processes in D unkillable and sucking very
> much on diskio.
>
>

Good inputs. Thanks!

Cheers,
Mark