Re: [PLUG] Weird microSD failure

[Russell Senior]

Yeah, I understood about the on-SD controller.  There is typically
some kind of ARM-based microcontroller that does all the block-device
to NAND translation.  It is doing something wrong and clearly
dysfunctional now, though.  I am sure that I did successful block
operations on the same microSD previously.

On Tue, Mar 6, 2018 at 5:31 PM, Tomas Kuchta
 wrote:
> When I said card controller, I meant the card controller on/in the actual
> SD card. Not the piece of HW attached to your computer.
>
> My conclusion at the time I was trying to understand the same behavior was
> that the in-card controller must be doing file transactions of some kind.
> Not behaving quite like basic block device.
>
> I recall even trying to actively corrupt the card's content, no success.
> Still, all worked fine when installing Linux on said cards.
>
> Hope it helps you avoiding wasting whole day or three on this, like I did.
>
> Tomas
>
> On Mar 7, 2018 9:23 AM, tomas.kuchta.li...@gmail.com wrote:
>
>> I do not believe that SD cards respond to pure raw block writes from dd.
>> Not unless the stream looks like files.
>>
>> I run into the same discovery some time ago. If I remember correctly, dd
>> didn't overwrite the content even with random data. It could behave
>> different for different firmware, but I tried a few with the same result.
>>
>> Tomas
>>
>> On Mar 7, 2018 9:13 AM, "wes"  wrote:
>>
>> that's only if you want to generate a certain size. otherwise it just keeps
>> going until it runs out of blocks to fill.
>>
>> -wes
>>
>> On Tue, Mar 6, 2018 at 5:08 PM, Tim Garton  wrote:
>>
>> > Don't you need a "count=#" option to dd as well? Not at a computer right
>> > now otherwise I'd be able to check if that's the case...
>> >
>> > On Mar 6, 2018 5:02 PM, "Richard England" 
>> wrote:
>> >
>> > > On 03/06/2018 04:20 PM, Tomas Kuchta wrote:
>> > >
>> > >> Try to delete the original files first. Then create empty file using
>> > >> /dev/zero and copy it to the card. I bet that it will be there on the
>> > card
>> > >> and some of your original data will disappear as result.
>> > >>
>> > >> My guess is that the card controller is deduplicating your /dev/zero
>> > >> blocks
>> > >> trying to protect the card from writes.
>> > >>
>> > >> Tomas
>> > >>
>> > >> On Mar 6, 2018 7:09 PM, "Russell Senior" 
>> > >> wrote:
>> > >>
>> > >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior
>> > >>>  wrote:
>> > >>>
>> >  On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock 
>> >  wrote:
>> > 
>> > > My initial attempt to google this was unsuccessful (most people
>> point
>> > >> out the write protect tab, not my problem).
>> > >>
>> > >
>> > > Bad switch on the write protect tab? (The tab operates a tiny
>> > switch.)
>> > >
>> >  Nope.
>> > 
>> >  I can turn the switch to lock and it mounts the device read only
>> very
>> >  clearly.  The behavior I observe is that it happily writes /dev/zero
>> >  over the block device, but then when I read again, the old data is
>> >  still present.
>> > 
>> > >>> For example, if I flip the tab to write protect tab to "Lock", I get
>> > >>> this:
>> > >>>
>> > >>> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M
>> > >>> dd: failed to open '/dev/sdc': Read-only file system
>> > >>> ___
>> > >>> PLUG mailing list
>> > >>> PLUG@pdxlinux.org
>> > >>> http://lists.pdxlinux.org/mailman/listinfo/plug
>> > >>>
>> > >>> ___
>> > >> PLUG mailing list
>> > >> PLUG@pdxlinux.org
>> > >> http://lists.pdxlinux.org/mailman/listinfo/plug
>> > >>
>> > >
>> > > |Perhaps using dd if=/dev/urandom |of=/dev/sdc status=progress bs=1M
>> > > ...just a thought.
>> > >
>> > > ___
>> > > PLUG mailing list
>> > > PLUG@pdxlinux.org
>> > > http://lists.pdxlinux.org/mailman/listinfo/plug
>> > >
>> > ___
>> > PLUG mailing list
>> > PLUG@pdxlinux.org
>> > http://lists.pdxlinux.org/mailman/listinfo/plug
>> >
>> ___
>> PLUG mailing list
>> PLUG@pdxlinux.org
>> http://lists.pdxlinux.org/mailman/listinfo/plug
>>
>>
>>
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Weird microSD failure

