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

Reply via email to