From: Lilah Tascheter via Guix-patches <guix-patches@gnu.org>
To: 73202@debbugs.gnu.org
Cc: Herman Rimm <herman@rimm.ee>
Subject: [bug#73202] [PATCH] Preparation for bootloader rewrite.
Date: Tue, 08 Oct 2024 13:05:36 -0500 [thread overview]
Message-ID: <3586f7df3cbecf867bc82ac21c46bd067616d3f0.camel@lunabee.space> (raw)
In-Reply-To: <sgg7cef5h7fj7sl3ypvy3k77v6zoi2wsvn6zc2mloyvyntce5o@b3anleonz5hf>
hi!!
> > I'm also worried about indentation growing too quickly.
> Do you have a use case in mind, with more than three levels of
> nesting?
yeah good point :p
> > 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'mnow 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.
alright, that sounds great! would work for image gen, and can't think
of a reason why distinct uuids and devices would be supplied.
>
> > 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?
oh yeah that's a way better idea! offloads the test work from runtime
to, well, testing.
> 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.
sounds good, make sure the field supports specifying that all
filesystems are supported though (mostly just because of bootloaders
that install a kernel directly, like uki-efi).
> (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))
> ...)
so, the benefit here is that bootloader builds would be deterministic
from the bootloader-configuration, right? I feel like a new top-level
macro, that requires specific fields for each possible device type is
unwieldly. it's also potentially important to be able to install
multiple distinct bootloaders with distinct configurations, for eg
u-boot->uefi chainloading or raid arrays. how about something like the
following:
(operating-system
(bootloader (list (grub-efi-bootloader
;; ... remove the bootloader-configuration record
;; entirely, and have each bootloader take their
;; own config. apart from targets and
;; menu-entries (which we can split off), there
;; aren't really any shared config opts anyway.
;; assoc-fs assocs a path with a file-system type
;; from the operating-system record (delay
;; or thunk the bootloader field so that images
;; can override file-systems?)
(root (assoc-fs file-systems "/")))))
;; have your original targets system in place
(bootloader-targets ...)
;; non-grub replacement for menu-entries, potentially with a
;; %base-boot-options thing for the autogenerated ones per
;; guix system generation?
(boot-options ...))
with a field sanitizer to make singular entries into lists, to simplify
single-bootloader use. devpaths would then be able to be generated by
the bootloader using the configuration target information.
honestly, then maybe just specify a target field (taking a symbol) in
the file-system record, and have assoc-fs take either a target symbol
or mount path. have bootloader-targets be generated from the file-
systems, with the bootloader-targets field just specifying non-
filesystem block devices.
I think parts of that may be similar to what you were originally
intending? I'm sorry, if so.
- lilah
prev parent reply other threads:[~2024-10-08 18:06 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 16:58 [bug#73202] [PATCH] guix: scripts: Rewrite reinstall-bootloader to use provenance data Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 00/15] Preparation for bootloader rewrite Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 01/15] gnu: bootloader: Remove deprecated bootloader-configuration field Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 02/15] gnu: system: Remove useless boot parameters Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 03/15] gnu: tests: reconfigure: Remove bootloader install test Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 04/15] guix: scripts: Remove unused code Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 05/15] guix: scripts: Rewrite reinstall-bootloader to use provenance data Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 06/15] guix: utils: Add flatten and flat-map from haunt Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 07/15] guix: records: Add wrap-element procedure Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 08/15] gnu: bootloader: Add bootloader-target record and infastructure Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 09/15] gnu: bootloader: Add bootloader-configurations->gexp Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 10/15] gnu: bootloader: Add device-subvol field to menu-entry record Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 11/15] gnu: build: bootloader: Add efi-bootnums procedure Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 12/15] gnu: bootloader: Install any bootloader to ESP Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 13/15] gnu: bootloader: Match records outside the module Herman Rimm via Guix-patches via
2024-09-20 10:37 ` [bug#73202] [PATCH v2 14/15] gnu: system: boot: Add procedure Herman Rimm via Guix-patches via
2024-09-20 10:38 ` [bug#73202] [PATCH v2 15/15] teams: Add bootloading team Herman Rimm via Guix-patches via
2024-09-21 10:57 ` [bug#73202] [PATCH v2 00/15] Preparation for bootloader rewrite Herman Rimm via Guix-patches via
2024-09-25 20:58 ` Lilah Tascheter via Guix-patches
2024-09-26 10:08 ` [bug#73202] [PATCH v3 01/14] gnu: bootloader: Remove deprecated bootloader-configuration field Herman Rimm via Guix-patches via
2024-09-26 10:08 ` [bug#73202] [PATCH v3 02/14] gnu: system: Remove useless boot parameters Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 03/14] gnu: tests: reconfigure: Remove bootloader install test Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 04/14] guix: scripts: Remove unused code Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 05/14] guix: scripts: Rewrite reinstall-bootloader to use provenance data Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 06/14] guix: utils: Add flatten and flat-map from haunt Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 07/14] guix: records: Add wrap-element procedure Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 08/14] gnu: bootloader: Add bootloader-target record and infastructure Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 09/14] gnu: bootloader: Add bootloader-configurations->gexp Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 10/14] gnu: bootloader: Add device-subvol field to menu-entry record Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 11/14] gnu: build: bootloader: Add efi-bootnums procedure Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 12/14] gnu: bootloader: Install any bootloader to ESP Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 13/14] gnu: bootloader: Match records outside the module Herman Rimm via Guix-patches via
2024-09-26 10:09 ` [bug#73202] [PATCH v3 14/14] teams: Add bootloading team Herman Rimm via Guix-patches via
2024-10-03 20:32 ` [bug#73202] [PATCH] Preparation for bootloader rewrite Herman Rimm via Guix-patches via
2024-10-04 5:07 ` Lilah Tascheter via Guix-patches
2024-10-04 13:55 ` Herman Rimm via Guix-patches via
2024-10-07 16:59 ` Ryan via Guix-patches via
2024-10-07 19:23 ` Herman Rimm via Guix-patches via
2024-10-08 14:37 ` Ryan via Guix-patches via
2024-10-08 17:23 ` Lilah Tascheter via Guix-patches
2024-10-08 18:05 ` Lilah Tascheter via Guix-patches [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3586f7df3cbecf867bc82ac21c46bd067616d3f0.camel@lunabee.space \
--to=guix-patches@gnu.org \
--cc=73202@debbugs.gnu.org \
--cc=herman@rimm.ee \
--cc=lilah@lunabee.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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).