Check error with 20.04-desktop ISO

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

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 the one file with a mismatching MD5 sum.

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

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1888033/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Lau (lgautier)]

There was follow-up in the question (I first created this as a question):
https://answers.launchpad.net/ubuntu/+question/691933

The file efi.img in the USB appears to be modified at boot time (Kai suggests that it is modified by the BIOS), which leads to a failed check (different checksum than expected for that file).

[Kai Kasurinen (kai-kasurinen)]

maybe duplicate of bug 1832425

[Thinking Torus (thinking-torus)]

It might be helpful to take a closer look to see exactly what has changed.

For example, do a binary comparison:
$ cmp -bl old/efi.img new/efi/img

Or loop mount the img files and examine the contents:
$ mkdir mntold
$ mkdir mntnew
$ sudo mount -o loop old/efi.img mntold
$ sudo mount -o loop new/efi.img mntnew

mount may want to make its own changes so make sure the img files are writable.

[Dimitri John Ledkov (xnox)]

I have downloaded 20.04.1 desktop media, validated SHA256.gpg signature and SHA256 checksum, mounted the iso.

The check succeeded for me both using md5sum -c md5sum.txt and using casper-md5check /mnt /mnt/md5sum.txt.

I also mounted p1 of the iso, and executed the checks again and they too were successful.

Please try again using 20.04.1 iso, and please provide instructions on how to reproduce this, and please let me know how you booted the iso after downloading it.

[Kai Kasurinen (kai-kasurinen)]

I Don't know real hardware, but on qemu:
qemu-system-x86_64 -bios /usr/share/qemu/OVMF.fd -drive media=disk,file=ubuntu-20.04.1-desktop-amd64.iso

"-bios will only provide one big read-only ROM. In that case OVMS stores the EFI variables in /boot/EFI/NvVars."

[Lau (lgautier)]

As explained in the thread, the issue is not with the files in the original iso but with the fact that the efi.img is modified during the boot process, making the subsequent checksum fail.

This seems marked as invalid without looking at the issue.

[Lau (lgautier)]

Initially this was a question (https://answers.launchpad.net/ubuntu/+question/691933) but I invalidated it when this was reproduced by someone else and it seemed like a real bug.

The checksum test were already reported there, but we also came to the conclusion that it is modified during the boot process.

[Thinking Torus (thinking-torus)]

This certainly looks like a hardware dependent issue.

Just to add another data point (not 20.04):
https://askubuntu.com/questions/1149958/ubuntu-server-18-04-2-hwe-kernel-boot-grub-efi-img-file-failed-the-md5-checks

@Lau
Since you have the hardware that CAN reproduce the issue, why not do a little digging to see what has changed as I suggested above and how it's related to your hardware?

I have read you comment and I don't think excluding efi.img from the checks is a good idea. What if the modification is a sign of some advanced malware trying to hop from one computer to another? We certainly don't want to miss that!

On the other hand, if some hardware platform wants to make the modification for legit reasons and in predictable ways, we can certainly allow that. But we can't make a white list unless we know what to white list.

[Thinking Torus (thinking-torus)]

I just realized Kai has already indirectly referenced the link I mentioned.

These are two new (old) data points:
https://www.reddit.com/r/debian/comments/aflkdv/strange_error_while_check_the_cdroms_integrity_on/
Affecting ubuntu 18.10 Desktop
https://askubuntu.com/questions/404035/the-boot-grub-efi-img-file-failed-the-md5-checksum-verification
Affecting ubuntu-12.04.3-server-amd64.iso

[Steve Langasek (vorlon)]

I have double-checked that there is nothing in the boot configuration that is configured to modify the contents of efi.img (which contains only the signed EFI executables - modification of which would cause the image to subsequently fail to boot). Any modification of this image must be coming from outside, which is not something we can account for.

[Benjamin Bock (crapshit)]

Today I had the same exact problem.
I found out that after creating on Windows 10 with win32diskimager an usb boot stick with Ubuntu 20.04, I had a called "writable" partition on that stick also. That efi image file you mentioned was the only file with a different md5sum.
After that I created one more time a boot stick, but now on Ubuntu 18.04 with dd and now I had no issues anymore.
I hope this helps.

BR
Crapi

[topsail (dp-w)]

I have also just experienced this same issue when installing xubuntu 20.04.1. Let me know if I can be of any assistance!

[Willi Hahn (wijo)]

Me too, Machine: Lenovo Think-book 14-IIL. Win 10 pre-installed. Since a couple of days I got permanently this error. Installing Ubuntu 20.04.1 anyway my machine became very unpredictable. Rebooting of either system (Win or Ubuntu) ended in a lot of error messages. I had to power off and then try to boot again. My work-around was:
Install Ubuntu 18.04. This could be done without any problems. And then, I upgraded to Ubuntu 20.04.1 and so far as to today I finally got a stable system.

[Игорь (vlzvoice)]

Same for me. I can't install kubuntu 20.04.2 with the same problem.