[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [REGRESSION] Re: [PATCH v4 5/5] efi: Use generic EFI loader for x86_
From: |
Ard Biesheuvel |
Subject: |
Re: [REGRESSION] Re: [PATCH v4 5/5] efi: Use generic EFI loader for x86_64 and i386 |
Date: |
Fri, 28 Jun 2024 19:28:37 +0200 |
On Thu, 27 Jun 2024 at 12:27, Jan Čermák <sairon@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 :)
>
Hello Jan,
I appreciate the gesture but please don't send me stuff.
Given that you carry your own GRUB build, I would recommend reverting
to non-EFI stub boot for affected Atom systems, identified by DMI
data, which should be easy to access on such systems.
Look for 'goto fallback' in the existing loader logic in
grub-core/loader/efi/linux.c - you'd need to jump to the same point to
use the GRUB 2.06 logic for systems that fail that cannot load the EFI
stub kernel image.
Out of curiosity - these are all x86_64 Atoms right? How old are they?