Hi Ard, On Tue, Nov 23, 2021 at 07:58:32AM +0100, Ard Biesheuvel wrote: > On Tue, 23 Nov 2021 at 06:12, Salvatore Bonaccorso <car...@debian.org> wrote: > > > > Hi Vincent, > > > > On Fri, Nov 19, 2021 at 10:04:57PM +0100, Vincent Blut wrote: > > > Hi, > > > > > > Le 2021-10-26 17:33, Zameer Manji a écrit : > > > > On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut <vincent.deb...@free.fr> > > > > wrote: > > > > > > > > > Control: reassign -1 src:linux > > > > > > > > > > Hi, > > > > > > > > > > Le 2021-10-26 20:44, Zameer Manji a écrit : > > > > > > Package: linux-image-arm64 > > > > > > Version: 5.14.9-2 > > > > > > Severity: important > > > > > > > > > > > > Dear Maintainer, > > > > > > > > > > > > In bullseye, version 5.10.70-1 has the > > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER > > > > > > kernel configuration set to 'y'. In bookworm it is unset which > > > > > > disable > > > > > this feature. > > > > > > > > > > > > This kernel configuration parameter allows for the EFI stub of the > > > > > kernel to > > > > > > parse and use a 'initrd=' parameter to set up an initrd when booting > > > > > from EFI. > > > > > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if > > > > > configured > > > > > > to pass an initrd. If the kernel configuration parameter is unset, > > > > > > the > > > > > > `initrd=` paramater is ignored, and can result in an unbootable > > > > > > system > > > > > because > > > > > > the initrd has not setup the root filesystem. > > > > > > > > > > > > Without the kernel configuaration set, it is not possible to use > > > > > 'systemd-boot' > > > > > > or 'refind' on arm64 as both of these bootloaders assume the kernel > > > > > > will > > > > > > handle the 'initrd=' flag and setup the initrd. > > > > > > > > > > > > Please consider enabling > > > > > > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on > > > > > > arm64 so using 'systemd-boot' or 'refind' can continue to work. > > > > > > Until > > > > > these > > > > > > bootloaders have been updated to use an alternative method of > > > > > > passing the > > > > > > initrd to the EFI stub, it is not possible to have a booting system. > > > > > > > > > > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer > > > > > enabled > > > > > by > > > > > default. Please see [1] for some details. > > > > > > > > > > Cheers, > > > > > Vincent > > > > > > > > > > [1] > > > > > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a > > > > > > > > > > > > > Hello Vincent, > > > > > > > > I see and understand the rationale of upstream to deprecate this > > > > functionality. > > > > >From the commit you linked I see another commit [0] which says: > > > > > > > > > Loading an initrd passed via the kernel command line is deprecated: it > > > > > is limited to files that reside in the same volume as the one the > > > > > kernel > > > > > itself was loaded from, and we have more flexible ways to achieve the > > > > > same. So make it configurable so new architectures can decide not to > > > > > enable it. > > > > > > > > I assume the 'more flexible ways' to do the same is referencing this > > > > feature [1] > > > > which is indeed more flexible. The problem is that the > > > > firmware/bootloader > > > > must > > > > support this new functionality, by populating the right EFI file with > > > > the > > > > right GUID. > > > > > > > > As far as I can see on arm64 there are three EFI bootloaders: > > > > * GRUB2 > > > > * systemd-boot > > > > * refind > > > > > > > > Both systemd-boot and refind do not yet support this new mechanism, > > > > although I see > > > > that systemd has some unreleased code [2] to support the new way. I have > > > > not been > > > > able to test GRUB2 but my understanding is that this new method is still > > > > under active > > > > development [3]. > > > > > > > > The problem is that upstream has deprecated this functionality by > > > > assuming > > > > the only > > > > active use was x86, but was completely possible to use it on arm64 (it > > > > works fine for me > > > > on bullseye). Since EFI bootloaders have not yet implemented the new > > > > way, > > > > and still > > > > rely on this deprecated method on all architectures, it results in > > > > unbootable systems > > > > on arm64. > > > > > > > > I would 100% think this should remain disabled on arm64 if most EFI > > > > bootloaders > > > > supported the new way, but unfortunately they do not. > > > > > > > > I hope you would consider enabling this kernel configuration for arm64 > > > > until EFI > > > > bootloaders catch up to the recommended way. > > > > > > > > > > > > [0] > > > > https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5 > > > > [1] > > > > https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c > > > > [2] > > > > https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a > > > > [3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html > > > > > > Salvatore, I tend to agree with Zameer. I think we should explicitly > > > enable > > > EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER until the support for loading > > > initrd > > > from a device path is widespread among bootloaders. > > > > Yeah I guess it makes sense and understand. Before doing the switch > > and re-enabling it explicitly, let's ask Ard if there are known plans for > > !X86 and say so for example arm64 as well to revert the default > > upstream. The more we can follow those upstream the better for us :) > > > > Ard, this is about https://bugs.debian.org/997907 on non X86, > > specifically for arm64. > > > > Hello all, > > I don't see a reason to revert the default upstream. The feature > remains deprecated (and in the longer term, the EFI handover protocol > may be deprecated and removed as well), so the earlier the bootloaders > adapt, the better it is. > > In the meantime, keeping it enabled in the distros for arm64 makes > sense because there is an established installed base. But that doesn't > mean this should be the upstream default.
Perfect thanks for commenting quickly. We will enable it donstream in Debian then explicitly for the time beeing. Regards, Salvatore
