GNU bug report logs - #73202
[PATCH] Preparation for bootloader rewrite.

Previous Next

Full log

View this message in rfc822 format

From: Herman Rimm <herman <at> rimm.ee>
To: 73202 <at> debbugs.gnu.org
Cc: Lilah Tascheter <lilah <at> lunabee.space>
Subject: [bug#73202] [PATCH] Preparation for bootloader rewrite.
Date: Fri, 4 Oct 2024 15:55:33 +0200

Hello,

On Fri, Oct 04, 2024 at 12:07:16AM -0500, Lilah Tascheter wrote:
> > (define (grub-efi-default-targets esp)
> how would this handle root offsets, eg by guix system init? is
> everything assumed to be offset from root?
For every (key . value) in targets, prefix value with root-offset.  Or
if the target tree is still available, extend it:

  (bootloader-target
    (type 'root)
    (path root-offset)
    (targets (list %target-tree)))

It works under the assumption that bootloader-target paths will not be
referenced in bootloader configuration files.  When that does not hold,
e.g. in the (make-)grub.cfg procedure, then I think either the target
paths (or tree) need to be unprefixed (or unwrapped); or the root should
be offset implicitly, i.e. doing the installation in a chroot.

> I'm also worried about indentation growing too quickly.
Do you have a use case in mind, with more than three levels of nesting?

> otherwise, though, it's definately an improvement over offset!
Thanks.  Using the assumption that Guix only works with UNIX file
systems and not DOS-derivatives or exotic data stores, it only allows
constructing a tree and not a forest or (cyclic) graph, respectively.

> how are you replacing device-local paths? some bootloaders need that
> information to access files before fully loading.
I guess when device-local paths are required, a targets tree should be
provided and queried using the with-targets macro.  They could also be 
cast from target paths, with a warning.

> also, if the path, device, label, and uuid fields are combined, the
> guix system image won't be able to get all the info it needs to the
> bootloader installers. uuid or label needs to be there to identify the
> device on-boot,
So I have tried combining the path field into the device field, but I'm
now in favor of using a target tree/paths field together with a combined
block device, file system label, or UUID field.  Here the assumption is
that any of the aformentioned types can be derived from any other, e.g.
with find-partition-by-uuid and read-partition-label.  If a bootloader
cannot use a provided type, or find other required types, it should
throw an error.  If you have a use case where both a block device and a
(potentially unrelated) UUID are configured, please let me know.

> but also path, device, and devpath are required to actually install
> bootloader files.
I think the device could be installation-agnostic and anything related
to installation could be a different bootloader, or a field like tftp.

> also, one reason with-targets exists is as a safeguard for future
> people writing bootloaders. guix system image tends to be overlooked,
> so it performs checks to make sure the bootloader targets requested
> are available during image generation.
What do you think about having required types per bootloader, and tests
for trees generated from image partitions in (gnu tests image) instead?

That reminds me: I would like to add a supported file systems field to
the bootloader, so that if the file system found for root-device is not
supported, it throws a little error.

> > (operating-system
> >   (bootloader (list %grub-efi-bootloader))
> >   ;; This is shared between bootloaders.  Ideally, it does not affect
> >   ;; which files are installed or their contents, but only the
> > location.
> >   (bootloader-targets (grub-efi-default-targets "boot")))
> I do really like the conceptual separation between configuration and
> installation! though, users would now need to enter the root device
> details three times, potentially in inconsistant formats.
Thanks, I think the two examples below could work pretty well.

Cheers,
Herman

(define %boot-fs
  (file-system
    (device (uuid "E6A5-FEBB" 'fat32))
    (mount-point "/boot") ; Taken as ESP.
    ;; Cannot be used to configure e.g. GRUB netboot, but it would be
    ;; nice to assert (support? bootloader type) in fs->bootloader.
    (type "vfat")))
(operating-system 
  (bootloader ;; Procedure defined in (gnu system file-systems).
              (file-system->grub-efi-bootloader %boot-fs))
  ...)

;; bootloader->file-system would not work as well.  An OS field (macro)
;; to define both simultaneously at a high level could be useful though.
(operating-system
  (file-systems-with-bootloader
    ;; Irrelevant for file-systems.
    (bootloader grub-efi-bootloader)
    ;; Relevant as a file-system and bootloader installation.
    (boot-device "UUID, label, or block device.")
    (mount-point "/boot")
    (type "vfat")
    ;; Not relevant to bootloader.  Default values given.
    (root-file-system (mounted-root-fs)) ; Error if not found.
    ;; Cons the generated boot FS and mounted root FS to this.
    (file-systems %base-file-systems))
  ...)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.