This is likely an issue stemming from a bad interaction between the firmware's PE loader and the kernel's efi stub.
The reason peimage can appear to fix this as it bypasses the firmware's PE loader for secure boot reasons. Hiding bugs in said PE loader is a coincidental side benefit and not an intentional fix. On Thu, Jun 27, 2024 at 11:27 AM Jan Čermák <sai...@sairon.cz> wrote: > > Hi Ard, > > sorry, I feel a little ashamed for replying after such a long time but I > wanted to do some due diligence first and didn't have time (or the Atom > board around) until now. > > > Does your Kconfig have EFI_DISABLE_PCI_DMA enabled by any chance? That > > could definitely produce the issues you are observing. > > No, this option is not set in our kernel. > > > In any case, given that you never relied on the EFI stub in the past > > on x86_64 (as GRUB 2.06 does not rely on it), you could just disable > > that in your Kconfig. > > > > That of course does not solve the Fujitsu issue, which apparently > > requires boot via the EFI stub, but I don't have a solution for that - > > I suppose that simply never worked with the old 'working' version of > > the OS? > > The goal is to have a single configuration that works for both (or > ideally - all amd64) targets so disabling EFI stub is not an option. > With no changes in the kernel in the meantime, just GRUB 2.06 loaded > kernel without issues on both devices. > > Anyway, what held me up a bit is that I wanted to try any of the major > distributions that already adopter GRUB 2.12. I tested Ubuntu 24.04 and > Arch's build of GRUB. While Arch's GRUB behaves exactly the same way > (error loading image) I was a bit puzzled that it's not the case of > Ubuntu. It took me a while to figure out why because there are quite > many patches applied but in the end it boiled up to the following two > from the grub package repo [1]: > > - loader-framework.patch > - efi-use-peimage-shim.patch > > Vanilla GRUB with these two patches AND with the introduced `peimage` > module added to the GRUB binary boots our kernel correctly. > > At this point I don't have the knowledge to figure out if it's just side > effect of that changes or if they indeed make any difference. And I'm > not sure what effect it has on the Fujitsu board but I can't find any > mentions of it in Ubuntu's issue tracker or anywhere on the internet so > I *guess* it's fine. > > I don't know what else to try at this point. If you'd like to look into > the issue yourself, I can give you the board I have, in the end it has > no other use for me than making sure that our OS boots correctly there, > and if the issue gets resolved, it will be just gathering dust. Let me > know if you're interested - if you give me an EU address to ship to, I > can arrange that. Outside the EU I'm afraid the shipping costs and > duties would be higher than the cost of the hardware itself :) > > Thanks, > Jan > > [1] > https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/patches/secure-boot > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
