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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> >> >> wrote: >> >> >> >> On Tue, Mar 6, 2018 at 3:04 AM, Russell Senior >> >>> <[email protected]> wrote: >> >>> >> >>>> On Tue, Mar 6, 2018 at 3:01 AM, Jim Karlock <[email protected]> >> >>>> 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 >> >>> [email protected] >> >>> http://lists.pdxlinux.org/mailman/listinfo/plug >> >>> >> >>> _______________________________________________ >> >> PLUG mailing list >> >> [email protected] >> >> 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 >> > [email protected] >> > http://lists.pdxlinux.org/mailman/listinfo/plug >> > >> _______________________________________________ >> PLUG mailing list >> [email protected] >> http://lists.pdxlinux.org/mailman/listinfo/plug >> > _______________________________________________ > PLUG mailing list > [email protected] > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
