all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lilah Tascheter <lilah@lunabee.space>
To: guix-devel@gnu.org
Cc: Hilton Chain <hako@ultrarare.space>
Subject: [RFC] proposal for refactoring bootloaders
Date: Thu, 15 Feb 2024 01:28:25 -0600	[thread overview]
Message-ID: <3cf16a155c1742eff056fc1dc3e0c31366e677ba.camel@lunabee.space> (raw)

hi everyone!

I've been working on submitting to mainline some bootloaders I
packaged a while ago on my channel (an efi-stub bootloader supporting
secure boot & full disk encryption and p-boot for pinephones) and came
across a good few hard points in how guix handles bootloaders. the
current system seems to have been made with only grub/extlinux-alikes
in mind, and makes working with everything else extremely cumbersome
and incompatible with generation rollbacks. before I start
making/submitting changes, I wanted to ask for opinions on the following
plan:

* merge bootloader-installer and bootloader-disk-image installer.
  almost all cases where one is used, the other is called with almost
  the exact same arguments, except for in (gnu system image), which
  provides the image itself. this should be provided in general; BIOS
  bootloaders and u-boot need to know the main disk device anyway.

* create a new bootloader-config-installer record field
  (accepting a gexp), replacing bootloader-configuration-file and
  bootloader-configuration-file-generator. it's really only
  grub/extlinux-alikes that use a single, static-path config file. uefi
  configuration involves calling efibootmgr, and p-boot needs an entire
  configuration partition. can provide a helper procedure to replicate
  current behavior, and register the gexp as a gc root to prevent gc of
  boot objects, in lieu of the current behavior.

* provide the full bootloader-configuration record to
  bootloader-installer instead of just bootloader-package. the full
  record is available every time bootloader-installer is called.

* don't provide bootloader-configuration to bootloader-config-installer.
  reinstall-bootloader (guix scripts system) regens the configuration
  without access to the full bootloader-configuration record.
  conceptually, config install should only affect the boot entries
  themselves anyway.

* change initialize-efi-partition (gnu build image) to handle any
  bootloader-installer when used, providing its partition as the target.
  also un-hardcode grub in system-disk-image (gnu system image).

* to facilitate secure boot support, add a
  bootloader-configuration-signing-keypair record field accepting a pair
  of out-of-store paths to encryption keys.

* provide generation numbers to bootloader-installer and
  bootloader-config-installer, to help with coordination between the
  procedures, and bootloader-config-installer allowing incremental
  rollbacks in bootloaders that have to copy the kernel/initrd off-root.

(thanks Hilton Chain for initial discussion on this in the uefi support
patch thread!)

- lilah




             reply	other threads:[~2024-02-16 19:09 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15  7:28 Lilah Tascheter [this message]
2024-02-16  8:33 ` [RFC] proposal for refactoring bootloaders Lilah Tascheter
2024-02-19 10:18   ` Efraim Flashner
2024-02-24  1:27     ` Felix Lechner via Development of GNU Guix and the GNU System distribution.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3cf16a155c1742eff056fc1dc3e0c31366e677ba.camel@lunabee.space \
    --to=lilah@lunabee.space \
    --cc=guix-devel@gnu.org \
    --cc=hako@ultrarare.space \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.