Re: Better handle systemd-boot and installkernel changes in HB

Nowa Ammerlaan <[email protected]> writes:

> Hi all,

[I've replied to immolo below as well. Let's please try not top-post as
it's hard to follow then.]

>
> With regards to EFISTUB, I double checked that before and found that it actually does not use /proc during configuration.
> Uefi-mkconfig used to do that, but it no longer does precisely because folks were running into this problem.
>
> With regards to the Handbook, I'd just instruct users to configure the desired cmdline in /etc/kernel/cmdline instead of
> touching the file. Sd-boot features auto detection but that does not work for every setup and users will likely want to
> configure other options anyway. There should also really be no need to clean that file up afterwards since users will
> very likely want to make adjustments to the kernel cmdline after installation.
>

I guess it depends on how floppym feels about the usefulness of the grub
autodetection. I don't know either way.

> In general users should configure some cmdline (regardless of the used bootloader) before installing the kernel and
> rebooting. So perhaps there should be a whole separate section dedicated to configuring the cmdline for grub, sd-boot,
> kernel built-in, or via dracut.
>

That might be a good solution in the end, yeah.

> Best regards,
> Nowa
>
> On 7 November 2025 15:44:49 CET, Immolo <[email protected]> wrote:
>
>  H,
>
>  In my previous email I made some errors in my summary and the fix didn't not fully solve the issue for Gentoo. Thanks
>  to Nowa for being patient and explaining the parts I did not fully grasp.
>
>  The summary is now https://bugs.gentoo.org/965211 highlighted users were not understanding the current steps in the
>  Handbook to correctly setup systemd-boot and EFISTUB systems. In turn this caused a support queue issue for the same
>  task happening over and over. Gentoo has now added a chroot detection feature to sys-kernel/installkernel, which
>  helps identify when a user has fallen into this trap.
>
>  The HB needs an update that solves the issue for current stable users and how to deal with the chroot detection for ~
>  ARCH users.
>
>  My solution to this is as follows.
>    
>  Part 1:
>
>  Add the following text and steps to https://wiki.gentoo.org/wiki/Handbook:Parts/Installation/Kernel
>
>  Add to both systemd-boot and EFSSTUB:
>
>    By default systemd-boot/EFISTUB will take the kernel cmdline from the system, which is less than ideal for an
>  install from live media.
>    To workaround this the following changes must be made:
>
>      touch /etc/kernel/cmdline

OK.

>      touch /etc/kernel/install.d/05-check-chroot.install
>

Why is this bit needed? Should we tell people to touch /etc/cmdline
instead/as well?

Note I can live with us mentioning this suppression file but I just want
to be clear on why we're doing it.

>  This gives systemd-boot a blank kernel cmdliine to use rather than using the installcd's cmdine and gets around the
>  chroot check if the user
>  decides to use ~ARCH.
>
>  For GRUB:
>
>    Create the following to pass chroot checks for {{Package|sys-kernel/installkernel}}:
>       touch /etc/kernel/install.d/05-check-chroot.install

I'm not following this bit.. can't we just disable the check for grub
instead somehow?

Does it make sense to tell users to always be doing this for grub?

>
>  GRUB does not require any other tweaks which aren't already well explained in the HB so this is all that is needed.
>
>  A copy/paste can be found at https://wiki.gentoo.org/wiki/User:Immolo/Sandbox/Kernel-systemd-boot
>
>  Part 2 (Optional):
>
>  Clean up the changes made so the blank /etc/kernel/cmdline is removed and make Nowa's previous attempt easy to follow
>  at 
>  https://wiki.gentoo.org/wiki/Handbook:AMD64/Blocks/Bootloader
>  I don't like the idea of keeping /etc/kernel/cmdline for any longer than
>  is required for the install. This resolves that issue, however I would like someone
>  else to check if it's the correct call.
>

I think I could go either way on this.

* Removing it: this means that once they are booted, we follow upstream
  behaviour.

* Keeping the empty file: when users reenter a chroot later on for
  recovery or something, they may well completely forget about this
  problem if we've deleted the file. The problem we're solving here
  isn't just about new installs but also recovery...

>  This can be both viewed and copied from https://wiki.gentoo.org/wiki/User:Immolo/Sandbox/Bootlloader-systemd-boot
>
>  These steps have now been confirmed as the fix by a user on Reddit, so all that is
>  required now is for Nowa to please give a quick once over and if she is happy 
>  then this should be taken as the confirmed solution into the HB ASAP.
>
>  NOTE: Alpha and HPPA might need a second edit due to some wikicode quirks
>  I can only spot those when we make these changes though. (I'm 70% sure they will 
>  be OK though.)
>
>  Kind regards,
>
>  immolo
> [...]

thanks for working on this,
sam