What I am trying to convey to you is that “sync” is never guaranteed. Ever.
garunteed?
What I am trying to convey to you is that “sync” is never guaranteed. Ever.
Where do you get this from. Reference?
Regards,
John
twou twou omwee tou twou. 
Jesus, do either of you do any independent reading on your own ?
“guaranteed” . . do a bit of googling on your own . . .
Well that escalated quickly.
I did the windows thing as an experiment. Basically nothing in Linux was working so I figured may as well.
From your symptoms, it sounds like your eMMC may be confused or borked,
probably with a bad sector or two somewhere. The on-chip controller is
supposed to deal with this gracefully, but in my experience error cases
are generally not well dealt with across the industry.
Try wiping the entire eMMC, specifically by discarding all blocks (this
tells the embedded eMMC controller it doesn't have to save the contents
of any blocks. Use the blkdiscard command (from Jessie) or format the
block device with ext4 (which performs a discard on all blocks) if
you're using wheezy.
Then try to dd to the entire device. If this fails, I suspect your eMMC
is bad.
Anyone else got a suggestion for testing/verifying the eMMC?
Jesus, do either of you do any independent reading on your own ?
“guaranteed” . . do a bit of googling on your own . . .
You make these statements and everyone is just going to believe you? If you are so sure of yourself, then back it up. The issue of disk cache isn’t applicable here since we are talking about an SDCard. So, with respect to SDCard, why is sync “never guaranteed. Ever”?
Regards,
John
So I have to thank everyone for the patience on this one. I did the mks.ext4 and that seemed to help but did not fix it. I bought a new sd card last night as that was the only variable I didnt chage other then the BBB.
Damn thing flashed first try. Thanks again. From now on new SD cards will be the first thing I try in errors like this.