Well, since I fixed it for the time being by rebooting, I can't test it. I kind of doubt it, but it's something I'll try next time. My currently theory is that it has to do with udev, systemd and udisksd. I saw some weird messages about /dev/disks/by-label conflicting.
[...] May 01 02:36:21 myhost systemd[1446]: dev-disk-by\x2dlabel-waggywag\x5cx202.12\x5cx20\x2d\x5cx2020170418.device: Dev dev-disk-by\x2dlabel-waggywag\x5cx202.12\x5cx20\x2d\x5cx2020170418.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:1c.6/0000:03:00.0/usb3/3-1/3-1.4/3-1.4:1.0/host9/target9:0:0/9:0:0:0/block/sdc and /sys/devices/pci0000:00/0000:00:1c.6/0000:03:00.0/usb3/3-1/3-1.4/3-1.4:1.0/host9/target9:0:0/9:0:0:0/block/sdc/sdc1 [...] On Tue, May 1, 2018 at 10:17 PM, Tomas Kuchta <[email protected]> wrote: > Would it help to add iflag=direct and/or oflag=direct? > > -T > > On Tue, May 1, 2018, 2:42 PM Russell Senior <[email protected]> > wrote: > > > Followup on this, I noticed it again last night on multiple USB > > thumbdrives. A dd to the device immediately succeeds (which is weird in > > itself for large writes of iso sized blobs), but unplugging-replugging > > shows the writes didn't actually happen. The problem was persistent > until I > > rebooted the machine and it started working normally again. Very weird. I > > think the microSD was probably fine and the hosage was at the USB or > > something other than the hardware level. It might be related to > unplugging > > a mounted device at some point. Any ideas are welcome. > > > > On Tue, Mar 6, 2018 at 8:29 PM, Russell Senior < > [email protected]> > > wrote: > > > > > https://www.youtube.com/watch?v=r3GDPwIuRKI > > > > > > On Tue, Mar 6, 2018 at 8:22 PM, Russell Senior > > > <[email protected]> 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 > > > > <[email protected]> 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, [email protected] 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" <[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 > > > > > _______________________________________________ > > 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
