Check error with 20.04-desktop ISO

Bug #1888033 reported by Lau on 2020-07-18
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu CD Images
Undecided
Unassigned
Ubuntu
Critical
Dimitri John Ledkov

Bug Description

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.

Lau (lgautier) on 2020-07-18
description: updated

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

tags: added: bot-comment
Lau (lgautier) wrote :

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) wrote :

maybe duplicate of bug 1832425

Changed in ubuntu-cdimage:
status: New → Confirmed
Changed in ubuntu:
status: New → Confirmed
importance: Undecided → Critical
tags: added: focal
Thinking Torus (thinking-torus) wrote :

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.

Changed in ubuntu:
assignee: nobody → Dimitri John Ledkov (xnox)
Dimitri John Ledkov (xnox) wrote :

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.

Changed in ubuntu:
status: Confirmed → Invalid
Changed in ubuntu-cdimage:
status: Confirmed → Invalid
Kai Kasurinen (kai-kasurinen) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions