From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id YFV5K0T0/2apcwAAqHPOHw:P1 (envelope-from ) for ; Fri, 04 Oct 2024 13:57:24 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id YFV5K0T0/2apcwAAqHPOHw (envelope-from ) for ; Fri, 04 Oct 2024 15:57:24 +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=FRhW8pbP; dkim=fail ("headers rsa verify failed") header.d=rimm.ee header.s=herman header.b=TK47hc+m; 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=1728050244; 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=i6fo2qRTNRAvvyejDkIGvUMNEHovvWnVaqXZP9vEcYw=; b=arJRYRJ0hV2dRjmME5qnSFamYgMaIU19cPfmUyJ4CQz45SGADY+7dhDCjYOX0GquYDSRo7 gnzA7awBjEsMILkN4+RXn7MqUUQe6Jh3h71TCJcE8D1y8QkjIzlntO5fpFGA4zM5PBJY+N Ts74GnLwW/62DhZs6B9psTe9hH6VG5Po1c3IjWr8I8FDefap9g71B+B+14Q3/hhh5r0up8 fi46jr59UIXDnnINkEvuxmAYOCUk9KQGkm1D/vIysjd9ryEkop8pZogB7Kpr+hktBmY1W0 RzicouyOEyX7FBJS07e6F3nP35KU1xiytqv6rSjkgE8GdCye3+3su7YAiln30w== 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=FRhW8pbP; dkim=fail ("headers rsa verify failed") header.d=rimm.ee header.s=herman header.b=TK47hc+m; 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-Seal: i=1; s=key1; d=yhetil.org; t=1728050244; a=rsa-sha256; cv=none; b=lgVacmOBVj2JiMOXYjKbLMiYGegpZ6zZTvmxySRSDf65flGoWBj3VFs/PPYsMo4HOL8Tpn lqLUlmmfeuVGfWObaaNb4TXUsy/DjO6INNbFb2oQoSAtWubxwi3BbRfpNumqTacQ8D5P1m OeGR17VN5YFm67g/WY4yd/iOshv8w/gaofZzv5e+K9ZOMXe1RiXhgpiGs8RaGZgqTVDehP CjTdNw+jFcbJM9nh5lXBTe6muDZOAHZ6gHVQDXrTcQUOYwsEU0pFzRvYbJKdP8vv+xe3fw Le96xvbegdaN3ggYL7vXezJ3r4APHKyew65Ss+yBIShcP0Ncsw/fkjXHTZ/W1Q== 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 3EF3747DF0 for ; Fri, 04 Oct 2024 15:57:23 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1swinn-0002R7-HJ; Fri, 04 Oct 2024 09:57:03 -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 1swink-0002Qx-Dc for guix-patches@gnu.org; Fri, 04 Oct 2024 09:57:00 -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 1swink-0007mV-4w for guix-patches@gnu.org; Fri, 04 Oct 2024 09:57:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:MIME-Version:References:From:Date:To:Subject; bh=i6fo2qRTNRAvvyejDkIGvUMNEHovvWnVaqXZP9vEcYw=; b=FRhW8pbPB8p/ZiQ5GsmHT6Gud1C9emuuLGlmGrcNxn92iDw7UCbg2Utly8RnzozlXO0I7XxIIgdHpoIQUhHPTLGf/pKmLh731zw+GVFWO285ORiHbbKjN6f9CCkVAJuGLBXy504fN+mUj8fx1jCLzX1nmltt1nMGc6sk2Zq0axm74SpYojtO9x5OLDohJOjsY7Gaj2pMNKxBxxWHqTqBRFQtzLpfwnzZLgxOb0R+/l3cbGhX6bw3DeD2PCkLAlx/+NlFCsm8uxoaTZFh3TQN5uJspf1nEhrCIMLiiADcDTqLiDhwvnbqCzImZD9stzqaM3wzAM+8r8jojatKBpJHdA==; Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1swinm-0007hK-7M for guix-patches@gnu.org; Fri, 04 Oct 2024 09:57:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#73202] [PATCH] Preparation for bootloader rewrite. Resent-From: Herman Rimm Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 04 Oct 2024 13:57: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: Lilah Tascheter Received: via spool by 73202-submit@debbugs.gnu.org id=B73202.172805018429574 (code B ref 73202); Fri, 04 Oct 2024 13:57:02 +0000 Received: (at 73202) by debbugs.gnu.org; 4 Oct 2024 13:56:24 +0000 Received: from localhost ([127.0.0.1]:36148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swinA-0007gw-17 for submit@debbugs.gnu.org; Fri, 04 Oct 2024 09:56:24 -0400 Received: from 81-205-150-117.fixed.kpn.net ([81.205.150.117]:36009 helo=email.rimm.ee) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1swin7-0007go-FY for 73202@debbugs.gnu.org; Fri, 04 Oct 2024 09:56:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rimm.ee; s=herman; t=1728050169; h=from:from: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: in-reply-to:in-reply-to:references:references; bh=i6fo2qRTNRAvvyejDkIGvUMNEHovvWnVaqXZP9vEcYw=; b=TK47hc+mME8jzZYy+r4URPhj10f1LKzz2LUbnEnI7eDeNHUQZD3WO1XEPWuNVLx8UnH18H DND/xruk0s5NLLmCg80DhG7j2ScQTlrTM9PXpTX1dNf7nL4foaWzXT480rOJqfSXXDVKBe cDSMPMWFt5pcjJ6Wl5aFpIViIPe+PAR8nKikY3PCmbaftycOykAGE/RguI5IKMXxJDiG2k Zzln1PT8ox6aPJlji4kGwoEug9OLZk136vizqHZck/Mg+8dmuL4gw5sgHapdCznIpkVxb5 EoBGwYNgD8fzaRoWZvLKS34KtobJNUyhE+NF7IRwMmPxn7KbOAaqWeqgq2zfFw== Received: by 81-205-150-117.fixed.kpn.net (OpenSMTPD) with ESMTPSA id d318c624 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO); Fri, 4 Oct 2024 13:56:09 +0000 (UTC) Date: Fri, 4 Oct 2024 15:55:33 +0200 Message-ID: References: <4fnudiucjxequd3m4ayy7drqsgjokybfvsu6l2tbssurhlr5wd@odqr53qw5qqz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: , Reply-to: Herman Rimm X-ACL-Warn: , Herman Rimm via Guix-patches From: Herman Rimm via Guix-patches via Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: 0.43 X-Spam-Score: 0.43 X-Migadu-Queue-Id: 3EF3747DF0 X-TUID: hO7hUYIVoJNy 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)) ...)