Things Kids Shouldn't Do at Home

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Things Kids Shouldn't Do at Home

martin McCormick-3
I have killed an 8 GB thumb drive while doing an experiment.

        I had 2 8 GB PNY drives.  One has a FAT 32 file system
and the other had no partitions on it as I had deleted the ones
that were there.

        The good drive had it's UUID tagged to mount on a
directory I called /flash.  The fstab entry is

UUID="3453-A839" /flash vfat rw,user,noauto  0       0
#UUID="5A0D-76AA" /flash vfat rw,user,noauto  0       0

        I decided to make a full copy of the good drive to an
identical PNY 8 GB drive which was the one with all the
partitions deleted.

        The good drive was /dev/sde and the soon to be murdered
drive was /dev/sdd so my copy command was:

dd if=/dev/sde of=/dev/sdd

        It worked and I now had two drives with the same UUID.

        I mounted the doomed drive as /flash and did a rm -r
/flash/* so now I had an empty drive whose UUID is the same as
the good drive.

        Out of curiosity, I wondered what might happen if I had
two thumb drives containing the same UUID.

        After plugging both in to a usb extender, the good drive
is still good.  That's the one whose files I did not delete.

        The drive I killed now does not register anything at all.
It's as if nothing had been plugged in to any USB port.  I
plugged it in to another debian system that didn't witness any of
what I had just done and absolutely nothing happened there
either.

        There is no data emergency here, but what on Earth did I
do to the empty drive to make it not even show an error in
syslog?

        I am sure that having two devices with the same UUID is
not good, but I expected some sort of error message, not a total
destruction of one of the two drives.

        The now dead drive was behaving normally until I plugged
them both in at once.

        I was going to do a mount /flash and see what the system
did but it appears that just having both drives plugged in was
sufficient to draw some blood, so to speak, somewhere.

        The good drive contains some ebooks and I was planning
to put different ebooks on the dead drive but that is not going
to happen unless I can make the dead drive show up again.

        Are there any open-source rescue programs in Linux that
one can run to mess with the on-board controller of the thumb
drive?  This obviously killed the target drive since it was
working right up to when it stopped working.

        Thanks.

Martin McCormick
WB5AGZ

Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

songbird
  um, if you've plugged in one device with a certain
UUID and you've got a mount point and an /etc/fstab
entry for it and then plug in another i suspect the
2nd device would not cause anything to happen.

  what you might want to do is unplug the working
device and then plug in the one that doesn't work
and use a partitioner to set up a new partition
table and a new (and different UUID).

  see if that helps.  :)

  good luck.


  songbird

Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

David Christensen
In reply to this post by martin McCormick-3
On 2020-04-01 18:07, Martin McCormick wrote:

> I have killed an 8 GB thumb drive while doing an experiment.
>
> I had 2 8 GB PNY drives.  One has a FAT 32 file system
> and the other had no partitions on it as I had deleted the ones
> that were there.
>
> The good drive had it's UUID tagged to mount on a
> directory I called /flash.  The fstab entry is
>
> UUID="3453-A839" /flash vfat rw,user,noauto  0       0
> #UUID="5A0D-76AA" /flash vfat rw,user,noauto  0       0
>
> I decided to make a full copy of the good drive to an
> identical PNY 8 GB drive which was the one with all the
> partitions deleted.
>
> The good drive was /dev/sde and the soon to be murdered
> drive was /dev/sdd so my copy command was:
>
> dd if=/dev/sde of=/dev/sdd
>
> It worked and I now had two drives with the same UUID.
>
> I mounted the doomed drive as /flash and did a rm -r
> /flash/* so now I had an empty drive whose UUID is the same as
> the good drive.
>
> Out of curiosity, I wondered what might happen if I had
> two thumb drives containing the same UUID.
>
> After plugging both in to a usb extender, the good drive
> is still good.  That's the one whose files I did not delete.
>
> The drive I killed now does not register anything at all.
> It's as if nothing had been plugged in to any USB port.  I
> plugged it in to another debian system that didn't witness any of
> what I had just done and absolutely nothing happened there
> either.

All electronic devices fail eventually.  Your USB flash drive happened
to fail while you were exercising it.  I do not find that surprising.


I was once awoken in the middle of the night by the smell of burning
electronics.  This turned out to be a SanDisk Ultra Fit USB 3.0 128 GB
flash drive connected to my MacBook Pro for Time Machine backups.
Thankfully, it did not catch on fire and my MacBook seems undamaged.


David

Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

Alexander V. Makartsev
In reply to this post by martin McCormick-3
On 02.04.2020 06:07, Martin McCormick wrote:
I have killed an 8 GB thumb drive while doing an experiment.

	I had 2 8 GB PNY drives.  One has a FAT 32 file system
and the other had no partitions on it as I had deleted the ones
that were there.

	The good drive had it's UUID tagged to mount on a
directory I called /flash.  The fstab entry is

UUID="3453-A839" /flash vfat rw,user,noauto  0       0
#UUID="5A0D-76AA" /flash vfat rw,user,noauto  0       0

	I decided to make a full copy of the good drive to an
identical PNY 8 GB drive which was the one with all the
partitions deleted.

	The good drive was /dev/sde and the soon to be murdered
drive was /dev/sdd so my copy command was:

dd if=/dev/sde of=/dev/sdd

	It worked and I now had two drives with the same UUID.

	I mounted the doomed drive as /flash and did a rm -r
/flash/* so now I had an empty drive whose UUID is the same as
the good drive.

	Out of curiosity, I wondered what might happen if I had
two thumb drives containing the same UUID.

	After plugging both in to a usb extender, the good drive
is still good.  That's the one whose files I did not delete.

	The drive I killed now does not register anything at all.
It's as if nothing had been plugged in to any USB port.  I
plugged it in to another debian system that didn't witness any of
what I had just done and absolutely nothing happened there
either.

	There is no data emergency here, but what on Earth did I
do to the empty drive to make it not even show an error in
syslog?

	I am sure that having two devices with the same UUID is
not good, but I expected some sort of error message, not a total
destruction of one of the two drives.

	The now dead drive was behaving normally until I plugged
them both in at once.

	I was going to do a mount /flash and see what the system
did but it appears that just having both drives plugged in was
sufficient to draw some blood, so to speak, somewhere.

	The good drive contains some ebooks and I was planning
to put different ebooks on the dead drive but that is not going
to happen unless I can make the dead drive show up again.

	Are there any open-source rescue programs in Linux that
one can run to mess with the on-board controller of the thumb
drive?  This obviously killed the target drive since it was
working right up to when it stopped working.

	Thanks.

Martin McCormick
WB5AGZ

I think thumb drive failed because of physical damage and by pure coincidence.
That is, if you watch syslog [1] when plugging in faulty usb thumb drive and there is no messages about inserted hardware. I'd check for those in the first place.
From low-level perspective any plugged in usb device is different, at least because of different port IDs, so operating system would tell them apart even if data\filesystems on them are identical.
I suspect physical damage was done to lines or solder joints of usb connector or controller IC by bent PCB, or a static discharge fried a controller IC.

[1] # tail -f /var/log/syslog

-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀ 
Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

local10
In reply to this post by David Christensen
On 2020-04-01 18:07, Martin McCormick wrote:

>>  Out of curiosity, I wondered what might happen if I had
>> two thumb drives containing the same UUID.
>>

Nothing bad really unless the system is supposed to boot from one of them and both are present in the system at boot time.

I have two HDDs (main one and backup one) where partitions on the backup HDD have the same UUIDs as partitions on the main HDD. This was done on purpose to simplify backups and to have backup HDD to be readily available to replace the main HDD. I copied data between the two of them many times without any issues whatsoever.

If necessary, you can change UUID with tune2fs:
# tune2fs /dev/{device} -U {uuid}

Regards,

Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

martin McCormick-3
My thanks to all those who theorise that it was this particular
drive's time to die.  It is several years old and I was thinking
along the lines that the rest of you were thinking.  One thing I
haven't done yet is to see if the clock crystal  that drives the
internal usb controller is still active.  I am not sure what
frequency it should free run on but one can sometimes hear the
clock on a general-coverage short wave radio receiver or
scanner-type receiver.

        What one hears is a signal that usually sounds like a
continuous carrier with no modulation.  It's there when the drive
is powered up and goes away when the drive is disconnected.


Thanks.

Martin
WB5AGZ

local10 <[hidden email]> writes:
 On 2020-04-01 18:07, Martin McCormick wrote:

>
> >>  Out of curiosity, I wondered what might happen if I had
> >> two thumb drives containing the same UUID.
> >>
>
> Nothing bad really unless the system is supposed to boot from one of them
> and both are present in the system at boot time.
>
> I have two HDDs (main one and backup one) where partitions on the backup
> HDD have the same UUIDs as partitions on the main HDD. This was done on
> purpose to simplify backups and to have backup HDD to be readily
> available to replace the main HDD. I copied data between the two of them
> many times without any issues whatsoever.
>
> If necessary, you can change UUID with tune2fs:
> # tune2fs /dev/{device} -U {uuid}
>
> Regards,
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

G.W. Haywood-2
In reply to this post by martin McCormick-3
Hi there,

On Thu, 2 Apr 2020, Martin McCormick wrote:

> My thanks to all those who theorise that it was this particular
> drive's time to die.  It is several years old and I was thinking
> along the lines that the rest of you were thinking.  One thing I
> haven't done yet is to see if the clock crystal  that drives the
> internal usb controller is still active.  I am not sure what
> frequency it should free run on but one can sometimes hear the
> clock on a general-coverage short wave radio receiver or
> scanner-type receiver.
>
>         What one hears is a signal that usually sounds like a
> continuous carrier with no modulation.  It's there when the drive
> is powered up and goes away when the drive is disconnected.
>
>
> Thanks.
>
> Martin
> WB5AGZ

Come on WB5AGZ, you know better than that.  You can't hear a
continuous carrier with no modulation.  You can only hear the result
of mixing it with something. :)

--

73,
Ged,
MSEG3

Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

Joe Rowan
On Fri, 3 Apr 2020 09:58:14 +0100 (BST)
"G.W. Haywood" <[hidden email]> wrote:

> Hi there,
>
> On Thu, 2 Apr 2020, Martin McCormick wrote:
>
> > My thanks to all those who theorise that it was this particular
> > drive's time to die.  It is several years old and I was thinking
> > along the lines that the rest of you were thinking.  One thing I
> > haven't done yet is to see if the clock crystal  that drives the
> > internal usb controller is still active.  I am not sure what
> > frequency it should free run on but one can sometimes hear the
> > clock on a general-coverage short wave radio receiver or
> > scanner-type receiver.
> >
> >         What one hears is a signal that usually sounds like a
> > continuous carrier with no modulation.  It's there when the drive
> > is powered up and goes away when the drive is disconnected.
> >
> >
> > Thanks.
> >
> > Martin
> > WB5AGZ  
>
> Come on WB5AGZ, you know better than that.  You can't hear a
> continuous carrier with no modulation.  You can only hear the result
> of mixing it with something. :)
>

Yes, but if your receiver has any form of AGC, you should be able to
hear the background noise change when a significant carrier is being
received, or even just wideband junk at a level that forces its way
though the RF stage.

Not to mention the jitter in the frequency caused by program loops in
the processor with inadequate power smoothing... most modern
electronics puts out interference which can be heard as some sort of
clicking or buzzing.

--
Joe

Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

tomas@tuxteam.de
In reply to this post by G.W. Haywood-2
On Fri, Apr 03, 2020 at 09:58:14AM +0100, G.W. Haywood wrote:
> Hi there,
>
> On Thu, 2 Apr 2020, Martin McCormick wrote:
>
> >My thanks to all those who theorise that it was this particular
> >drive's time to die [...]

> >        What one hears is a signal that usually sounds like a
> >continuous carrier with no modulation.  It's there when the drive
> >is powered up and goes away when the drive is disconnected.

[...]

> Come on WB5AGZ, you know better than that.  You can't hear a
> continuous carrier with no modulation.  You can only hear the result
> of mixing it with something. :)

That depends which frequency this continuous carrier has. Those [1]
are clearly audible :-D

Cheers
[1] https://en.wikipedia.org/wiki/Bell_103_modem
-- "All generalizations suck" tomas

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Things Kids Shouldn't Do at Home

Nate Bargmann-4
In reply to this post by G.W. Haywood-2
* On 2020 03 Apr 04:16 -0500, G.W. Haywood wrote:

> Hi there,
>
> On Thu, 2 Apr 2020, Martin McCormick wrote:
>
> > My thanks to all those who theorise that it was this particular
> > drive's time to die.  It is several years old and I was thinking
> > along the lines that the rest of you were thinking.  One thing I
> > haven't done yet is to see if the clock crystal  that drives the
> > internal usb controller is still active.  I am not sure what
> > frequency it should free run on but one can sometimes hear the
> > clock on a general-coverage short wave radio receiver or
> > scanner-type receiver.
> >
> >         What one hears is a signal that usually sounds like a
> > continuous carrier with no modulation.  It's there when the drive
> > is powered up and goes away when the drive is disconnected.
> >
> >
> > Thanks.
> >
> > Martin
> > WB5AGZ
>
> Come on WB5AGZ, you know better than that.  You can't hear a
> continuous carrier with no modulation.  You can only hear the result
> of mixing it with something. :)
In an FM receiver it can become "full quieting" if it is strong enough.

True, the carrier won't be heard but the effect of a very low background
noise level when the carrier is strong enough to be clipped by the
limiter is audible.

To me FM was one of the great technical achievements of the 20th
Century.  Too bad Maj. Armstrong didn't live to see it fully embraced.
FM is a tragedy with many parts.

- Nate

--

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819


signature.asc (673 bytes) Download Attachment