As the URL indicates the md5sum is expected to be 3cdc56… Sure enough, if I pull that file down with wget, the md5sum is 28d3fead8ae2… I’m getting a file that looks reasonable otherwise:
% md5sum grub-efi-bootaa64.efi
28d3fead8ae217a2a879e467b920a3a3 grub-efi-bootaa64.efi
% file grub-efi-bootaa64.efi
grub-efi-bootaa64.efi: PE32+ executable (EFI application) Aarch64 (stripped to external PDB), for MS Windows
But I don’t want to trust an executable that may have been modified.
Thanks for the report! Is this happening on an unmodified build, e.g. plain Yocto on scarthgap branch with meta-mender? Which board target? I agree that a changed hash should be carefully checked, so I’d like to reproduce it.
I have also added a (thin-so-far) layer to support our hardware, and I’ve added the Mender layer from https://github.com/mendersoftware/meta-mender.git using branch scarthgap. The URI for the failing checksum is defined in this file.
It’s entirely possible I don’t have the build configured correctly yet for Mender. E.g., I think it’s strange that the failing file is related to GRUB EFI while I am building for an ARM processor that boots with U-Boot.
Ah okay, we’re getting there. I guess that you do not have specified any additional MENDER_FEATURES then? Not knowing your board and setup, I have to assume that it is using a boot flow which is essentially
some loader -> u-boot -> Linux
The Mender defaults are GRUB+UEFI, so maybe this local.conf addition already gets you started: