On Wed, 3 Jul 2024 at 16:25, Jan Čermák <sai...@sairon.cz> wrote: > > Hi Ard > > On 28. 06. 24 19:28, Ard Biesheuvel wrote: > > 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. > > Thanks for the suggestion, that sounds like a more acceptable solution > (than the revert). However, would a quirk like that be acceptable in > upstream code as well? In long term, we'd like to only support hardware > that is supported in upstream, instead of taking the maintenance burden > of carrying custom patches indefinitely, so if it is GRUB's maintainers' > decision to abandon support for old buggy hardware, we shall declare it > abandoned as well. >
If GRUB no longer works correctly on these systems due to the move to the generic EFI loader, and we can straight-forwardly identify them using SMBIOS metadata, I don't anticipate any objections from the GRUB maintainers. @Daniel? > > Out of curiosity - these are all x86_64 Atoms right? How old are they? > > Yes, they are, e.g. Atom D525 [1], but from the reports we've received > it seems the problem is with the NM10 chipset [2] in general (as I > stated in the first message in the thread). They are ~14 years old so > pretty archaic I'd say O:-) > If you can get me the output of 'dmidecode' from preferably more than one variant of such a system, I can hack up a GRUB patch that implements the SMBIOS matching and the opt-out. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
