Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Thursday, December 23, 2010

Corrupted USB Drive


By Collin Park in
Would SUSE and fsck be able to recover the data in a usable way?
My friend's brother had a 512MB Lexar Media Jumpdrive Pro USB drive that became corrupted after using it with Windows 2000. His IT department was able to get back some but not all of the file contents, but without any file names. On his own, he tried some recovery utilities, but all failed. Using a typical Linux distro--in this case SuSE 8.0--however, it wasn't hard to recover almost all of the data from the drive along with the filenames and to burn a CD-ROM of the contents.
USB Drive Ruined by Windows
Here's what I heard about the data loss:
Date: Sun,  1 Aug 2004 17:06:03 -0700
    Subject: USB
   ...  My USB drive is a
    Lexar Media USB Jumpdrive Pro 2.0 (512 MB).  I was working
    on it in a computer with Windows 2000 and logged off before
    ejecting the drive.  Next time when I tried to use it,
    it showed up as a Removable drive rather than the usual
    Lexar Media drive and when I tried to open it, it said the
    drive was not formatted; and under Properties, 0 bytes free
    and used space and file system "RAW"

    According to Lexar tech support, there is a bug with
    Windows 2000 (that MS never bothered to fix) and can corrupt
    the drive when it is removed without proper eject. They
    recommend EasyRecovery Pro for data recovery which did
    allow me to recover some files (> 500) using their RAW data
    recovery program (all other tool failed because usually
    said "no recognizable file on disc").  Unfortunately,
    all the file names are lost and some files are gone.
The big questions was "can Linux read the drive?" A Web search of "linux usb jumpdrive pro" gave me hope that my kernel, 2.4.18 on SuSE 8.0, would recognize the drive in question. So, as root, I typed:
# tail -f /var/log/messages
and plugged the drive into a USB socket. Here's what appeared; I removed "Aug 5 01:32:15 linux kernel:" from each line below):
usb.c: registered new driver usb-storage
    scsi0 : SCSI emulation for USB Mass Storage devices
    usb-uhci.c: interrupt, status 3, frame# 1313
      Vendor: LEXAR     Model: JUMPDRIVE PRO     Rev: 0   
      Type:   Direct-Access                      ANSI SCSI revision: 02
    Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
    SCSI device sda: 1001952 512-byte hdwr sectors (513 MB)
    sda: Write Protect is off
     sda: sda1
    WARNING: USB Mass Storage data integrity not assured
    USB Mass Storage device found at 4
    USB Mass Storage support registered.
Encouraged by that report, I tried this:
# dd if=/dev/sda of=/tmp/r1 bs=512
which reported that 1,001,952 blocks had been transferred. I then unplugged the drive and did the rest of my work using the image stored in /dev/sda.
Condition of the Boot Sector
The master boot record, which is the boot sector for the entire drive and its first sector, has a partition table, as well as other interesting things:
# od -Ax -tx1 /tmp/r1 | less
    0001b0 00 00 00 00 00 00 00 00 48 04 07 c9 00 00 80 01
    0001c0 01 00 06 0f ff e0 3f 00 00 00 b1 45 0f 00 00 00
    0001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
The boot sector has a reasonable-looking partition table with one entry. It began at offset 0x1be, the two bytes 80 01. Your favorite search engine can give you other information about the partition table, but I note two things here. First, the entry has an LBA32 format--starting logical sector 0x3f, length 0xf45b1. Now, 0xf45b1 is 1000881 decimal. That plus 63 (0x3f) is 1000944. The difference between the 1001952 and this 1000944 is 1008, that is, 63*16. I guess this has something to do with cylinder boundaries. The second thing of note is the byte at 0x1c2, with value 06; this is the partition type. What does 06 mean?
Typing fdisk /dev/hda as root and giving the command l to list, shows that type 6 is:
0  Empty           1c  Hidden Win95 FA 65  Novell Netware  bb  Boot Wizard hid
 1  FAT12           1e  Hidden Win95 FA 70  DiskSecure Mult c1  DRDOS/sec (FAT-
 2  XENIX root      24  NEC DOS         75  PC/IX           c4  DRDOS/sec (FAT-
 3  XENIX usr       39  Plan 9          80  Old Minix       c6  DRDOS/sec (FAT-
 4  FAT16 <32M      3c  PartitionMagic  81  Minix / old Lin c7  Syrinx         
 5  Extended        40  Venix 80286     82  Linux swap      da  Non-FS data    
 6  FAT16           41  PPC PReP Boot   83  Linux           db  CP/M / CTOS / .
So, it's FAT16.
Now, if I had been watching carefully, I would have known from the line sda: sda1 in /var/log/messages that the partition table was okay and contained only one entry.   More:
arreglar un USB roto
Copia bloques bloques de tamaño en bytes determinado por ibs del fichero de entrada, en vez de todo hasta el final del fichero.
Copia 1024000 bloques de tamaño 512 bytes (1024000*512/1024/1024 = 500 MiB) de /dev/zero a valido.

No comments: