Here is an another mention of that problem, posted 8 months ago:
https://www.reddit.com/r/Fedora/comments/11r7gi8/fedora_media_check_fails_at_48_every_time_during/

Fun fact — if I choose a non-default option to run Fedora Live without media check then it does run successfully.

I verified the ISO file downloaded by Media Writer with this commands in my WSL2:

curl -O https://fedoraproject.org/fedora.gpg
gpgv --keyring ./fedora.gpg Fedora-Workstation-39-1.5-x86_64-CHECKSUM
sha256sum -c Fedora-Workstation-39-1.5-x86_64-CHECKSUM

The output says:

Fedora-Workstation-Live-x86_64-39-1.5.iso: OK
sha256sum: WARNING: 19 lines are improperly formatted

Could these improperly formatted lines be the problem?

EDITED: The answer is no — manually downloaded with Google Chrome ISO from the official site has the same 19 improperly formatted lines.

I am also getting the same failure in the media check after booting the USB made with Fedora Media Writer. The failure happens at the same point as you mentioned - 4.8%

My environment:

• Windows 10 Pro (x64, 22H2)
• Fedora Media Writer 5.0.6
• generic 16GB USB 2.0 drive
• ISO Fedora-Silverblue-ostree-x86_64-39-1.5.iso
• ISO sha256sum confirmed OK

Similar reports of the issue:

• https://www.reddit.com/r/Fedora/comments/11r7gi8/fedora_media_check_fails_at_48_every_time_during/
• https://www.reddit.com/r/Fedora/comments/zlzxhs/fedora_always_fails_at_0048_on_test_image_and/
• https://www.reddit.com/r/Fedora/comments/1xgdkh/fedora_media_verification_fails_at_48/
• https://bugzilla.redhat.com/show_bug.cgi?id=1282244
  There are some suggestions that the OS (Windows or macOS) performing file indexing is modifying the drive contents in a way that disrupts the media check.

A workaround I used is to download an ISO file manually and use Rufus to create a bootable USB stick.

I've had a failed media check when using the 5.0.9 win64 release with either F38 or F39 workstation (downloaded through Firefox). It was the only time I tried that release and its possible my media check failure could have happened from something unrelated, but I've used and continue using the latest dev/pre-release version (Oct 25, 2023) without issue and haven't seen any failed checks, including a few hours ago today with F39 Workstation. I recently replaced bad RAM and can't rule that out as a reason for the bad media write.

I flash downloaded images from Firefox or aria2c with MediaWriter on Windows 10 LTSC 21H2 to a 1TB external HDD and Indexing disabled (removed the whole Search service). I never tried downloading an image from MediaWriter itself.

Update: I've been using Etcher for a while now on Windows and have had zero bad media checks with many F40 image writes; it's what I use for everything needing a dd'd image on Windows now.

Right mine's also failing, but only using the Windows version (Latest)

Backlink to the fedora bug (Proposed as a release blocker): https://bugzilla.redhat.com/show_bug.cgi?id=2269373

Mine also failed on 4.8% exactly... I also got the same "failed to start" message. I just download the ISO and used dd to copy it to my USB Stick.

This sometimes happens even outside of Windows, but might be seen the most there. A common issue description is here:
https://discussion.fedoraproject.org/t/install-media-sometimes-fail-media-check-at-4-8/108478

This is not unique to media writer or Windows. I have produced USB stick with Balena Etcher on both macOS and windows and I have the same issue. ISO file checksum OK.

This is not unique to media writer or Windows. I have produced USB stick with Balena Etcher on both macOS and windows and I have the same issue. ISO file checksum OK.

Just a bad USB, but failing on 4.8% on two instances can't be a coincidence.

Thanks for the thumbs down and assuming I didn't do my homework. And nope, 3 different USB sticks and portable USB HDD on two different machines and same 4.8% failure in all instances. It's most definitely not a "bad USB stick". Yes, again, ISO checksums OK in all instances.

Congratulations on killing the readability of this issue. @grulja you might want to take some action, like hiding all the recent comments, or similar.

Please file different problems as separate tickets. This one is strictly related to the 4.8% verification fail issue. All other conversation should be elsewhere.

#669 (comment)

This issue is not limited to media creation under Windows. See my earlier comments.

@sbagneris, do you know what version of Balena Etcher reproduced this? The sole corroboration I see of this is at r/NobaraProject/comments/1334kr9, ¹ unless forums.balena.io/t/36537/80 also refers to the same. If not, you might assist if you report this issue to Balena's GitHub, too. Perhaps, both packages utilise a problematic library.

I downloaded the latest version of balena etcher for x64 linux (2.1.4) along with the latest fedora 43 iso and burned the lot on my arch whatever laptop. Booted the USB and same error at 4.8% validation. The issue is agnostic of OS or image writer.

