See linked issue. Downloaded latest Fedora Kinoite x86_64 ISO on Windows using Chrome https://download.fedoraproject.org/pub/fedora/linux/releases/39/Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-39-1.5.iso flashed it to a usb stick with fedora media writer on windows 11 booted, did the verification check, it failed. Rebooted and installed, it works normally. Opening this bug as it was said to be not reproducible.
I can confirm this. This only happens on the latest version of FMW on Windows Only though. works fine with the Linux version (No idea about MacOS). https://github.com/FedoraQt/MediaWriter/issues/669
It fails the validation check but still installs properly if you skip that check? Can you confirm if the problem appears on Fedora Workstation or Fedora KDE install media?
Proposed as a Blocker for 40-beta by Fedora user sgallagh using the blocker tracking app because: Beta Criterion: "Release-blocking live and dedicated installer images must boot when written to a USB stick with any of the officially supported methods." Officially supported methods includes the Windows Fedora Media Writer tool.
I took the safest route to reproduce this: 1- Downloaded the freely available Fedora 39 iso downloadable from https://fedoraproject.org/workstation/download (Use the Torrent download) 2- Booted into Windows (Bare metal, not VM) 3- Downloaded FMW from the link in #1, installed. Burned the image onto USB. 4- Booted (Again, baremetal) into the usb flash drive, did a media test. Failed.
Created attachment 2021428 [details] Failed test
Just to confirm: does the installer itself run to completion if you skip the media check?
Hi, I think this is a long-standing issue, it was most like present for past couple Fedora releases. I'm afraid that fix for this and some other related issues (like drive restoration on Windows) would require a rewrite of how we write images on Windows using Windows API. This is something I have zero experience with, not to mention that I don't have capacity to work on this in the near future. Fedora Media Writer used to have a full time developer working on it, before it went under my maintanence and it didn't really change much internally (except UI-wise) since then. There are definitely technical depts in some areas. Another issue is that even if we fix this, we won't get an official binary published on getfedora.org, because we are not signing Windows binaries since last year, after a certificate we used to have expired and signing of Windows binaries got more complex. I'm open to review PRs if someone decides to fix this issue, but I'm afraid that's the only thing I can promise you right now.
(In reply to Stephen Gallagher from comment #6) > Just to confirm: does the installer itself run to completion if you skip the > media check? Checking into that now
(In reply to Stephen Gallagher from comment #6) > Just to confirm: does the installer itself run to completion if you skip the > media check? So, I installed this on a VM, and booted from it. Went through setup, everything seems to have worked fine.
Just to triple check, I also booted from the USB drive and tested the media. It did still fail.
(In reply to Steve Cossette from comment #1) > No idea about MacOS FMW works as expected on MacOS and the media check result is PASS.
Yeah interestingly enough, I tried to burn the workstation image using Rufus in Windows. First, I tried to write the image in "ISO mode" and it complained it didn't have a copy of our custom grub version. So I instead burned it in DD mode, and it succeeded. But, booting from the image still results in a fail at 4.8% which is odd.
I've tested FMW 5.0.6 (the official stable version from getfedora.org) on Windows 11, I've written both F39 Workstation Live and F40 Workstation Live Beta RC 1.2, and both pass checkisomd5 just fine. So this is NOT an universal issue, just to make that clear. On the other hand, I've seen 4.8% errors even on Fedora in the past. My assumption is that it happens when some partition gets automounted and some filesystem metadata change (and then the whole checksum changes). (In reply to Jan Grulich from comment #7) > Fedora Media Writer used to have a full time developer Slightly off topic, but on my Win11, I had to burn each image twice, the first write attempt always failed after a while. FMW will bit-rot more and more, if we don't resolve staffing and certificate signing.
Someone on the Fedora Discord called Yuu says this might have to do with USB automount on Windows disabling automount and flashing a USB should hopefully then create one that passes the checksum test no idea what that means myself as i rarely use Windows
Discussed at 2024-03-14 Fedora Beta Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/teams/f40-beta-go-no-go-meeting/f40-beta-go-no-go-meeting.2024-03-14-17.01.html . Rejected as a blocker on the basis that it doesn't entirely violate the criteria (it is possible to write a bootable image) and it is complex to fix for various reasons outlined above.
I believe that Yuu fellow is correct: some time ago, I forgot to unplug a Fedora USB drive before booting into a W10 installation, and the media check started to fail exactly at 4.8%; apparently, Windows tries to automount everything with wild abandon (even if you never get past the login screen), and instantly writes some hidden garbage on the connected disks, which ends up breaking the media check. See also: https://superuser.com/questions/1199823/how-to-prevent-creation-of-system-volume-information-folder-in-windows-10-for
I can verify that this is most certainly an error with Windows and not Fedora Disk Writer. I was having the same issue and out of curiosity made the following test after seeing this bug report. I created a new disk using disk writer on my computer running fedora and then booted from it on the windows machine I was originally trying to install on. It then passes the check. After rebooting in to Windows 10, and then trying to boot from the disk once more causes it to fail.
It just happened to me today, once, after creating the image using FMW on Fedora 40. So as I said before, this is not OS-specific. But on some OSes the likelihood might be higher.
*** Bug 2275270 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Seems like this has nothing to do with the Fedora release at all. Not sure we really need a Fedora bugzilla bug for it, maybe we could close this and track it upstream?
I hope this is fixed with the new Fedora Media Writer on Windows.
@jgrulich TL;DR: I urge you to reopen this bug report. It cannot fixed with Fedora Media Writer as it affects *any* bootable Fedora created in Windows (also with Rufus, Balena Etcher, ...). Thus, the component that does the media check should be made robust against whatever Windows does to the medium. Furthermore, I suggest that you treat this as a high priority issue, as migrating from Windows is a very common use case and the very first impression (to-be) users get from this distribution. I'll summarize the currently known information about this issue below: On booting from a pen drive, Fedora by default runs a media check to ensure the volume's consistency. If the bootable pendrive has been created from Windows with any software, users frequently report that the media check fails at exactly 4.8%. Some users report that turning off the (by default on) "Autoplay" feature in Windows solved the issue for them but I can personally confirm that this doesn't always mitigate the issue. Other users report that turning off automount in diskpart did the trick. In summary, some feature It is not entirely known what Windows exactly does to the bootable media that makes the media check fail, but it has been mentioned that Windows may add a file (to any media it mounts) for indexing. If that is the case, a simple mitigation for this issue would be to either ignore that file, or, to be more general, rewrite the media check so that it only checks the files that are actually included in the distribution. Note that a Windows user wanting to change over to Fedora is a very common use case. Installing from a bootable pendrive is the very first thing a new Linux user is going to see. Having a media check that fails by default when coming from Windows scares new users away and is worse than not having any media check at all. Microsoft will not change this behavior, even if from a purists point of view one might argue that the blame might lie with Windows. At the moment, the implementation of the media check should simply be considered not adequate for this real-world scenario. See also the discussion in https://github.com/FedoraQt/MediaWriter/issues/669 and various reddit threads, the most informative being https://www.reddit.com/r/Fedora/comments/11r7gi8/fedora_media_check_fails_at_48_every_time_during/
Since this is already tracked at https://github.com/FedoraQt/MediaWriter/issues/669#issue-1988817042, I don't see a need to keep this open. https://pagure.io/fedora-kde/SIG/issue/482 has already been closed with deferred to upstream.
I have explained in my prior message why I believe the issue 1. cannot be fixed at FedoraQt/MediaWriter as the same happens when using other software to create the image on Windows, i.e. it is not an issue of FedoraQt/MediaWriter and hence CLOSED UPSTREAM is incorrect 2. it is unrealistic to assume Microsoft will do anything about it, for all we know they might consider this a feature, not a bug I have nothing more to say on this issue.
Don't ever say “I have nothing more to say.” We can speak like adults; I'm going to ignore it as something said in a moment of emotion. Regarding the topic at hand, being closed as UPSTREAM is applicable in this circumstance precisely because it's tracked at FMW's GitHub instance. If the issue were with the way that it was packaged in a RH OS, like Fedora, that would be the purview of this issue. Tracking something more broad is more-so applicable to the closed SIG issue. However, because we can report this to Microsoft, these closure reasons are likely accurate. Your unsubstantiated presumption that Microsoft would consider this to be a feature is not something that we can debate, nor something would modify the decision to close this issue.
This is probably my second comment ever and I am no developer, so I really have no idea about any of this. But the problem seems to be where this bug should be filed? It is obviously caused by the way Windows handles removable media. That suggests the bug should be reported to Microsoft. Will they care? From their point of view nothing is most likely even broken. It is safe to assume that whatever is done to the removable media is part of a feature in Windows. If Microsoft (as several of us believe) don't care about this, what can be done about it? If it is possible to block Windows from altering the boot media it might be possible to do in FMW. That would still not solve the problem when the boot media is created in any other way. Only solution I see is a workaround in how the media check is performed so that it detects if the media have been altered by Windows and react in an appropriate manner. As long as this is the only thing "wrong" it might be safe to continue? I don't think there is any more I can do about any of this. I just feel it is sad if people are scared away from Fedora because of a failed media check on their first try.
Well said.
I checked and there do exist thumb drives with a write protect switch, but they're expensive.
*** Bug 2412714 has been marked as a duplicate of this bug. ***