From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 2AeCOfJUlF8SbQAA0tVLHw (envelope-from ) for ; Sat, 24 Oct 2020 16:23:14 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id UE92NfJUlF+9BQAA1q6Kng (envelope-from ) for ; Sat, 24 Oct 2020 16:23:14 +0000 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 1CEEF940439 for ; Sat, 24 Oct 2020 16:23:14 +0000 (UTC) Received: from localhost ([::1]:33666 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWMK0-0004YQ-VS for larch@yhetil.org; Sat, 24 Oct 2020 12:23:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWMJq-0004Y6-Rf for guix-patches@gnu.org; Sat, 24 Oct 2020 12:23:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:51652) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWMJq-0000I7-Gb for guix-patches@gnu.org; Sat, 24 Oct 2020 12:23:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWMJq-0003i9-Bl for guix-patches@gnu.org; Sat, 24 Oct 2020 12:23:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#41066] [PATCH] gnu: bootloader: Support for chain loading. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 24 Oct 2020 16:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41066 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Danny Milosavljevic Cc: Stefan , Mathieu Othacehe , 41066@debbugs.gnu.org, Efraim Flashner , Maxim Cournoyer Received: via spool by 41066-submit@debbugs.gnu.org id=B41066.160355658114244 (code B ref 41066); Sat, 24 Oct 2020 16:23:02 +0000 Received: (at 41066) by debbugs.gnu.org; 24 Oct 2020 16:23:01 +0000 Received: from localhost ([127.0.0.1]:34965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWMJo-0003hg-RO for submit@debbugs.gnu.org; Sat, 24 Oct 2020 12:23:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54128) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWMJm-0003hT-Qb for 41066@debbugs.gnu.org; Sat, 24 Oct 2020 12:22:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49381) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWMJf-0000GB-6z; Sat, 24 Oct 2020 12:22:51 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=52100 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kWMJe-0002ot-C1; Sat, 24 Oct 2020 12:22:50 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <7A4ABEA8-4500-4D55-BCCE-BFB37FB06B2C@vodafonemail.de> <20200524131316.4c6e8a50@scratchpost.org> <3197004D-0131-4781-99FD-60EBE434E794@vodafonemail.de> <023CBBED-35CD-4AD3-97C4-0DE0B7623B9A@vodafonemail.de> <6E5ECFBA-57F4-485F-9403-1D04CF82062D@vodafonemail.de> <4D71A75A-5722-457C-A5CE-98CE51A53450@vodafonemail.de> <975EC414-6A81-444B-9BB0-AE303C6A9511@vodafonemail.de> <20201022194630.597302a2@scratchpost.org> <87eelpp0pn.fsf@gnu.org> <20201024033051.00720ac1@scratchpost.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 3 Brumaire an 229 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Sat, 24 Oct 2020 18:22:48 +0200 In-Reply-To: <20201024033051.00720ac1@scratchpost.org> (Danny Milosavljevic's message of "Sat, 24 Oct 2020 03:30:51 +0200") Message-ID: <87a6wbiofb.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -3.3 (---) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -0.01 X-TUID: FyyodyiLq6z7 Hi, Danny Milosavljevic skribis: > On Fri, 23 Oct 2020 14:48:36 +0200 > Ludovic Court=C3=A8s wrote: > >> (bootloader-chain grub-efi-netboot-bootloader >> (list (file-append u-boot "/libexec/u-boot.bin") >> (file-append firmware "/firmware"))) > > Ohhh! That's right. That's much better. Can a profile be created with = those > in it? Especially because of the profile hook... Yes, there=E2=80=99s first-class objects that one can use in gexp= s: (profile (content (manifest (entries =E2=80=A6)))) >> I think we should look at how to simplify this interface. Intuitively, >> I would expect the =E2=80=98bootloader-chain=E2=80=99 to take a list of = >> records and return a record. >> Is this something that can be achieved? If not, what are the extra >> constraints that need to be taken into account? > > That is not easily possible, and is also logically not what happens anywa= y. > > The use case of this entire patchset is when one (for some reason) can't = boot > the final bootloader directly, then one uses some chain of bootloaders to > get the final bootloader to boot. > > That especially means that all the bootloaders before the final bootloader > WILL NOT GET THE GUIX GENERATIONS MENU. > > It is also pretty uncommon/impossible to use each usual bootloader instal= ler > in order to install all the bootloaders one after another. Just think of > what would happen if multiple x86_64 bootloaders all tried to install > themselves into the first sector of the drive. That's not gonna work > correctly. > > What actually happens is that there's some kind of payload area in the fi= rst > bootloader where you can put the second bootloader, and some kind of payl= oad > area in the second bootloader where you can put the third bootloader... a= nd so > on. Except for the final bootloader, which has the Linux kernel in the p= ayload > area (as far as the final bootloader is concerned, it can do everything a= s if > it was the first and only thing that was loaded at boot so far). > > That means the final bootloader can use the normal config files and gener= ally > proceed like all our standalone bootloaders do. None of the previous boo= tloaders > in the chain can do that, generally. Sorry, I don=E2=80=99t see why this prevents an API that more closely match= es the idea of a chain of bootloaders (but perhaps I=E2=80=99d just need to sp= end more time studying this.) I guess my advice is: design an interface that=E2=80=99s as close as possib= le to the concepts at hand. If implementation details constrain what can be done, that=E2=80=99s OK, but it should be clear in that case why we end up = with an interface that=E2=80=99s not as simple as one could expect. >>bootloader-profile > >> Yes, if it=E2=80=99s about building a profile, you could just use a >> object. Would that work here? > > Huh? Isn't he doing that already? > > That's what that procedure does. Or am I misunderstanding? It=E2=80=99s not using code from (guix profiles) IIRC. >> >From a quick look at the patch, I don=E2=80=99t fully understand yet wh= at=E2=80=99s=20=20 >> going on. > > I suggested to Stefan to use a profile with a profile hook in order to > configure all those bootloaders of a bootloader chain correctly. That's > what he does here. > > Usually, Guix bootloader *packages* have a lot of junk that (1) you would= n't > want on a esp partition (wastes space) and also stuff that would be dupli= cates > with other bootloaders (COPYING etc). Therefore, it's nice to be able to > filter what files of those packages get used. I think your suggestion in= the > beginning is the best one. (file-append u-boot "/libexec/u-boot.bin") in= deed! > The profile hook can then use whatever methods to configure all those > bootloaders correctly. Alrighty! Thanks, Ludo=E2=80=99.