Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #181439 > unrolled thread

Kingston Thumb Drive Comatose.

Back to article view | Back to linux.debian.user

Contents

  Kingston Thumb Drive Comatose. "Martin McCormick" <martin.m@suddenlink.net> - 2017-05-26 23:10 +0200
    Re: Kingston Thumb Drive Comatose. Fungi4All <fungilife@protonmail.com> - 2017-05-27 00:20 +0200
      storage devices with same marketing size having different number of  blocks David Christensen <dpchrist@holgerdanske.com> - 2017-05-27 04:30 +0200
      Re: Kingston Thumb Drive Comatose. "Martin McCormick" <martin.m@suddenlink.net> - 2017-05-27 04:30 +0200
    Re: Kingston Thumb Drive Comatose. David Christensen <dpchrist@holgerdanske.com> - 2017-05-27 03:20 +0200
      Re: Kingston Thumb Drive Comatose. "Martin McCormick" <martin.m@suddenlink.net> - 2017-05-27 21:50 +0200
        Re: Kingston Thumb Drive Comatose. David Christensen <dpchrist@holgerdanske.com> - 2017-05-27 23:30 +0200
          Re: Kingston Thumb Drive Comatose. David Wright <deblis@lionunicorn.co.uk> - 2017-05-28 06:00 +0200
    Re: Kingston Thumb Drive Comatose. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-05-28 12:00 +0200
      Re: Kingston Thumb Drive Comatose. Jamie White <jatos.software@gmail.com> - 2017-05-28 16:10 +0200
        Re: Kingston Thumb Drive Comatose. Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-05-28 16:50 +0200

#181439 — Kingston Thumb Drive Comatose.

	I have a 128 GB thumb drive which has been sitting in a
drawer for 2 or 3 years because it is not completely dead but had
a traumatic event.

	It worked fine until the night it accidentally got
over-filled after a backup script tried to put this drive's own
file system back in to it in an infinite recursive loop which is
what you get when one forgets to exclude the mount point.

	Of course, what should have happened was a "Write failed"
condition but what actually happened seems to be that the
controller in the Kingston drive lost track of where to put
anything so it now can't even find the SDRAM that makes up the
"disk."

	The drive makes the /dev/sdX node as one might expect but
any attempt to read or write the node such as to reformat it or
use fdisk on it fails with a "no medium found" message.

	Since this was a backup drive, I simply got another drive
and backed up to it so I just want to be able to use this drive
again since the failure is probably not due to actual
hardwarefailure but could be called a design flaw since the drive
should protect itself from this sort of issue.

	Has the state of the art improved any recently so that
Linux users have any tools that can unstick the Kingston's
controller? The data are probably not of any importance any
longer but the drive probably cost close to $100 when it was new
and it seems so close to being usable. Any constructive ideas are
appreciated.
Here is what syslog shows when the drive is inserted:

audio2 kernel: [82157.422619] usb 1-1: new full-speed USB device number 2 using uhci_hcd
kernel: [82157.734651] usb 1-1: new full-speed USB device number 3 using uhci_hcd
kernel: [82157.909640] usb 1-1: New USB device found, idVendor=13fe, idProduct=3100
kernel: [82157.913558] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: [82157.917858] usb 1-1: Product: 2233 PRAM               
kernel: [82157.920367] usb 1-1: Manufacturer:                         
kernel: [82157.987815] usb-storage 1-1:1.0: USB Mass Storage device detected
kernel: [82157.999983] scsi2 : usb-storage 1-1:1.0
kernel: [82158.010244] usbcore: registered new interface driver usb-storage
kernel: [82159.011680] scsi 2:0:0:0: Direct-Access              2233 PRAM        1.00 PQ: 0 ANSI: 0 CCS
kernel: [82159.037067] sd 2:0:0:0: Attached scsi generic sg3 type 0
kernel: [82159.063686] sd 2:0:0:0: [sdc] Attached SCSI removable disk

[toc] | [next] | [standalone]

#181441

[Multipart message — attachments visible in raw view] — view raw

From: martin.m@suddenlink.net
The data are probably not of any importance any
longer but the drive probably cost close to $100 when it was new
and it seems so close to being usable. Any constructive ideas are
appreciated.

