20090524 VuS54 SD

From Seamonster
Jump to: navigation, search

I've been paranoidly trying to resuscitate the SD card from 54 (summary below, details farther below). I got it repaired--it looks like the last campbell data may be from 2008/10/02 23:03 while the Agent data is logged until Nov 16. That is all in the database/browsers now.

The VuS logged voltage was in 11V into November (and even hit 12.06V on Nov 9) The first 10V I see is Nov 11. First 9V is Nov 15. and the same day it went to 8V. The last data log I see if Nov 16.

Summary

The SD card was corrupt when it came back. An e2fsck failed, even an "mke2fs -S". All commands seemed to fail to see the partition, but fdisk did show the partition table. Finally (after cloning the SD card onto a USB stick and trying it there) I did an "fdisk /dev/sdc" and then simple "w" (wrote) the partition table. Then the disk was happily mounted, and I cloned it all onto my office computer.

Details

Here's diagnosing the problem. Solution described above.

[1549656.871098] Dev sdc: unable to read RDB block 0
[1549656.872804]  unable to read partition table
dev:/home/seamonster# dd if=/dev/sdc of=VuS54_corrupt_wholecard.dd
993280+0 records in
993280+0 records out
508559360 bytes (509 MB) copied, 72.669 seconds, 7.0 MB/s
dev:/home/seamonster# mount /dev/sdc3 /mnt
mount: special device /dev/sdc3 does not exist
dev:/home/seamonster# e2fsck /dev/sdc3
e2fsck 1.40.2 (12-Jul-2007)
e2fsck: No such file or directory while trying to open /dev/sdc3
dev:/home/seamonster# fdisk /dev/sdc

The number of cylinders for this disk is set to 1940.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sdc: 508 MB, 508559360 bytes
16 heads, 32 sectors/track, 1940 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1           6        1520   da  Non-FS data
/dev/sdc2               7          10        1024   da  Non-FS data
/dev/sdc3              20        1940      491776   83  Linux


At http://www.redhat.com/archives/enigma-list/2002-July/msg00287.html I found this:

Hi

On 15 Jul 2002, j neto wrote:

> I have a RedHat72 at home with a old PC,old harddisk Everythinh was ok
> till yesterday, it could autenticate user/pwd. I try force reboot, and
> it gave disk errors. I run fsck but it advice to run e2fsck, and this
> reports errors with the first blocl snd sugests to run e2fsck with -e
> 8193 option But this gives thesame error: can't find the first block
> and sugest the same What can i do? Reinstall everything again?

I had the same problem recently with a corrupt hard disk.  e2fsck would
not work, reporting "Bad magic number in super-block".  The -b 8193 option
also failed.  Clearly all the relevant blocks were unreadable and I
assumed that was the last I was going to see of the hard disk.

I then booted from a different hard disk and ran "mke2fs -S" on the
damaged partition.  See description on man page:

       -S     Write  superblock and group descriptors only.  This
              is useful if  all  of  the  superblock  and  backup
              superblocks  are corrupted, and a last-ditch recov­
              ery method is desired.  It causes mke2fs to  reini­
              tialize the superblock and group descriptors, while
              not touching the inode  table  and  the  block  and
              inode  bitmaps.   The  e2fsck program should be run
              immediately after this option is used, and there is
              no guarantee that any data will be salvageable.

After running e2fsck (which reported numerous errors) I found that the
disk was not only readable but actually bootable.  All the data appeared
intact.  The disk itself is still unreliable and clearly no use for an
online system, but the above exercise was very valuable for recovering
all current data from the damaged disk.

Regards

Jim Holland
System Administrator
MANGO - Zimbabwe's non-profit e-mail service