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 myh
Would it help to add iflag=direct and/or oflag=direct?
-T
On Tue, May 1, 2018, 2:42 PM Russell Senior
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)
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 ma
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 cl
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 pre
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
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 trie
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,
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
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 usi
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 deduplicati
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
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
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 mou
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
15 matches
Mail list logo
