I just can’t properly install Fedora Kinoite and I don’t understand why.
I downloaded ISO from official site, checked signatures, checked SHA sums (probably rechecked 10 times already). Everything is OK.
Then I wrote ISO to USB flash drive using “dd” method, everything was fine.
But when I’m trying to install Fedora from USB it always gives me an error (after checking 100%) “The media check is complete, the result is: FAIL.”.
Since I don’t want to install new system from potentially compromised media, I tried many times more, with absolutely same results. I tried different completely new USB drive. Nothing changed.
I tried to write with Fedora Media Writer. No problem with writing, but absolutely the same error when trying to install.
I searched for solutions, found that such problems are not so rare, but people mainly blame Windows for accessing USB drive. But I use Ubuntu, auto-mount is disabled.
I tried to compare ISO with what is written on the flash drive, and this is the result I get consistently:
sudo cmp -n stat -c '%s' Fedora-Kinoite-ostree-x86_64-40-1.14.iso Fedora-Kinoite-ostree-x86_64-40-1.14.iso /dev/sdb
Fedora-Kinoite-ostree-x86_64-40-1.14.iso /dev/sdb differ: byte 4167659525, line 16177707
Any ideas how to solve this? Besides from not checking media at all, I would prefer not to ignore the possibility of malfunction.
The problem is that if you ever plug in the USB memory device in a running WIndows system, the contents of the USB device will be modified making the check fail.
Disk Fedora-Kinoite-ostree-x86_64-40-1.14.iso: 3,89 GiB, 4181080064 bytes, 8166172 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: CD3C786C-03B3-42DF-BE93-7B917BA38EE6
Device Start End Sectors Size Type
Fedora-Kinoite-ostree-x86_64-40-1.14.iso1 64 8139955 8139892 3,9G Microsoft basic data
Fedora-Kinoite-ostree-x86_64-40-1.14.iso2 8139956 8165507 25552 12,5M EFI System
Fedora-Kinoite-ostree-x86_64-40-1.14.iso3 8165508 8166107 600 300K Microsoft basic data
The second partition starts at byte offset 4167657472 == 8139956 * 512
The diff is at byte offset 4167659525, that is 2053 bytes into the fat file system, and also beyond the iso9660 file system in the first partition.
In conclusion, the first partition is intact and not modified, and that is where the install image is found.
The second partition may have been mounted at some point and perhaps not unmounted properly, or perhaps something else. If the system automounts USB devices, it might be a good idea to turn that off.
So now I understand that it gets modified when it inserted into target PC.
Because if I check USB after writing ISO on it, everything is OK. If I remove it and insert again into the machine running Ubuntu everything is still OK.
After I connect it to the target machine, even without starting media check, then remove and check media in Ubuntu, it gives me the same modification at the same place.
So it is probably happens at the BIOS level. I tried to turn off everything that possible, including secure boot - no luck.
Not an automount issue for sure.
I understand that this change probably won’t deeply affect new installation. But for some reason it gets modified.
I’m afraid that it might be BIOS malware or something similar.
Download page says
We take security seriously
Once you have downloaded an image, be sure to verify it for both security and integrity.
By calculating the image’s checksum on your own computer and comparing it to the original checksum, you can verify the image has not been tampered with or corrupted.
And I take this problem seriously and can’t just let it go, without proper explanation at least.
If the change is at the second partition, which is marked as EFI System, then it is possibly target PC EFI related issue.
Unfortunately, I don’t have Legacy Mode in BIOS.
Still not sure that this is normal situation.
There are various reasons why this could happen, including faulty hardware, firmware, and software.
You can try to isolate the issue as much as possible by using another live media like GParted Live or another PC not affected by this issue to create a Fedora live media.
Then reboot the problematic PC, navigate to BIOS/EFI, attach the Fedora live media, and boot it directly from BIOS/EFI to avoid involving the currently installed system.
If you do cmp with -l option you can also see the byte values (in octal) at the place where you get a difference. By default cmp stops at the first difference.
another PC not affected by this issue to create a Fedora live media
Definitely not the PC used to create media problem.
attach the Fedora live media, and try to boot it directly from BIOS/EFI to avoid involving the currently installed system
No installed system at all, and no option to boot directly from BIOS/EFI.
But after I tried to insert USB flash when BIOS menu was opened, and then checked media at the other machine, it got different already.
I used cmp with -l option. Should I share the result, is it of any use for someone? Because it is way above my expertise to understand what these bytes actually mean.
If possible, try to upgrade or reflash the BIOS/EFI firmware and reset its settings.
Over the years, many low level vulnerabilities have been discovered such as Spectre, Meltdown, Sinkclose, etc., so I wouldn’t be surprised if some of them could be utilized to install a persistent firmware level malware.
One more possibility is faulty RAM.
Also try using other Fedora images such as netinstall or server, but remember to keep the chain of trust in its general sense at each step.
I’m the type of person who believes that everything is compromised and backdoors everywhere, but actually this time I’m not sure that this is the case.
It is too stupid, for such a low level malware, to be detected at basic auto md5 hash check.
So, I tried to write random 5gb file on the same USB and then inserted it in the target PC, with BIOS menu opened, and even tried to boot from it. No changes detected with cmp after this.
Then I tried to write Ubuntu ISO on that USB, and it changed after I booted it (just install menu) on the target PC. And again, changes are in the region of the EFI partition, cmp -l shows slightly different bytes change, but somewhat similar to what I posted earlier.
Is it realistically possible to decipher what exactly changes knowing these bytes positions?
Probably it’s just something related to BIOS and EFI relations, but possibility of malware is still concerning.
It all depends on where the directory is located in the file system. That reflects on the FAT table which holds the pointers to the disk blocks of the directory.