Re: shim 16 breaking systemd stub and next steps

[Luca Boccassi <luca.boccassi@xxxxxxxxx>]

On Fri, 21 Mar 2025 at 15:30, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
>
> On Fr, 21.03.25 07:23, Harry G Coin (hgcoin@xxxxxxxxx) wrote:
>
> > > I'm afraid we are not aligned on that - shim exists because hardware
> > > exists, non-tech-savvy users exist, and distributions exist, and the
> > > intersection of all three matters. I understand you focus on the VM
> > > case, which is very important and deserves its time and space, but
> > > it's only one part of the whole story. The solution for VMs and the
> > > solution for generalist distributions on end-user consumer hardware do
> > > not have to be the same, if there are reasons to diverge.
> > > The overwhelming feedback we got over the years in distros is that if
> > > users have to go mess with firmware settings in order to run Linux,
> > > they either give up or just disable secure boot and leave it off
> > > permanently, neither of which are desirable outcomes for us, hence the
> > > need for shim.
> >
> > +1.  The growth future of any distro depends on __ at least the installer
> > images __ 'just working the first time' whether the laptop, desktop or
> > widget has secure boot on or off.
> >
> > Afterward, once installed, methods used by that installed code can vary, and
> > have the advantage of being configured by the installer that has data about
> > the instance.  I advise forcing the average desktop/laptop user to deal with
> > the bios at any point in the process puts that distro on a path to exclusion
> > from being tried at all by the general user -- who in the years that follows
> > becomes the developer, specifier in their organization, etc. Nagging the
> > user that 'it would be better if the bios were set to X' is ok.  But
> > __installer images__  have to 'just work out of the box'.
>
> Huh, I mean, I am not against that people do shim if that floats their
> boat, but I find your reasoning wrong. You seem to believe that users
> can install distros without interfacing with the system
> firmware. That's nonsense though: how do you get your firmware to boot
> from your installer USB stick in the first place? You go to the
> firmware menu for that. So you *do* interface with the firmware, there
> is no way around that. Yeah, finding the SecureBoot option in the
> firmware setup is a bit more involved, but it's certainly not an all
> or nothing situation at all.

YMMV, but I have definitely had machines where the usb stick had
higher priority, so inserting a bootable usb was enough for the
firmware to choose it without needing to enter the options.