On 2/9/21 18:11, Chris Murphy wrote:
On Tue, Feb 9, 2021 at 3:29 PM pmkellly@xxxxxxxxxxxx
<pmkellly@xxxxxxxxxxxx> wrote:
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.
It can distinguish between different kinds of problems.
I have no doubt, but the granularity of detecting faults on a formatted
and mounted storage device by writing files must be less than a pattern
test that does not use any preexisting disk data structure and the disk
is even dismounted when the test is run.
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.
The fake flash folks have gotten very good at faking seemingly legit
hardware down to the packaging. It's not so much reputable brand as it
is reputable reseller.
Yes, I fully understand and I always buy from the same reputable
retailer. The good news is that the thumb drive I use for installing
images for test passed both the f3 tests and the badblocks test.
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.
Well it's a bit needle in a haystack trying to track down transient
boot problems.
Well I certainly understand the problems with flash. However I don't
think they are quite as bad as that.
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.
Oh I thought you were booting from that same stick, but it had been
imaged with a different ISO. If the media is failing, the
manifestation of the failure can be different between uses.
I have one machine I use for testing (Lenovo M83 with i5-4570). I always
use that machine and I have been using the same thumb drive (Sandisk
16GB USB 3). As I said before I would guess that it has about 100 Fedora
Workstation Live install cycles on it. That's all that thumb drive gets
used for. There are no power cycles involved during an install. I do a
restart to get from the currently installed version on the system to
running from the new version on the thumb drive. When the Live part of
the install is complete, I use a restart to get from running Live to
running the newly installed version on the hard drive to complete the
install. I just pull out the thumb drive after Live is done and the
machine is getting ready to start BIOS/UEFI for the boot. My clue is the
monitor indicates that BIOS/UEFI has found the monitor but has not found
the disk drives yet. This is the procedure I have used since we started
using thumb drives with no issues. Come to think of it I used the same
procedure back when we used DVDs and again with no problems.
I have new thumb drives of the same make and model on hand. If I find
time, I will retrain myself to use "dd" in the CLI to write the ISO to
the thumb drive. I seem to recall it can be used for that. As long as I
see these failures to boot I will keep working on it to see if I can
come to a conclusion as if I need to change thumb drives more often,
report a bug against Media Writer, or report a bug against the ISO images.
A couple questions if I may. I've never taken the opportunity to look
into Media Writer. Is it just a GUI for dd or is it independent of dd?
If it's just a GUI for dd I guess their wouldn't be much benefit from
using dd directly. Second though I really doubt this would be the case,
but is Media Writer actively involved in telling any of the start up,
boot loader, etc lies you mentioned earlier, or are they just contained
in the ISO and Media Writer is not actively involved in them
Have a Hreat 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
