https://www.youtube.com/watch?v=r3GDPwIuRKI
On Tue, Mar 6, 2018 at 8:22 PM, Russell Senior <russ...@personaltelco.net> 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 > <tomas.kuchta.li...@gmail.com> 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" <p...@the-wes.com> 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 <garton....@gmail.com> 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" <rlengl...@frontier.com> >>> 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" <russ...@personaltelco.net> >>> > >> wrote: >>> > >> >>> > >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior >>> > >>> <russ...@personaltelco.net> wrote: >>> > >>> >>> > >>>> On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock <jjkarl...@gmail.com> >>> > >>>> 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