Unlikely hardware. I have attempted this accross half a dozen USB sticks and a few external HDD's on various target machine and the result is the same in every case: failure at 4.8%.

Just for kicks I wrote the iso to USB with dd. No fancy tool here. Same result. Failure at 4.8%. If you want I'll drag a DVD burner and do it like it's 2004 and burn it on a coaster but I suspect the outcome like in every case is going to be the exact same.

It's not Windows, it's not Balena, it's not the phase of the moon or the size of your left shoe. Something is fundamentally wrong with either the way the iso are created or the piece of code that does the checking.

Unlikely hardware. I have attempted this accross half a dozen USB sticks and a few external HDD's on various target machine and the result is the same in every case: failure at 4.8%.

Just for kicks I wrote the iso to USB with dd. No fancy tool here. Same result. Failure at 4.8%. If you want I'll drag a DVD burner and do it like it's 2004 and burn it on a coaster but I suspect the outcome like in every case is going to be the exact same.

It's not Windows, it's not Balena, it's not the phase of the moon or the size of your left shoe. Something is fundamentally wrong with either the way the iso are created or the piece of code that does the checking.

Either Balena used part of the Fedora application code and carried over the bugs (I'm skeptical about that) or the problem is actually with the way the Fedora ISO is built. I've never had this problem with ISOs from other distributions! I vote for the problem being that the Fedora ISO is poorly constructed!

@GabrielMGitHub, that'd make sense. Where would one report a bug with the ISO creation process? It's not Media Writer's purview, since the ISOs are merely downloaded via it, and are available elsewhere.

@GabrielMGitHub, that'd make sense. Where would one report a bug with the ISO creation process? It's not Media Writer's purview, since the ISOs are merely downloaded via it, and are available elsewhere.

Whenever I tried to download an ISO using Fedora Media Writer, I encountered problems. Now I go to the Fedora website and download the ISO directly, then I verify the SHA256 checksum. Only after that do I use Fedora Media Writer to write the image.

The problem should first be reported as if the issue were with Fedora Media Writer; the developers should verify and conduct their test cases, conclude that the problem is with the ISO, and then report it to the Fedora team. This is not the job of the end users.

If the problem occurs when using Fedora Media Writer, the user cannot independently determine whether the problem lies with the ISO file or not, or whether it's definitely a problem with Fedora Media Writer. The user reports what they see; they don't have the power to guess.

I have a degree in computer science, and one of my postgraduate degrees is in Software Project Management. Your way of thinking is completely wrong!

Does the Fedora Media Writer tool generate logs? If so, please provide the path for users to attach this data. If possible, create a test routine that the user can perform using the tool and then report the output of this test. If the tool does not generate logs, and there is no way to perform practical tests, I believe the tool needs to be rewritten or discontinued due to its inefficiency in generating debug triggers.

Why don't you create a question with the team that develops the Fedora ISO creation tool and include a link to this discussion or other existing ones as a reference? This way, they will be aware of the issue and could work together. This responsibility should not be in the hands of the end user, but of the Fedora Media Writer developers.

My words here are not intended to offend anyone, but merely to bring reality to the table in the interest of reaching a conclusion and, based on that, identifying the root cause of the problem.

Whenever I tried to download an ISO using Fedora Media Writer, I encountered problems. Now I go to the Fedora website and download the ISO directly, then I verify the SHA256 checksum. Only after that do I use Fedora Media Writer to write the image.

@GabrielMGitHub, so it solely occurs with ISOs downloaded via FMW? @sbagneris, is that what you did when you tested Balena; downloaded the ISO via FMW, then wrote it with Balena? If not, this information appears contradictory, hence my confusion.

I have a degree in computer science, and one of my postgraduate degrees is in Software Project Management. Your way of thinking is completely wrong!

I don't know what you're referring to, nor why you informed, presumably me, of this.

Thank you to everyone for the detailed testing. The evidence that multiple tools (Balena Etcher, dd, Fedora Media Writer) and different operating systems all fail consistently at the 4.8% validation point strongly suggests the issue lies either in:

• The Fedora ISO file structure/creation process itself.

• A common validation library used by these tools.

Since the problem is agnostic to the writing tool, reporting this to the Fedora ISO or QA team is the highest-leverage next step, as they control the source file.

@RokeJulianLockhart, would you be willing to search for the official Fedora bug reporting channel for ISO/QA issues so we can move this from discussion to official action?

I'm going to lock the conversation now as it's not going anywhere. The issue here is caused by Windows auto-mounting the device after we write an image to it and modifies the content, creating some files on the device, making it to later fail the checksum. I'm planning to look into this to see whether there is anything we can do about it, but it is certainly not an issue in the Fedora images or any other library used for the validation.