Repairing Flash Drive that wasn't ejected with I/O errors?
I was dumb and didn't eject my flash drive, now it won't show up in mount, can't be manually mounted, dd just hangs when trying to zero it out, and I get I/O errors when trying to format it. I know the hardware is good, or at least was, the only thing that should be wrong with it is that I didn't know ejecting it was necessary. Please help, it's a 136GB(advertised as 128 with about 33GB hidden) PNY USB 3.0.
dmesg | tail
[122321.163508] usb-storage 2-1:1.0: USB Mass Storage device detected
[122321.165914] scsi7 : usb-storage 2-1:1.0
[122322.588840] scsi 7:0:0:0: Direct-Access PNY USB 3.0 FD 1100 PQ: 0 ANSI: 6
[122322.589312] sd 7:0:0:0: Attached scsi generic sg2 type 0
[122322.590302] sd 7:0:0:0: [sdb] 266108928 512-byte logical blocks: (136 GB/126 GiB)
[122322.592467] sd 7:0:0:0: [sdb] Write Protect is off
[122322.592472] sd 7:0:0:0: [sdb] Mode Sense: 43 00 00 00
[122322.593566] sd 7:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[122322.604864] sdb: unknown partition table
[122322.608311] sd 7:0:0:0: [sdb] Attached SCSI removable diskmount /dev/sdb ~/Desktop/temp
mount: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or solsusb -s 002:008 -v
Bus 002 Device 008: ID 154b:00ad PNY
Couldn't open device, some information will be missing
Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x154b PNY idProduct 0x00ad bcdDevice 11.00 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0sudo fdisk -l /dev/sdb
Disk /dev/sdb: 136.2 GB, 136247771136 bytes
255 heads, 63 sectors/track, 16564 cylinders, total 266108928 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/sdb doesn't contain a valid partition tableEDIT: 7/24/2018 Because of a (relatively) new response:
I tried wiping it with mkusb and formatting it with the disk utility, both of which just froze there for hours. It also freezes when trying to benchmark. I'm pretty sure it's just fried.
1 Answer
This is a very late answer. If you are still interested in fixing this flash drive, you can try along the following routes.
Repair the partition table and file system or recover files
It might be possible to repair the structure on the drive with testdisk, and if that does not work, it is possible (bad hard work) to recover files with photorec.
If there are important files to recover, I would recommend that you clone the drive and do the repair work on the cloned copy.
You will find more details at the following link,
Repair the partition table and file system of a pendrive
If there are no important files to recover
If there are no important files to recover, you can try to wipe the first megabyte of the drive and after that use a tool to create a new partition table with partitions and file systems, that you want on the drive.
According to the output from
sudo fdisk -l /dev/sdbin your question, the drive is still working as a mass storage device. If there is still write access, mkusb can wipe the first megabyte and after that gparted can create the partition table, partitions and file systems that you want.
Or you can let mkusb restore the drive to a standard storage device with an MSDOS partition table and a partition with the FAT32 file system. This is the 'easy option'.
See the following links
Gridlocked
Otherwise, with no write access at the 'raw level', mkusb will fail to wipe the first megabyte, and the drive is probably 'gridlocked', which is the first stage of a failing process. See this link
2