On 2/9/21 13:19, Chris Murphy wrote:
On Tue, Feb 9, 2021 at 10:23 AM pmkellly@frontier.com pmkellly@frontier.com wrote:
I've seen several ISOs lately that after they were written to a thumb drive using media writer they wouldn't boot. I won't be recounting the details I sent in prior motes to @test, but here is a little more information.
The last one I tried was Workstation Live 0207.n.0. It failed to boot initially, but I rewrote the same downloaded image to the same thumb drive with Media Writer again. After that it would boot. This might raise the possibility that Media Writer is involved with the boot problems. I guess I'll just keep track of this from now on.
I have been using the same thumb drive plugged into the same USB port all along. Today just for grins I ran badblocks on the thumb drive and no bad blocks were found. "badblocks -w -s -o Thumberror.log /dev/sdb)"
I would use f3. The gist is format the USB stick (file system doesn't matter) and mount it. Then
sudo f3write /mnt sudo f3read /mnt
Actually f3 is part of the Fedora repos now. I decided to use badblocks because I understand it's tests. It's the same basic tests I run on a new board prototype when there is ram or flash on the board. Besides testing the memory, it allows me to check the address and data buses too. Though this does not apply when testing a USB Flash decvice.
As I understand f3 it just writes files to the flash and reads them back checking for errors. I'll go ahead and try f3 on the same thumb drive.
I see that the file size is constant at 1.1GB except for the last one where it just uses up the left over space. There are 14 files of 1.1GB and 1 file of 5xxMB. so the size checked out. I'm wondering if they pick the file size based on the flash block size. That can make a difference testing flash. I checked out github to see if there is more info there. From what I read f3 seems to only verify size and basic functionality. I think badblocks with it's pattern testing is more likely to find problems. In any case f3read has finish running and pronounced my thumb drive I use for installs to be free of problems. The same result I got from badblocks.
But the thing is, transient errors from USB sticks is a real thing. Also, I once had a USB stick that would transiently corrupt on writes if the dd bs size was too high. I forget the value. But somehow it'd either lose writes or reorder them, and I'd get a completely bootable USB stick but it'd spew piles of file system errors during the installation.
https://github.com/AltraMayor/f3 https://fight-flash-fraud.readthedocs.io/en/latest/
Well I only use Flash from reputable manufacturers and though I never trust any single flash drive with anything important they have provided good results for me. Also, it's not clear that the flash drive is the problem in this case.
Way beyond flash drive fraud. Flash drives, especially the NOR types which seem to be the most common have a few error modes. Though some manufacturers advertise they have new designs good for millions of write cycles. Most of those available now only do about 100K cycles. Following my de-rating rules I never implement flash in any case where more than 50K cycles will be required. An install ISO puts a lot of data on the thumb drive. Then there are the wear leveling strategies to take into account to work out how all the spare blocks get used etc. Estimating the number of Live install cycles a thumb drive should be relied on will be hard and mostly guess work. Even so I would think they should be good for a thousand installs. This thumb drive only has about a hundred on it.
Another failure mode is that reads in adjacent cells can flip bits in other cells. They can also be sensitive to x-ray, and em fields depending on flux density.
We could go back to using DVDs for testing or perhaps use net install. I think I'd pass on both of those.
If it turned out that thumb drives were the issue. I guess we'd just have to change to a new thumb drive more frequently, but right now with the good test results I got on my thumb drive I don't think that will be necessary. I guess the two suspects for now are the ISO image's boot stuff, and Media Writer.
Side note: With 0207 I once again encountered the white screen sad face. when I rebooted after the initial install to do the complete the install tasks. The complete the install windows popped up on top of the sad face and I was able to coomplete the install. I did a restart after completing the install. The restart ran normally and I have seen no problems. Though I havent tested 0207 extensively. I'll get started again when Branched F34 is available.
This could also be transient corruptions on read. USB sticks notoriously do not report discrete read errors, they just return bad data.
Well I don't have my thumb drive plugged into my test machine when power up or down. Restarts do not change the power supply state. At least that's the case on my Lenovo machines. My work area is fully static protected. I really doubt the +5VDC supply in my test machine is producing any transients. There would be other highly observable effects. Though with some trouble I could get a scope and monitor it if someone believes that might be the trouble.
Have a Great Day!
Pat (tablepc)