[Tomas Kuchta]

When I said card controller, I meant the card controller on/in the actual
SD card. Not the piece of HW attached to your computer.

My conclusion at the time I was trying to understand the same behavior was
that the in-card controller must be doing file transactions of some kind.
Not behaving quite like basic block device.

I recall even trying to actively corrupt the card's content, no success.
Still, all worked fine when installing Linux on said cards.

Hope it helps you avoiding wasting whole day or three on this, like I did.

Tomas

On Mar 7, 2018 9:23 AM, tomas.kuchta.li...@gmail.com wrote:

> I do not believe that SD cards respond to pure raw block writes from dd.
> Not unless the stream looks like files.
>
> I run into the same discovery some time ago. If I remember correctly, dd
> didn't overwrite the content even with random data. It could behave
> different for different firmware, but I tried a few with the same result.
>
> Tomas
>
> On Mar 7, 2018 9:13 AM, "wes"  wrote:
>
> that's only if you want to generate a certain size. otherwise it just keeps
> going until it runs out of blocks to fill.
>
> -wes
>
> On Tue, Mar 6, 2018 at 5:08 PM, Tim Garton  wrote:
>
> > Don't you need a "count=#" option to dd as well? Not at a computer right
> > now otherwise I'd be able to check if that's the case...
> >
> > On Mar 6, 2018 5:02 PM, "Richard England" 
> wrote:
> >
> > > On 03/06/2018 04:20 PM, Tomas Kuchta wrote:
> > >
> > >> Try to delete the original files first. Then create empty file using
> > >> /dev/zero and copy it to the card. I bet that it will be there on the
> > card
> > >> and some of your original data will disappear as result.
> > >>
> > >> My guess is that the card controller is deduplicating your /dev/zero
> > >> blocks
> > >> trying to protect the card from writes.
> > >>
> > >> Tomas
> > >>
> > >> On Mar 6, 2018 7:09 PM, "Russell Senior" 
> > >> wrote:
> > >>
> > >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior
> > >>>  wrote:
> > >>>
> >  On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock 
> >  wrote:
> > 
> > > My initial attempt to google this was unsuccessful (most people
> point
> > >> out the write protect tab, not my problem).
> > >>
> > >
> > > Bad switch on the write protect tab? (The tab operates a tiny
> > switch.)
> > >
> >  Nope.
> > 
> >  I can turn the switch to lock and it mounts the device read only
> very
> >  clearly.  The behavior I observe is that it happily writes /dev/zero
> >  over the block device, but then when I read again, the old data is
> >  still present.
> > 
> > >>> For example, if I flip the tab to write protect tab to "Lock", I get
> > >>> this:
> > >>>
> > >>> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M
> > >>> dd: failed to open '/dev/sdc': Read-only file system
> > >>> ___
> > >>> PLUG mailing list
> > >>> PLUG@pdxlinux.org
> > >>> http://lists.pdxlinux.org/mailman/listinfo/plug
> > >>>
> > >>> ___
> > >> PLUG mailing list
> > >> PLUG@pdxlinux.org
> > >> http://lists.pdxlinux.org/mailman/listinfo/plug
> > >>
> > >
> > > |Perhaps using dd if=/dev/urandom |of=/dev/sdc status=progress bs=1M
> > > ...just a thought.
> > >
> > > ___
> > > PLUG mailing list
> > > PLUG@pdxlinux.org
> > > http://lists.pdxlinux.org/mailman/listinfo/plug
> > >
> > ___
> > PLUG mailing list
> > PLUG@pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> >
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
>
>
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Weird microSD failure

[Tomas Kuchta]

I do not believe that SD cards respond to pure raw block writes from dd.
Not unless the stream looks like files.

