Check error with 20.04-desktop ISO

Asked by Lau on 2020-07-17

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 - https://releases.ubuntu.com/20.04/SHA256SUMS) 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

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Lau
Solved:
2020-07-18
Last query:
2020-07-18
Last reply:
Lau (lgautier) said : #1

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.

Lau (lgautier) said : #2
Lau (lgautier) said : #3

Closing

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.

Kai Kasurinen (kai-kasurinen) said : #5

maybe:

"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."
http://forums.debian.net/viewtopic.php?f=17&t=143422

Kai Kasurinen (kai-kasurinen) said : #6

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)

Or Rufus.... Works well. Super small

Kai Kasurinen (kai-kasurinen) said : #8

> 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?)?

Kai Kasurinen (kai-kasurinen) said : #9

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

Lau (lgautier) said : #10

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).

Lau (lgautier) said : #11

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) ?