On 2/9/21 13:19, Chris Murphy wrote:
On Tue, Feb 9, 2021 at 10:23 AM pmkellly@xxxxxxxxxxxx
<pmkellly@xxxxxxxxxxxx> 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)
_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