I run into the same discovery some time ago. If I remember correctly, dd
didn't overwrite the content even with random data. It could behave
different for different firmware, but I tried a few with the same result.

Tomas

On Mar 7, 2018 9:13 AM, "wes"  wrote:

that's only if you want to generate a certain size. otherwise it just keeps
going until it runs out of blocks to fill.

-wes

On Tue, Mar 6, 2018 at 5:08 PM, Tim Garton  wrote:

> Don't you need a "count=#" option to dd as well? Not at a computer right
> now otherwise I'd be able to check if that's the case...
>
> On Mar 6, 2018 5:02 PM, "Richard England"  wrote:
>
> > On 03/06/2018 04:20 PM, Tomas Kuchta wrote:
> >
> >> Try to delete the original files first. Then create empty file using
> >> /dev/zero and copy it to the card. I bet that it will be there on the
> card
> >> and some of your original data will disappear as result.
> >>
> >> My guess is that the card controller is deduplicating your /dev/zero
> >> blocks
> >> trying to protect the card from writes.
> >>
> >> Tomas
> >>
> >> On Mar 6, 2018 7:09 PM, "Russell Senior" 
> >> wrote:
> >>
> >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior
> >>>  wrote:
> >>>
>  On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock 
>  wrote:
> 
> > My initial attempt to google this was unsuccessful (most people
point
> >> out the write protect tab, not my problem).
> >>
> >
> > Bad switch on the write protect tab? (The tab operates a tiny
> switch.)
> >
>  Nope.
> 
>  I can turn the switch to lock and it mounts the device read only very
>  clearly.  The behavior I observe is that it happily writes /dev/zero
>  over the block device, but then when I read again, the old data is
>  still present.
> 
> >>> For example, if I flip the tab to write protect tab to "Lock", I get
> >>> this:
> >>>
> >>> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M
> >>> dd: failed to open '/dev/sdc': Read-only file system
> >>> ___
> >>> PLUG mailing list
> >>> PLUG@pdxlinux.org
> >>> http://lists.pdxlinux.org/mailman/listinfo/plug
> >>>
> >>> ___
> >> PLUG mailing list
> >> PLUG@pdxlinux.org
> >> http://lists.pdxlinux.org/mailman/listinfo/plug
> >>
> >
> > |Perhaps using dd if=/dev/urandom |of=/dev/sdc status=progress bs=1M
> > ...just a thought.
> >
> > ___
> > PLUG mailing list
> > PLUG@pdxlinux.org
> > http://lists.pdxlinux.org/mailman/listinfo/plug
> >
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Weird microSD failure

[Russell Senior]

Worthy theories.

I tried deleting the files in the second partition (rootfs), the OS
said they were gone.  When I umounted, unplugged, replugged, they were
all there again.