Wild guess would be to use gparted and delete all partitions then
use dd if=/dev/zero 128000x1024 or more and see what the firmware would do.
I think it would reset itself once everything is deleted from it and refilled with 0
blocks to the max. I don't think you can digitally hurt these things till they
mechanically fail and can't write anymore. They will not delete data on their
own unless instructed specifically to do so.

Here is a surprising experience. Recently I asked the store to give me a few
of the cheapest and nastiest usb sticks, 8Gb if they had. The usb3 16Gb
were only a buck more. So I got identical sitting side by side on the rack
Intenso 16Gb usb3. I installed a system with 3 partitions on the one, booted
configured and wanted to make a backup with settings for network for a
seconf machine. So I used dd if=sdc of=sdd
I go in and check and there were a whole bunch of Mb more on the second
drive with no partition while the partitions that copied seemed identical.
So I wonder how long it would have taken me to figure out the error caused
by dd if I had randomly used the second as first and the first as second.
I think they are like uuids, there are no two identical usb drives ever.

[toc] | [prev] | [next] | [standalone]

#181472 — storage devices with same marketing size having different number of blocks

On 05/26/2017 03:16 PM, Fungi4All wrote:
> Here is a surprising experience. Recently I asked the store to give me a few
> of the cheapest and nastiest usb sticks, 8Gb if they had. The usb3 16Gb
> were only a buck more. So I got identical sitting side by side on the rack
> Intenso 16Gb usb3. I installed a system with 3 partitions on the one, booted
> configured and wanted to make a backup with settings for network for a
> seconf machine. So I used dd if=sdc of=sdd
> I go in and check and there were a whole bunch of Mb more on the second
> drive with no partition while the partitions that copied seemed identical.
> So I wonder how long it would have taken me to figure out the error caused
> by dd if I had randomly used the second as first and the first as second.
> I think they are like uuids, there are no two identical usb drives ever.

It is common for storage devices with the same marketing size to have 
different numbers of blocks.  Usually the same make and model of devices 
within a given production run (e.g. hardware revision) have the same 
number of blocks, but not necessarily so for different production runs 
(I have SanDisk Ultra Fit drives like this).


If imaging is in your bag of tricks, one work-around is 
under-provisioning -- e.g. partition new devices with less than 100% of 
the available blocks; leaving unused blocks at the end.  (Choosing the 
"right" number of blocks to leave unused is an exercise left for the 
reader.)


AFAIK USB flash drives don't have TRIM or secure erase, but there may be 
controllers/ firmware smart enough to recognize zero blocks and optimize 
their use (?).


David

[toc] | [prev] | [next] | [standalone]

#181473

Fungi4All <fungilife@protonmail.com> writes:
> Wild guess would be to use gparted and delete all partitions then
> use dd if=/dev/zero 128000x1024 or more and see what the firmware would 
> do.
> I think it would reset itself once everything is deleted from it and 
> refilled with 0
> blocks to the max. I don't think you can digitally hurt these things till 
> they
> mechanically fail and can't write anymore. They will not delete data on 
> their
> own unless instructed specifically to do so.

	This issue is deeper as the controller in the thumb drive
no longer knows where the media resides.

$sudo fdisk -l /dev/sdc
fdisk: cannot open /dev/sdc: No medium found

that is exactly what you also get if you use dd to either write
to /dev/sdc or read from it. Other people using MSWindows state
that the drive shows up as empty and they are prompted to insert
a disk (neat trick.) so different operating systems complain in
slightly different ways, but the upshot is that the on-board
controller has no idea any longer where data are stored hince the
"no medium found" condition.

	With all the tinkering that goes on in Linux, I am
surprised nobody has come up with a set of utilities as I bet
many of these thumb drives have similar microcode or similar
structures for allowing the thumb drive to reset it's controller.

	Since eprom has a finite number of write cycles, the
controllers cleverly shift write jobs around so data are written
to different memory cells when possible.

	I expect the best I can hope for is to reset it to
defaults so the drive will appear empty but can then be
repartitioned and used again.

Martin McCormick

[toc] | [prev] | [next] | [standalone]

#181468

