This is a discussion topic for the following Common Issue:
You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.
If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.
Please see the Common Issue for solution/workarounds:
If you insert a USB drive into a Windows machine, Windows will create a hidden directory. It’s called “System Volume Information” IIRC. That hidden directory does happen to cause the same behavior that you’re describing.
Could this be fixed by setting the partition type to something other than “Microsoft basic data”?
fdisk -l of the iso image shows:
Disk Fedora-Xfce-Live-x86_64-39-1.5.iso: 1,59 GiB, 1712130048 bytes, 3344004 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: AC768486-64A1-4EA9-A3F7-E81C65A76AFD
Device Start End Sectors Size Type
Fedora-Xfce-Live-x86_64-39-1.5.iso1 64 3319495 3319432 1,6G Microsoft basic data
Fedora-Xfce-Live-x86_64-39-1.5.iso2 3319496 3343339 23844 11,6M EFI System
Fedora-Xfce-Live-x86_64-39-1.5.iso3 3343340 3343939 600 300K Microsoft basic data
Which is exactly why a usb containing an iso install image should never be reconnected to a windows machine once the image has been written to the device. Linux does not modify the usb device (iso9660 image) when mounting the device but windows does add the extra info.
Honestly, I think the answer is to have the live usb media test check for the hidden directory that Windows injects, and remove the directory (if it exists) before doing the checksum. The directory is just some index metadata to help with performance on Windows. Removing it is 100% fine, and would probably prevent non-technical users from thinking there is a security issue with the Fedora installer.
It would still leave permanent changes in the file system. For example you can’t expect that the FAT table will be restored to the original contents, and the area from the removed file being restored to the previous bit pattern.
Yes, that happens on regular data drives. But at least in my case (pretty default Win11), the OS can’t read any of the partitions on the created flash drive (clicking on those partitions pops up a question to format it), so it doesn’t automount it and it doesn’t create those directories in there. So this affects just some people, and we don’t know why.
It could be a good idea. Please discuss in the upstream FMW ticket with developers, thanks!
Im new to linux i havent even installed it yet. was searching for error i was geting.
and sorry for bad English skills, I’m working on it.
Media Writer produces USB stick with FAIL media check · Issue #669 · FedoraQt/MediaWriter · GitHub I had a checksum error with a newer Fedora Media Writer on Windows, didn’t have it on the version before that, but can’t exactly rule out any other oddity. But that October pre-release version before 5.0.9 is my go-to if I’m using Fedora’s media writer on Windows.
Rufus two days ago even when writting the F40 iso in dd mode still gave me a 4% checksum error. Doubt I’ll be using it ever again.
Etcher is my main go-to on Windows and so far has written images flawlessly. Linux I just dd also without any problem.
I didn’t read much above this post, but why would Windows be allowed to be able to read the disk Fedora (or other Linux isos) are directly-written to? Afaik it’s only Rufus that offers something different than dd by-default, and I even had their dd mode fail 2 days ago which makes me question who even bothers with it (Ether is more recommended by distros, and Windows images already can be written with FAT32/NTFS without a tool).
If iso are dd’d, they shouldn’t be readable by Windows, and shouldn’t have any files created or modified afaik. From a security standpoint, I’d rather a Linux distro’s media check be validated with the files they provided from the iso and nothing else; rogue Windows files shouldn’t be a part of that, and should flag since there’s no telling what those files are or do. Files that are whitelisted can be used for payloads.
LOL! Blame everything but the math… Checksum fails = file is corrupt. I’ve used different flavors of linux for years and thought I’d give Fedora a shot. I’ve tried multiple OS - everything I can think of. Suspicions confirmed. Redhat is compromised. Stay away from Fedora
The problem occurs randomly (for some more often than for others) regardless of your host system. It happens when writing the image from Windows as well. It happens when using different writing tools, some of them completely unrelated to Fedora/Red Hat. They are just writing a data image, they don’t execute any code from it, and still it sometimes gets a 4.8% checksome fail (you don’t even need to boot the image to verify the checksum). So your “Red Hat is compromised” theory doesn’t really check out. Perhaps “the whole world is compromised”… or something touches the image after being written. Pick your favorite, I’m not going to argue any further.
