From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id GJLaFpp0BWcXoQAAe85BDQ:P1 (envelope-from ) for ; Tue, 08 Oct 2024 18:06:18 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id GJLaFpp0BWcXoQAAe85BDQ (envelope-from ) for ; Tue, 08 Oct 2024 20:06:18 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=vdCRy2CB; dkim=fail ("headers rsa verify failed") header.d=lunabee.space header.s=purelymail3 header.b=NS2TSTWr; dkim=fail ("headers rsa verify failed") header.d=purelymail.com header.s=purelymail3 header.b=QGmLcxiG; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1728410777; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=jCvx/p/xGV2lErGjjjM3Zqe3BtmwZUTPkBn74Ga6DEU=; b=mMGO8GGWpIFO0ihAWCqRQrPnjwE8ESqNcLs7klJ1u5FRcDg+Ag2iqWj1lURdvJD5Rf9JP+ UIRCdGZuf0K4jFietP4We9YQlJNiwHzdMtaoDzmoymD+5XjEfHn5ylY3k89h6V1algCZCN WUSmSOXkDrXGrPSgiVc2ND5lESzrQQtQVFHePwVJ6nh1P1/l0if6VULpkIn7Z7G/Vwca8B ogx+zuKAMhu4v4H2VsxT+R+xobQGi+cFjCHLbfiCGelkuj9H1EvjP98qsOz8B/WnI20vhe Ed03kkHQcrVrug0kYNU8hUEVYNR6wQoU4vo6CB+Ba7Oo97JAJCbAYKXq0Q1q1A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1728410777; a=rsa-sha256; cv=none; b=tkjJfvGeamKqHC2oZ7p3HDiSES+af2Gr1eKVi1lZrdtb5mHhlIn1CngpGxRI3LwWnQ4Xqf nmts9+Y5GBrZqxDg0CrIZdBfFI8XNqiYzbQtwK9KQlatOH+MQ/KKx0Cgv41thKmFarLJEG +7/3KQrxevPv64YY360cWMMu17VV6jAV/zKe+xjV4b0s0XyAoJELhHmIevH4G+Yzo512GG 7YBNbHJ5dJU7oWcAOnO9WcaujbdxZuuL/xWiJ6zm0kKWd3TpWfoRLI0Lf7xJELeoqVgjCW J59JBFG4XwmPvSe7vT7sWW+QTSTeWsud8YDBFDXt3Tv07Vaz0dQFYGS37mHj0w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=debbugs.gnu.org header.s=debbugs-gnu-org header.b=vdCRy2CB; dkim=fail ("headers rsa verify failed") header.d=lunabee.space header.s=purelymail3 header.b=NS2TSTWr; dkim=fail ("headers rsa verify failed") header.d=purelymail.com header.s=purelymail3 header.b=QGmLcxiG; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gnu.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 74FCD5C126 for ; Tue, 08 Oct 2024 20:06:17 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1syEar-0006Fv-7J; Tue, 08 Oct 2024 14:05:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1syEan-0006Fg-TT for guix-patches@gnu.org; Tue, 08 Oct 2024 14:05:54 -0400 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1syEan-0005XL-Kn for guix-patches@gnu.org; Tue, 08 Oct 2024 14:05:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:Date:From:To:Subject; bh=jCvx/p/xGV2lErGjjjM3Zqe3BtmwZUTPkBn74Ga6DEU=; b=vdCRy2CBSN/gwuCuMFgIwLQYoMhEb8Fn49a3icY2l3iF8jRmAYV+bCYWruYxJQq9WvL7tpVXuOcFrynD2VbQ+nfCVKq8TVIqXAF6hFoesS7GuTHpByWOak/JwQNX54YRh3gneXsQusWFXA05Xl/mWjOkMKHJ/K7qRq8Fc6QPl1gSEPFYPnIItySCqVZEOFUd5a4i3rbW0hGsAPUvXm9z0TDKf2irF2Y/ean6lW84QDc+/0SrH9A3XV4kquVnFqoA9/KX/zS5r4dpyy/iqXz2pIJNqgmGXrHedMoHoOX2hvrd7kqEQEsm/F/3LgNQzl52v2xuW4JK/rJ1xH7/9YyUkQ==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1syEaw-0005SQ-Ft for guix-patches@gnu.org; Tue, 08 Oct 2024 14:06:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#73202] [PATCH] Preparation for bootloader rewrite. Resent-From: Lilah Tascheter Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 08 Oct 2024 18:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73202 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 73202@debbugs.gnu.org Cc: Herman Rimm Received: via spool by 73202-submit@debbugs.gnu.org id=B73202.172841075720967 (code B ref 73202); Tue, 08 Oct 2024 18:06:02 +0000 Received: (at 73202) by debbugs.gnu.org; 8 Oct 2024 18:05:57 +0000 Received: from localhost ([127.0.0.1]:54340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syEaq-0005S7-P4 for submit@debbugs.gnu.org; Tue, 08 Oct 2024 14:05:57 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:54710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1syEan-0005Rq-Dw for 73202@debbugs.gnu.org; Tue, 08 Oct 2024 14:05:55 -0400 DKIM-Signature: a=rsa-sha256; b=NS2TSTWrsiM44JBFi0Otfo+A4pjss0PijRYZxpjjlbpWEz0SoHysEETteksKwWizBZ5yPWRMjtoYbnw6Vj8CXypT3kElRK2VBeJq8sD7GJjbePrknS9MiDn8I2zf9cUGKUzEnfzB315aOiaO8zZlxhiqbDPV2ljvfDhZZ1iHaJBWgnpiFyIRSRD2cR23e87QVQe/YqsVgSXVJwDeTy0wDs0oTymhyuvmF4Lvw3+MMHtXgs2Vc6jraCMMFG/W7P/gNl5KnY1SvOf1evS6qV0LdaT5vG3YA73JJqc+1rc/ouCXCTNks7EPemM1UK1v1tSeGh/sVrXHtenPxBVhT/gwMQ==; s=purelymail3; d=lunabee.space; v=1; bh=HU04stQHQoqRxgZ6VizLOjqj9Q/R4HepBS4UP4E1k/4=; h=Received:Subject:From:To:Date; DKIM-Signature: a=rsa-sha256; b=QGmLcxiG0F+NtaF63wRgXESW9oZhrsNSEqgRqeVtKpuTdnTZDMI3Lh30P66VNSi/pEWToLs28IzCwW1wYwPFv5K9wdVeZ5vC//qWmdmZfFy869by9KvXQLFUrzeHIoOjf9xO3oDN4DcsBSxyQszcmP7iDgEqd1r8x3DVP9y0zDOjStqdk0FwcdvphosX/nPcnXKwNEn6HOG0t5Ne05jOTphNXwifo8CNvbLRmYBIoxqZhoo57uOyyz7ZZhONN0XEFXPrEYScP+Pzm3qd9nbfNhfN18IxwuaCxqaNSs+ajDw72aqQ00tVh/x90TVGvoA+QCrfnH8ayTnwHLQE+0R7fg==; s=purelymail3; d=purelymail.com; v=1; bh=HU04stQHQoqRxgZ6VizLOjqj9Q/R4HepBS4UP4E1k/4=; h=Feedback-ID:Received:Subject:From:To:Date; Feedback-ID: 8937:2070:null:purelymail X-Pm-Original-To: 73202@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1089440259; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 08 Oct 2024 18:05:37 +0000 (UTC) Message-ID: <3586f7df3cbecf867bc82ac21c46bd067616d3f0.camel@lunabee.space> Date: Tue, 08 Oct 2024 13:05:36 -0500 In-Reply-To: References: <4fnudiucjxequd3m4ayy7drqsgjokybfvsu6l2tbssurhlr5wd@odqr53qw5qqz> Organization: Dissociation for Heresiographal Computation Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Lilah Tascheter via Guix-patches Reply-To: Lilah Tascheter Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -3.34 X-Spam-Score: -3.34 X-Migadu-Queue-Id: 74FCD5C126 X-Migadu-Scanner: mx13.migadu.com X-TUID: FJ2hodZJRvuY 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.=C2=A0 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.=C2=A0 If a bootloader cannot use a provided type, or find other > required types, it should throw an error.=C2=A0 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. >=20 > > 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 > =C2=A0 (file-system > =C2=A0=C2=A0=C2=A0 (device (uuid "E6A5-FEBB" 'fat32)) > =C2=A0=C2=A0=C2=A0 (mount-point "/boot") ; Taken as ESP. > =C2=A0=C2=A0=C2=A0 ;; Cannot be used to configure e.g. GRUB netboot, but = it would be > =C2=A0=C2=A0=C2=A0 ;; nice to assert (support? bootloader type) in fs->bo= otloader. > =C2=A0=C2=A0=C2=A0 (type "vfat"))) > (operating-system=20 > =C2=A0 (bootloader ;; Procedure defined in (gnu system file-systems). > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (file-system->grub-efi-bootloader %boot-fs)) > =C2=A0 ...) >=20 > ;; bootloader->file-system would not work as well.=C2=A0 An OS field > (macro) > ;; to define both simultaneously at a high level could be useful > though. > (operating-system > =C2=A0 (file-systems-with-bootloader > =C2=A0=C2=A0=C2=A0 ;; Irrelevant for file-systems. > =C2=A0=C2=A0=C2=A0 (bootloader grub-efi-bootloader) > =C2=A0=C2=A0=C2=A0 ;; Relevant as a file-system and bootloader installati= on. > =C2=A0=C2=A0=C2=A0 (boot-device "UUID, label, or block device.") > =C2=A0=C2=A0=C2=A0 (mount-point "/boot") > =C2=A0=C2=A0=C2=A0 (type "vfat") > =C2=A0=C2=A0=C2=A0 ;; Not relevant to bootloader.=C2=A0 Default values gi= ven. > =C2=A0=C2=A0=C2=A0 (root-file-system (mounted-root-fs)) ; Error if not fo= und. > =C2=A0=C2=A0=C2=A0 ;; Cons the generated boot FS and mounted root FS to t= his. > =C2=A0=C2=A0=C2=A0 (file-systems %base-file-systems)) > =C2=A0 ...) 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=20 ;; %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