[PLUG] Weird microSD failure
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
Re: [PLUG] Weird microSD failure
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
Re: [PLUG] Weird microSD failure
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
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] Serial communication with dmm
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 working with the python script, I suggest you continue using > >> python. It's no
Re: [PLUG] Weird microSD failure
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] Weird microSD failure
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
Re: [PLUG] Weird microSD failure
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
Re: [PLUG] Weird microSD failure
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
Re: [PLUG] Weird microSD failure
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
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
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
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
https://www.youtube.com/watch?v=r3GDPwIuRKI On Tue, Mar 6, 2018 at 8:22 PM, Russell Senior wrote: > 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