On 05/26/2017 02:06 PM, Martin McCormick wrote:
> 	I have a 128 GB thumb drive which has been sitting in a
> drawer for 2 or 3 years because it is not completely dead but had
> a traumatic event.
>
> 	It worked fine until the night it accidentally got
> over-filled after a backup script tried to put this drive's own
> file system back in to it in an infinite recursive loop which is
> what you get when one forgets to exclude the mount point.
>
> 	Of course, what should have happened was a "Write failed"
> condition but what actually happened seems to be that the
> controller in the Kingston drive lost track of where to put
> anything so it now can't even find the SDRAM that makes up the
> "disk."
>
> 	The drive makes the /dev/sdX node as one might expect but
> any attempt to read or write the node such as to reformat it or
> use fdisk on it fails with a "no medium found" message.
>
> 	Since this was a backup drive, I simply got another drive
> and backed up to it so I just want to be able to use this drive
> again since the failure is probably not due to actual
> hardwarefailure but could be called a design flaw since the drive
> should protect itself from this sort of issue.
>
> 	Has the state of the art improved any recently so that
> Linux users have any tools that can unstick the Kingston's
> controller? The data are probably not of any importance any
> longer but the drive probably cost close to $100 when it was new
> and it seems so close to being usable. Any constructive ideas are
> appreciated.
> Here is what syslog shows when the drive is inserted:
>
> audio2 kernel: [82157.422619] usb 1-1: new full-speed USB device number 2 using uhci_hcd
> kernel: [82157.734651] usb 1-1: new full-speed USB device number 3 using uhci_hcd
> kernel: [82157.909640] usb 1-1: New USB device found, idVendor=13fe, idProduct=3100
> kernel: [82157.913558] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> kernel: [82157.917858] usb 1-1: Product: 2233 PRAM
> kernel: [82157.920367] usb 1-1: Manufacturer:
> kernel: [82157.987815] usb-storage 1-1:1.0: USB Mass Storage device detected
> kernel: [82157.999983] scsi2 : usb-storage 1-1:1.0
> kernel: [82158.010244] usbcore: registered new interface driver usb-storage
> kernel: [82159.011680] scsi 2:0:0:0: Direct-Access              2233 PRAM        1.00 PQ: 0 ANSI: 0 CCS
> kernel: [82159.037067] sd 2:0:0:0: Attached scsi generic sg3 type 0
> kernel: [82159.063686] sd 2:0:0:0: [sdc] Attached SCSI removable disk

Please verify the device node for the USB flash drive (e.g. /dev/sdc), 
run the following commands, and paste your console session into a reply:

# cat /etc/debian_version

# uname -a

# fdisk -l /dev/sdc

# dd if=/dev/zero of=/dev/sdc count=2048; sync

# fdisk -l /dev/sdc


David

[toc] | [prev] | [next] | [standalone]

#181520

David Christensen <dpchrist@holgerdanske.com> writes:
> Please verify the device node for the USB flash drive (e.g. /dev/sdc), run
> the following commands, and paste your console session into a reply:
> 
> 
> # cat /etc/debian_version
> 
> # uname -a
> 
> # fdisk -l /dev/sdc
> 
> # dd if=/dev/zero of=/dev/sdc count=2048; sync
> 
> # fdisk -l /dev/sdc
> 
> 
> David

	I also added to that
#ls /dev/sdc

	Here are the results.

8.8
Linux audio2 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2 (2017-04-30) i686 GNU/Linux
fdisk: cannot open /dev/sdc: No medium found
dd: failed to open ‘/dev/sdc’: No medium found
fdisk: cannot open /dev/sdc: No medium found
root@audio2:/home/martin# ls /dev/sdc
/dev/sdc

It's there but it doesn't do anything else but show up as a
storage device with no medium.

Martin

[toc] | [prev] | [next] | [standalone]

#181525

On 05/27/2017 12:40 PM, Martin McCormick wrote:
> David Christensen <dpchrist@holgerdanske.com> writes:
>> # cat /etc/debian_version
> 8.8

>> # uname -a
> Linux audio2 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2 (2017-04-30) i686 GNU/Linux

>> # fdisk -l /dev/sdc
> fdisk: cannot open /dev/sdc: No medium found

