Check error with 20.04-desktop ISO

Asked by Lau

When using the ISO for Ubuntu 20.04 Desktop from bootable USB, the following message appears briefly at the end of the media check during boot.

Check finished: errors found in 1 files! You might encounter errors.

I checked the SHA256SUM (from here - for ISO, I tried creating the bootable USB with 3 different thumbdrives (2 different brands), and used either the Startup Disk Creator or Disks but the error does not go away.

Could the ISO be corrupted ? (and the checksum be calculated on the corrupted iso).

Note: The check during boot appears to be checking individual files (in the ISO) while the checksum verfied after downloading (and prior to creating the bootable USB) is for the ISO. The creation of the ISO and the calculation of its digest, and the check mechanisms for individual files in the ISO can be distinct processes, which would allow the creation of a corrupted ISO if being built from at least one corrupted subpart (file).

Question information

English Edit question
Ubuntu Edit question
No assignee Edit question
Solved by:
Last query:
Last reply:
Revision history for this message
Lau (lgautier) said :

The file md5sum.txt in the ISO contains the expected MD5 checksums every file so I checked all of them.

The file ./boot/grub/efi.img in the ISO is one file with a mismatching MD5 sum.

This means that either the md5sum.txt in the ISO is incorrect, or that file was tempered with before making it to the ISO.

Revision history for this message
Lau (lgautier) said :
Revision history for this message
Lau (lgautier) said :


Revision history for this message
actionparsnip (andrew-woodhead666) said :

If you use torrents rather than HTTP you'll get a good image. The torrent protocol checks the data as it is downloaded more than TCP (each chunk is checked). Once the download is completed a final check of all the data is completed. You'll probably get the data faster too as you'll be downloading from multiple sources.

Revision history for this message
Kai Kasurinen (kai-kasurinen) said :


"I've figured out why the verification failed each and every time I wrote the image from Windows system. It's because Windows write System Volume Information on any filesystem it can understand (EFI boot partition in this case) which causes the checksum to fail. Conclusion? Win32DiskImager and Etcher work the way they should in making installation media on Windows. Just don't count for any built-in verification tool to pass as Windows may add the aforementioned file to any filesystem it understands which ultimately changes the checksum of the image."

Revision history for this message
Kai Kasurinen (kai-kasurinen) said :

Ah, not Windows. What version Startup Disk Creator? (Older versions seems alter grub; 0.3.0 has reworked whole imaging process for writing to devices)

Revision history for this message
actionparsnip (andrew-woodhead666) said :

Or Rufus.... Works well. Super small

Revision history for this message
Kai Kasurinen (kai-kasurinen) said :

> Could the ISO be corrupted ?

probably no

e5b72e9cfe20988991c9cd87bde43c0b691e3b67b01f76d23f8150615883ce11 ubuntu-20.04-desktop-amd64.iso

md5sum -c md5sum.txt -> all OK

efi.img is vfat image, content: md5sum efi/boot/* f7a57b08bc7c1c85417ae4cea582d1d4 efi/boot/bootx64.efi
109e2fc4aa9786cd887ed6f95c485951 efi/boot/grubx64.efi
4487628005555bfd4a4c0a47211e0700 efi/boot/mmx64.efi

Maybe your efi.img is altered when you created bootable usb drive or when you booted usb drive (by bios?)?

Revision history for this message
Kai Kasurinen (kai-kasurinen) said :

qemu with OVMF.fd bios also modifies efi.img - empty NvVars file created

Revision history for this message
Lau (lgautier) said :

My mistake. I had the ISO mounted as disk but also the USB still plugged. I ran `md5sum -c` in the wrong mount point.

The ISO is fine.

A freshly created Bootable USB is fine (created with Startup Disk Creator).

This points out to what you suggested: the content of the USB is modified the first time I boot with it (either the BIOS, or Live Ubuntu itself).

Revision history for this message
Lau (lgautier) said :

Doesn't this make the current check at boot time pointless ?

Should efi.img be excluded from the checks, or if the modification of the efi is known and always the same an alternative checksum should also be included (so at at boot-time it check that efi.img has one of the two checksums) ?