I tried writing over the first 1.5GB of blocks (I got impatient and
control-C'd it after about 5 minutes) with /dev/urandom, sync'd,
unplugged, replugged, my partition table was intact, and my files in
rootfs were intact.

I think it is likely that the card controller is dysfunctional, but
why or how is a good question.

On Tue, Mar 6, 2018 at 5:12 PM, wes  wrote:
> that's only if you want to generate a certain size. otherwise it just keeps
> going until it runs out of blocks to fill.
>
> -wes
>
> On Tue, Mar 6, 2018 at 5:08 PM, Tim Garton  wrote:
>
>> Don't you need a "count=#" option to dd as well? Not at a computer right
>> now otherwise I'd be able to check if that's the case...
>>
>> On Mar 6, 2018 5:02 PM, "Richard England"  wrote:
>>
>> > On 03/06/2018 04:20 PM, Tomas Kuchta wrote:
>> >
>> >> Try to delete the original files first. Then create empty file using
>> >> /dev/zero and copy it to the card. I bet that it will be there on the
>> card
>> >> and some of your original data will disappear as result.
>> >>
>> >> My guess is that the card controller is deduplicating your /dev/zero
>> >> blocks
>> >> trying to protect the card from writes.
>> >>
>> >> Tomas
>> >>
>> >> On Mar 6, 2018 7:09 PM, "Russell Senior" 
>> >> wrote:
>> >>
>> >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior
>> >>>  wrote:
>> >>>
>>  On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock 
>>  wrote:
>> 
>> > My initial attempt to google this was unsuccessful (most people point
>> >> out the write protect tab, not my problem).
>> >>
>> >
>> > Bad switch on the write protect tab? (The tab operates a tiny
>> switch.)
>> >
>>  Nope.
>> 
>>  I can turn the switch to lock and it mounts the device read only very
>>  clearly.  The behavior I observe is that it happily writes /dev/zero
>>  over the block device, but then when I read again, the old data is
>>  still present.
>> 
>> >>> For example, if I flip the tab to write protect tab to "Lock", I get
>> >>> this:
>> >>>
>> >>> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M
>> >>> dd: failed to open '/dev/sdc': Read-only file system
>> >>> ___
>> >>> PLUG mailing list
>> >>> PLUG@pdxlinux.org
>> >>> http://lists.pdxlinux.org/mailman/listinfo/plug
>> >>>
>> >>> ___
>> >> PLUG mailing list
>> >> PLUG@pdxlinux.org
>> >> http://lists.pdxlinux.org/mailman/listinfo/plug
>> >>
>> >
>> > |Perhaps using dd if=/dev/urandom |of=/dev/sdc status=progress bs=1M
>> > ...just a thought.
>> >
>> > ___
>> > PLUG mailing list
>> > PLUG@pdxlinux.org
>> > http://lists.pdxlinux.org/mailman/listinfo/plug
>> >
>> ___
>> PLUG mailing list
>> PLUG@pdxlinux.org
>> http://lists.pdxlinux.org/mailman/listinfo/plug
>>
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Weird microSD failure

[Tomas Kuchta]

Try to delete the original files first. Then create empty file using
/dev/zero and copy it to the card. I bet that it will be there on the card
and some of your original data will disappear as result.

My guess is that the card controller is deduplicating your /dev/zero blocks
trying to protect the card from writes.

Tomas

On Mar 6, 2018 7:09 PM, "Russell Senior"  wrote:

> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior
>  wrote:
> > On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock  wrote:
> >>
> >>> My initial attempt to google this was unsuccessful (most people point
> >>> out the write protect tab, not my problem).
> >>
> >>
> >> Bad switch on the write protect tab? (The tab operates a tiny switch.)
> >
> > Nope.
> >
> > I can turn the switch to lock and it mounts the device read only very
> > clearly.  The behavior I observe is that it happily writes /dev/zero
> > over the block device, but then when I read again, the old data is
> > still present.
>
> For example, if I flip the tab to write protect tab to "Lock", I get this:
>
> # dd if=/dev/zero of=/dev/sdc status=progress bs=1M
> dd: failed to open '/dev/sdc': Read-only file system
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Serial communication with dmm

[wes]

Today I chanced upon "USPPcap" - a utility designed to capture traffic on
USB ports.

http://desowin.org/usbpcap/tour.html

It seems to me, since the Windows-based software for this thing works well,
and you have a USB->serial adapter, this utility could potentially be used
to monitor the traffic on a successful meter read, which could then be used
to re-create those steps in whatever other environment you'd like to use.

-wes

On Sun, Jan 7, 2018 at 5:13 PM, Denis Heidtmann 
wrote:

> The meter schematic I have shows two opto-isolators connected to the serial
> pins.  The output from the meter is an emitter follower driving the RxD pin
> and the emitter resistor connected to RTS.  The collector is connected to
> DTR.  The input to the meter drives an LED in series with a 3.3K resistor,
> TxD (+) to GND .  Does this explain the RTS being driven low?
>
> The protocol I have seen documented is:
>
> data format: 7n2 at 600 baud (7 bits, no parity, 2 stop bits).
> Control lines:
>DTR and RTS lines are used to power the TX line: RTS is clear
>for -12 supply; DTR is set for +12 supply. Data transmission is
>solicited sending whatever character to the RX line.
> Data string format:
>MAS-345 sends a 14 bytes string with:
>  < >< >
>:  two bytes with the oerating mode: DC, AC, OH, CA, TE ...
>:  one byte with - or space
>: five bytes with four digits and one decimal dot.
>: four bytes with the units: mV, A, kOhm, nF ...
>: '\r'
>One space is inserted between  and , one between
> and .
> The data string (without the '\r') is sent to the output device.
>
> The changes I made to the code to get some results were line 116 timeout
> changed from 0.1 to 3.0 and  commented out 129,  self.s.setTimeout(1) since
> it generated an error msg. indicating serial had no such object.   These
> changes gave me output if the meter was set at dc volts, otherwise an
> instruction to change it to dc volts.   Later I changed line 56 to make
> debug = True.  This gave me a listing of the what was coming from the meter
> (repeatedly), matching the above listing.
>
> So for starters I need to get it to poll the meter no more rapidly than
> 1/sec.  But I guess even in its wounded condition I could try to see if it
> will work with the usb-serial adapter.
>
> -Denis
>
> On Sun, Jan 7, 2018 at 2:18 PM, Denis Heidtmann  >
> wrote:
>
> > My goal is to be able to get data from the dmm using my laptop, which has
> > only USB.  I have an RS-232--USB adapter.  Eventually I want to make the
> > choices more friendly.
> >
> > Later today I will study the details of your observations.  The protocol
> I
> > have seen described elsewhere says the host needs to send a single byte
> > (H?) to get the dmm to send one reading.  I had to change two time values
> > and remove the setTimeout line to get it to work.  At present it locks
> the
> > meter for some time.  I expect that is because the host is sending bytes
> > too fast, causing the meter to try to respond before it is ready, a
> > difficulty I saw referenced in another description of how to deal with
> this
> > meter.
> >
> > Thanks for looking at the code.
> >
> > -Denis
> >
> > On Sun, Jan 7, 2018 at 12:35 PM, Galen Seitz 
> > wrote:
> >
> >> On 01/07/18 10:04, Denis Heidtmann wrote:
> >> >>
> >> >> On Mon, Jan 1, 2018 at 11:46 AM, Denis Heidtmann <
> >> >> denis.heidtm...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> I am looking into ways to examine the serial traffic to/from my dmm.
> >> >>
> >> > 
> >> >
> >> > I found a python script intended to interface with the mas-345:
> >> > https://github.com/markrages/py_test_interface
> >> > https://github.com/markrages/py_test_interface/blob/master/mas345.py
> >> >
> >> > I gave it a try on my desktop (which has a serial port).  To get it to
> >> run
> >> > I changed a couple of parameters and commented out one that was
> >> generating
> >> > a no-such-parameter error.  Then I put it into debug mode so I could
> see
> >> > the traffic from the meter.  The good news is it appears that the
> meter
> >> > does report values as the documented protocol indicates.  How the
> >> > communication is done is buried in the "serial" Python module. Someone
> >> who
> >> > understands Python could learn from this; I cannot.
> >>
> >> I've used the python serial module a few times.  Looking at that code, I
> >> see a few things that strike me as unusual.  First is RTS is
> >> cleared(line 125).  Normally both DTR and RTS would be set during serial
> >> communication.  The second thing is that the meter apparently requires
> >> the host to send 14 null characters(line 138) in order to cause it to
> >> send its measurement data.  Finally, requiring two stop bits(line 117)
> >> is unusual.  (Note that two stop bits and seven bit data is equivalent
> >> to one stop bit and including a mark parity bit in eight bit data.)
> >>
> >> Since its 

Re: [PLUG] Weird microSD failure

[Russell Senior]

On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior
 wrote:
> On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock  wrote:
>>
>>> My initial attempt to google this was unsuccessful (most people point
>>> out the write protect tab, not my problem).
>>
>>
>> Bad switch on the write protect tab? (The tab operates a tiny switch.)
>
> Nope.
>
> I can turn the switch to lock and it mounts the device read only very
> clearly.  The behavior I observe is that it happily writes /dev/zero
> over the block device, but then when I read again, the old data is
> still present.

For example, if I flip the tab to write protect tab to "Lock", I get this:

# dd if=/dev/zero of=/dev/sdc status=progress bs=1M
dd: failed to open '/dev/sdc': Read-only file system
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Weird microSD failure

[Russell Senior]

On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock  wrote:
>
>> My initial attempt to google this was unsuccessful (most people point
>> out the write protect tab, not my problem).
>
>
> Bad switch on the write protect tab? (The tab operates a tiny switch.)

Nope.

I can turn the switch to lock and it mounts the device read only very
clearly.  The behavior I observe is that it happily writes /dev/zero
over the block device, but then when I read again, the old data is
still present.

>
> thanks
> JK
>
>
>
> At 01:25 AM 3/6/2018, you wrote:
>>
>> I started playing with my Pine 64+ quad-core ARM64 board again
>> recently.  I have a 16GB Samsung EVO microSD card I was using
>> previously.  I started out by zero'ing it:
>>
>>   dd if=/dev/zero of=/dev/sdc bs=1M status=progress
>>
>> which seemed to finish fine.  But when I remove and re-insert it, it
>> still has data on it.  Double-U Tee Eff?  I have tried the same
>> process on three different machines with different methods of
>> connection (in an SD adapter in a USB-SD reader; in the SD adapter in
>> a laptop SD slot (probably still USB internally); and directly in a
>> microSD slot in a second laptop).
>>
>> I get no warning about being read only.  The writes seem to occur
>> successfully and fully complete.  I sync before I remove the media,
>> plug it back in and all the old data is still present.
>>
>> My initial attempt to google this was unsuccessful (most people point
>> out the write protect tab, not my problem).
>>
>> Any similar experience, and/or clues for recovery?
>>
>> Thanks in advance.
>>
>> --
>> Russell Senior
>> russ...@personaltelco.net
>> ___
>> PLUG mailing list
>> PLUG@pdxlinux.org
>> http://lists.pdxlinux.org/mailman/listinfo/plug
>
> ___
> PLUG mailing list
> PLUG@pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Re: [PLUG] Weird microSD failure

[Jim Karlock]

My initial attempt to google this was unsuccessful (most people point
out the write protect tab, not my problem).


Bad switch on the write protect tab? (The tab operates a tiny switch.)

thanks
JK


At 01:25 AM 3/6/2018, you wrote:

I started playing with my Pine 64+ quad-core ARM64 board again
recently.  I have a 16GB Samsung EVO microSD card I was using
previously.  I started out by zero'ing it:

  dd if=/dev/zero of=/dev/sdc bs=1M status=progress

which seemed to finish fine.  But when I remove and re-insert it, it
still has data on it.  Double-U Tee Eff?  I have tried the same
process on three different machines with different methods of
connection (in an SD adapter in a USB-SD reader; in the SD adapter in
a laptop SD slot (probably still USB internally); and directly in a
microSD slot in a second laptop).

I get no warning about being read only.  The writes seem to occur
successfully and fully complete.  I sync before I remove the media,
plug it back in and all the old data is still present.

My initial attempt to google this was unsuccessful (most people point
out the write protect tab, not my problem).

Any similar experience, and/or clues for recovery?

Thanks in advance.

--
Russell Senior
russ...@personaltelco.net
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

[PLUG] Weird microSD failure

[Russell Senior]

I started playing with my Pine 64+ quad-core ARM64 board again
recently.  I have a 16GB Samsung EVO microSD card I was using
previously.  I started out by zero'ing it:

  dd if=/dev/zero of=/dev/sdc bs=1M status=progress

which seemed to finish fine.  But when I remove and re-insert it, it
still has data on it.  Double-U Tee Eff?  I have tried the same
process on three different machines with different methods of
connection (in an SD adapter in a USB-SD reader; in the SD adapter in
a laptop SD slot (probably still USB internally); and directly in a
microSD slot in a second laptop).

I get no warning about being read only.  The writes seem to occur
successfully and fully complete.  I sync before I remove the media,
plug it back in and all the old data is still present.

My initial attempt to google this was unsuccessful (most people point
out the write protect tab, not my problem).

Any similar experience, and/or clues for recovery?

Thanks in advance.

-- 
Russell Senior
russ...@personaltelco.net
___
PLUG mailing list
PLUG@pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug