From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 0K4PJjLDD2OIfgEAbAwnHQ (envelope-from ) for ; Wed, 31 Aug 2022 22:23:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id WHUHJjLDD2OTOQEA9RJhRA (envelope-from ) for ; Wed, 31 Aug 2022 22:23:14 +0200 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 3C020BC70 for ; Wed, 31 Aug 2022 22:23:14 +0200 (CEST) Received: from localhost ([::1]:47354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oTUEz-0002pD-FC for larch@yhetil.org; Wed, 31 Aug 2022 16:23:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40200) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oTTUM-0005nk-LX for guix-patches@gnu.org; Wed, 31 Aug 2022 15:35:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:50766) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oTTUM-0005jU-C4 for guix-patches@gnu.org; Wed, 31 Aug 2022 15:35:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oTTUM-0006CU-7f for guix-patches@gnu.org; Wed, 31 Aug 2022 15:35:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#57496] [PATCH 1/2] gnu: bootloader: Extend `' for chain-loader. Resent-From: Julien Lepiller Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 31 Aug 2022 19:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57496 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: tiantian Cc: 57496@debbugs.gnu.org Received: via spool by 57496-submit@debbugs.gnu.org id=B57496.166197445523759 (code B ref 57496); Wed, 31 Aug 2022 19:35:02 +0000 Received: (at 57496) by debbugs.gnu.org; 31 Aug 2022 19:34:15 +0000 Received: from localhost ([127.0.0.1]:40514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTTTa-0006B9-9r for submit@debbugs.gnu.org; Wed, 31 Aug 2022 15:34:15 -0400 Received: from lepiller.eu ([89.234.186.109]:53288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oTTTX-0006Ay-F9 for 57496@debbugs.gnu.org; Wed, 31 Aug 2022 15:34:13 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id 89b08bdb; Wed, 31 Aug 2022 19:34:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=date:from :to:cc:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=dkim; bh=9K7RtLkMCo3Q TPDwLQcTRv5FHe8J3trEtJbpJ3Q3CMg=; b=kpBlndJmb//dqkOFGO0WV+WtTVJH pO5fkFkwbPL66iB+p+zDkvAzXxmuhANMvlcnqGdc5Dr6I7z4zbXJ2d/35LKUHppo 8sv4UnCwZqQLXrGttH8A2Sc4AtE9OpPP78iPo22K+gf5ahtQcvnq9h5OxQC5dmSS RX87sr7tiliEsjzX5a6/UzNtWaJ4fU3QwomXXXROUR1FeVM+li1P/X4VsSgj2vdI A6m92xgyeOrF5BtHid82p08dnOUvRK1fGCdTpL/QC0ieMZ95wTFtfJvLCOp6MvOT hkiFRWkPabfWMVCv+fiE48NvhafWrn7D5O0IPXrktl13f5eP0o2TWQRsOw== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id 289f2752 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 31 Aug 2022 19:34:08 +0000 (UTC) Date: Wed, 31 Aug 2022 21:34:06 +0200 From: Julien Lepiller Message-ID: <20220831213406.3ec92474@sybil.lepiller.eu> In-Reply-To: References: <55016216-84d9-e2e6-8bf5-0efdfa0e6ac1@foxmail.com> X-Mailer: Claws Mail 4.1.0 (GTK 3.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1661977394; h=from:from:sender:sender: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=pWg0StfyGO9TLwxTq4MDlGgZfOElUWmOf9EMF+Q2Iiw=; b=MhZkQ4Vh+w0CVNJ0/Y3Z/8TaQahWkCsCWSMyzIJr/ZV4sEPMlJ2iwYvEpXfEFhphlT7nn5 yf2j6J1OnUzUjmgWtd3dA2yhb/KINziK8ygk15UZYWtZzVuLPCB3Iplq4FxvA+VhYSa/gv SbeN0BYs08rL9XKHArFkADFKapS3VkPYpiDceYgzlRWCBODERzOSgfeXzrsjUPvSCfZZaD wxOynJfnoiDt/HPJo81Y0E9KPqPTK3Bq4LJCAoBI5PQHY9b6nbuldWPSwkbDiO5zP4WtVx H7kL4F0q0kYJd4tbJ+8Do+HzK+KcrI5JBX5Pb8LUCtqdobqRtLBIqDJkBkEn6Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1661977394; a=rsa-sha256; cv=none; b=CYmv0WvkqQppITgvYwMBDDakjwjOTK28j6JNevfJx8kxCvNHC2GwlRrpuhuUW8RGXaigs0 krngwdwDrbfFJvnwJOXi6Eh5iWdsTtuNHqAUauLu+oCpKAUcPmr3MUzqJVeLfs6mgDFFal LlkqCVxL+RrPL4cFqXIqnBbuO7DFrV41hhlaniiQdbKZG82M+dt7qDdmcMLG9batZuVS55 +v0PIPxQ8XC4cTLXikXCOKfN91eRfnKLXZLaELiCD1gI8XxdY8gYZn3u453GEkiIbl/bRS iD+HGD/9DVU9mz7h+pUdIsQEZOSIZrud4I1nlVMbhUT4/aQPuq2mmDHDdR95kQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lepiller.eu header.s=dkim header.b=kpBlndJm; dmarc=fail reason="SPF not aligned (relaxed)" header.from=lepiller.eu (policy=none); 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" X-Migadu-Spam-Score: 6.62 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lepiller.eu header.s=dkim header.b=kpBlndJm; dmarc=fail reason="SPF not aligned (relaxed)" header.from=lepiller.eu (policy=none); 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" X-Migadu-Queue-Id: 3C020BC70 X-Spam-Score: 6.62 X-Migadu-Scanner: scn0.migadu.com X-TUID: L7y0ymbdzXUs Le Thu, 1 Sep 2022 01:55:34 +0800, tiantian a =C3=A9crit : > Dear Mr/Ms Lepiller, >=20 > I'm sorry. I didn't notice the wrong sender name. You don't have to apologize. I received your email and I didn't even notice the sender name :) >=20 > Because my patch was replied so quickly for the first time, I am > excited and hope to reply as soon as possible. >=20 > After the last installation of icedove, the mail client on my > computer, I don't know why icedove lost all configuration information > this time, so I log in again. Icedove defaults to the desktop user > name I set for testing the guix system. In a hurry, I didn't notice > the mistake. >=20 > I checked the contents of the email and tried to make the meaning > accurate. Without noticing that the name of the sender of the mail is > wrong. >=20 > I'm not sure if the previous mail was intercepted in the trash, so I > forward it. >=20 > My mistake was really stupid. I sincerely apologize for disturbing > you. >=20 > Sincerely, > tiantian >=20 > -------- Forwarded Message -------- > Subject: Re: [bug#57496] [PATCH 1/2] gnu: bootloader: Extend > `' for chain-loader. Date: Wed, 31 Aug 2022 20:22:55 +0800 > From: user in guix system > To: Julien Lepiller , 57496@debbugs.gnu.org >=20 > Hi, >=20 > On 2022/8/31 15:18, Julien Lepiller wrote: > > Hi tiantian! > > > > Thanks for the patches. It's a bit hard to follow since I'm not at a > > computer, but here are some preliminary remarks. > > > > First, thanks for documenting the change in the manual, it's not > > something even I think about all the time ^^'. We'll have to rework > > the English a bit but it's understandable :) > > =20 >=20 > My English is not good. Thank you for correcting the document. Let's try something like this: @item @code{chain-loader} (default: @code{#f}) A string that can be accepted by @code{grub}'s @code{chainloader} directive. This has no effect if either @code{linux} or @code{linux-multiboot} fields are specified. The following is an example of chainloading a different GNU/Linux system. >=20 > > I'm wondering why there are two patches? The first patch below seems > > documented but the second patch does not have a changelog text. > > Shouldn't they be merged? They seem to be for the same thing. > > =20 >=20 > I have little submission experience and my English isn't good, so I > refer to the submission history of multiboot. As you can see, my > submission also imitates it. However, I did not modify > like it. On the one hand, I did not understand the > role of . on the other hand, it has successfully > passed the tests on my computer, such as reconfigure, > switch-generation and roll-back. I didn't know about boot-parameters. It sounds like they are related to guix deploy, which I don't use. I think we can still go with your patch, and later add chainloading in boot-parameters if needed. >=20 > If it is better to merge into the first, there is no problem. How can > I do this? Should I send v2 here after local merge, or other? >=20 > commit 1244491a0d5334e1589159a2ff67bbc967b9648b > Author: Jan (janneke) Nieuwenhuizen > Date: Tue May 26 18:09:01 2020 +0200 >=20 > bootloader: grub: Add support for multiboot. >=20 > * gnu/bootloader/grub.scm (grub-configuration-file): Add support > for multiboot. >=20 > commit 912b857ede450828805e09bb718658f79c40703a > Author: Jan (janneke) Nieuwenhuizen > Date: Tue May 26 17:38:30 2020 +0200 >=20 > system: Add 'multiboot-modules' field to . >=20 > * gnu/system.scm ()[multiboot-modules]: New > field. (read-boot-parameters): Initialize it. > (operating-system-multiboot-modules, hurd-multiboot-modules): > New procedure. (operating-system-boot-parameters): Cater for > multiboot the Hurd and initialize it; avoid initrd in that case. > (operating-system-kernel-file): Cater for for Gnumach (the Hurd) > besides Linux. (boot-parameters->menu-entry): Use it to support a > multiboot . >=20 > commit 21acd8d6c11b85d06c82b168807b35cb7d2d0adf > Author: Jan (janneke) Nieuwenhuizen > Date: Tue May 26 16:54:18 2020 +0200 >=20 > bootloader: Extend `' for multiboot. >=20 > * gnu/bootloader.scm > ()[multiboot-kernel,multiboot-arguments, > multiboot-modules]: New fields. [linux,initrd]: Add default value > '#f'. (menu-entry->sexp, sexp->menu-entry): Support multiboot entry. > * doc/guix.texi (Bootloader Configuration): Document them. >=20 OK, I see now. I don't really understand why they were separate, but let's keep them separate for now. > > From what I understand, specifying chainloader with at least linux > > or linux-multiboot will lead to chainloader being silently dropped. > > Maybe we should have an error message instead? > > =20 >=20 > Yes. Thank you for asking this question. I didn't think about it > before. What I can think of now is to complete pattern as follows. > When the chainloader and Linux or multiboot are specified at the same > time, it will report an error message. >=20 > But I feel that this is not elegant, it will make code difficult to > read. I am a beginner of scheme. Could you give me some advice? >=20 > --- >8 --- =20 >=20 > (match entry > (($ label device mount-point linux linux-arguments > initrd #f () () #f) > `(menu-entry (version 0) > (label ,label) > (device ,(device->sexp device)) > (device-mount-point ,mount-point) > (linux ,linux) > (linux-arguments ,linux-arguments) > (initrd ,initrd))) > (($ label device mount-point #f () #f > multiboot-kernel multiboot-arguments > multiboot-modules #f) > `(menu-entry (version 0) > (label ,label) > (device ,(device->sexp device)) > (device-mount-point ,mount-point) > (multiboot-kernel ,multiboot-kernel) > (multiboot-arguments ,multiboot-arguments) > (multiboot-modules ,multiboot-modules))) > (($ label device mount-point #f () #f #f () () > chain-loader) > `(menu-entry (version 0) > (label ,label) > (device ,(device->sexp device)) > (device-mount-point ,mount-point) > (chain-loader ,chain-loader)))) >=20 > --- <8 --- I prefer this variant where the pattern is explicit. As with what we have today, if the user specifies more than one of linux, linux-multiboot and chainloader, they get an unhelpful "no matching pattern" error. This could be done later if you don't have time, but I would suggest to fix it by adding a default case that matches all incorrect cases, like so: (_ (raise (condition (&message (message (G_ "Your error message here")))))) Have a look at other "&message" conditions for inspiration. Also I noticed that if all of linux, linux-multiboot and chainloader are #f, then the first pattern matches and will lead to a different error message. I haven't tested so I'm not sure what we get, but it might be interresting to match on all of them being #f, and print a different message. Again, this can be done later. >=20 > > I'm not too familiar with chainloading. Is using grub partition > > names like (hd0,gpt1) the only way? We try to discourage using > > these names as they can easily vary between reboots and your system > > unbootable.=20 >=20 > It can also use device to specify the disk partition. The following is > the menu-entry that I am using. >=20 > --- >8 --- =20 >=20 > (menu-entries > (list > (menu-entry > (label "ArchLinux") > (device (uuid "1C31-A17C" 'fat)) > (chain-loader "/EFI/ArchLinux/grubx64.efi")))) >=20 > --- <8 --- >=20 > The examples in the document were written before the bug#57307 was > fixed. At that time, only this example passed the test on my > computer. I didn't take into account that the example was bad. I'm > sorry. This new example is perfect. Could you add it to your next patch? >=20 > I'm sorry, because I don't know how to paste the code snippet in the > mail. After seeing your reply, after a long search, no good example > was found. I don't know if there is a problem when I write the code > snippet like this. If there is any problem, I'm sorry. They came out fine. I don't use anything fancy to read emails, so I don't really care. I think emacs might have something to show snippets of code better. >=20 > Thank you very much for checking and correcting my patches. Could you send a v2 with the changes we discussed so far? Thanks, Julien >=20 > Thanks, > tiantian >=20 >=20