By Collin Park in HOWTOs
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/messagesand 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=512which 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.
# 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 aaThe 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:
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.