>> # dd if=/dev/zero of=/dev/sdc count=2048; sync
> dd: failed to open ‘/dev/sdc’: No medium found

The path to your device node appears to contain unicode.  Is that an 
e-mail artifact, or did you feed a unicode path to dd?  This is why I 
said "paste your console session into a reply" -- so we can verify the 
command that was actually run.


>> # fdisk -l /dev/sdc
> fdisk: cannot open /dev/sdc: No medium found

> root@audio2:/home/martin# ls /dev/sdc
> /dev/sdc

Plain 'ls' isn't very useful.  The -l switch provides more information.


Please unplug all extraneous USB devices, leave the Kingston drive 
plugged in, run the following commands, and paste your console session 
into a reply:

# ls -l /dev/sdc

# lsusb


What happens if you connect the Kingston drive into a Windows machine?


David

[toc] | [prev] | [next] | [standalone]

#181531

On Sat 27 May 2017 at 14:19:29 (-0700), David Christensen wrote:
> On 05/27/2017 12:40 PM, Martin McCormick wrote:
> >David Christensen <dpchrist@holgerdanske.com> writes:
> >># cat /etc/debian_version
> >8.8
> 
> >># uname -a
> >Linux audio2 3.16.0-4-686-pae #1 SMP Debian 3.16.43-2 (2017-04-30) i686 GNU/Linux
> 
> >># fdisk -l /dev/sdc
> >fdisk: cannot open /dev/sdc: No medium found
> 
> >># dd if=/dev/zero of=/dev/sdc count=2048; sync
> >dd: failed to open ‘/dev/sdc’: No medium found
> 
> The path to your device node appears to contain unicode.  Is that an
> e-mail artifact, or did you feed a unicode path to dd?  This is why
> I said "paste your console session into a reply" -- so we can verify
> the command that was actually run.

I hadn't noticed it before, but dd uses “real” quotation marks
in its error message. Who would have thought it?

I'd be interested to see the contents of file /run/udev/data/b8:X
where X is typically a power of two. The file appears as the stick
is plugged in. If the stick is partitioned, files b8:X+1, etc also
appear, one for each partition.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#181536

Le 26/05/2017 à 23:06, Martin McCormick a écrit :
> 	I have a 128 GB thumb drive which has been sitting in a
> drawer for 2 or 3 years because it is not completely dead but had
> a traumatic event.
(...)

The drive is dead. The controller is still responding but the storage 
part is gone. Don't waste any more time with it.

[toc] | [prev] | [next] | [standalone]

#181545

[Multipart message — attachments visible in raw view] — view raw

I would suspect you need a specialist application to sort this, thing is,
when you plug in a disk drive, the system uses information from the first
sector to identify the drive and its size. You get a similar problem when
you zero out an entire hard disk, and there the solution is to manually
enter into the bios the hard drive.

What I suspect has happened in your case, is a wrap around when writing to
drive has overwritten the first sector.

Jamie

On Sun, May 28, 2017 at 10:54 AM, Pascal Hambourg <pascal@plouf.fr.eu.org>
wrote:

> Le 26/05/2017 à 23:06, Martin McCormick a écrit :
>
>>         I have a 128 GB thumb drive which has been sitting in a
>> drawer for 2 or 3 years because it is not completely dead but had
>> a traumatic event.
>>
> (...)
>
> The drive is dead. The controller is still responding but the storage part
> is gone. Don't waste any more time with it.
>
>


-- 
Jamie

[toc] | [prev] | [next] | [standalone]

#181546

Le 28/05/2017 à 16:08, Jamie White a écrit :
> I would suspect you need a specialist application to sort this, thing is,
> when you plug in a disk drive, the system uses information from the first
> sector to identify the drive and its size.

No, this information is not stored in the first sector nor anywhere else 
in the storage area. It is retrieved using a drive identification 
command, not a sector read command.

> You get a similar problem when you zero out an entire hard disk

No, it is a completely different problem. It destroys partition tables, 
partitions and filesystems, not drive identification.

> and there the solution is to manually enter into the bios the hard drive.

I don't see what you mean exactly, but that won't solve either problem.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web