[sclug] Victim of unprovoked power pailures

[Graham]

> Message: 1
> Date: Fri, 16 Dec 2005 16:50:30 +0000
> From: Patrick <patrick at kirks.net>
> Subject: Re: [sclug] Victim of unprovoked power pailures
> To: SCLUG <sclug at sclug.org.uk>
> Message-ID: <43A2F056.7080202 at kirks.net>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> I'll have a stab at it tonight.  I have no idea how to use dpkg any more 
> so will try the md5sum -c /var/lib/dpkg/info/coreutils.md5sums command 
> and see if it makes any sense.
> 
> It may be that a simple format and reinstall isthe best option.
> 
> Thanks all.
> 
> Patrick

It was an isolated issue,
but on IBM laptop disks from a specific 6 months,
there was a fault with the 'fdisk' geometry layout,
which manifested itself when a disk block error happenned.
Something to do with thermal recalibration failing,
causing a new thermal calibration, causing what sounded
like a ping-pong match going on. It was cured by a fresh fdisk.

If yours is a bad block, which fails, leaving core dumps from some binary,
it should show up as an sector error in dmesg, whilst running
	dd if=/dev/hda of=/dev/null bs=128k
If a HD gets a bad-block, it wants to provide the data, but it cant.
It wants to swap the bad media for a good one, but it cant, because
it needs the old data. After internal retries, it fails the read request,
and the kernel reports it. If you find the sector, you can overwrite it (at
block aligned boundries), and the HD's firmware will overlay it forever.
That will then leave you with something full of NUL bytes (feeling lucky?)

If you need to know what will be clobbered (a work machine), you can
read every file with cpio, until dmesg complains, and narrow it down,
or RTFM ext_debugfs. (It could also be a directory, inode or fs block)

As for format, there is (generally) no such thing available in user-land.
The low-level media format is done at the factory, and can be re-done,
but only with secret invocations of SCSI bios / ATA-opcodes.

Graham