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 CHj5DV1Kyl6lEQAA0tVLHw (envelope-from ) for ; Sun, 24 May 2020 10:20:13 +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 JU/aCV1Kyl5deAAA1q6Kng (envelope-from ) for ; Sun, 24 May 2020 10:20:13 +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 AE98894030E for ; Sun, 24 May 2020 10:20:11 +0000 (UTC) Received: from localhost ([::1]:35000 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcnjk-0004rI-TP for larch@yhetil.org; Sun, 24 May 2020 06:20:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcnjf-0004qy-0X for guix-patches@gnu.org; Sun, 24 May 2020 06:20:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:53219) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcnje-0001NN-NR for guix-patches@gnu.org; Sun, 24 May 2020 06:20:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jcnje-0007kr-IK for guix-patches@gnu.org; Sun, 24 May 2020 06:20:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs. Resent-From: Stefan Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 24 May 2020 10:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41011 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Mathieu Othacehe Cc: 41011@debbugs.gnu.org Received: via spool by 41011-submit@debbugs.gnu.org id=B41011.159031554429737 (code B ref 41011); Sun, 24 May 2020 10:20:02 +0000 Received: (at 41011) by debbugs.gnu.org; 24 May 2020 10:19:04 +0000 Received: from localhost ([127.0.0.1]:36532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcnii-0007jY-Bv for submit@debbugs.gnu.org; Sun, 24 May 2020 06:19:04 -0400 Received: from vsmx009.vodafonemail.xion.oxcs.net ([153.92.174.87]:17776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jcniV-0007ir-Bm for 41011@debbugs.gnu.org; Sun, 24 May 2020 06:19:03 -0400 Received: from vsmx001.vodafonemail.xion.oxcs.net (unknown [192.168.75.191]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id ED4B3159DD26; Sun, 24 May 2020 10:18:45 +0000 (UTC) Received: from macbook-pro.kuh-wiese.my-router.de (unknown [2.206.141.243]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 68AEE159DD4E; Sun, 24 May 2020 10:18:39 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Stefan In-Reply-To: <87h7w7cc55.fsf@gnu.org> Date: Sun, 24 May 2020 12:18:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <92DB8E2B-1CA2-41AE-9265-53C4F5337686@vodafonemail.de> References: <9AAFEFF4-8ACE-4C95-975F-67C3F4FDAF81@vodafonemail.de> <87a72gi4kz.fsf@gmail.com> <1179D890-7D6C-43D8-A286-DA7A0F61D585@vodafonemail.de> <87h7w7cc55.fsf@gnu.org> X-Mailer: Apple Mail (2.3124) X-VADE-STATUS: LEGIT X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.7 (-) 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=none; 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.99 X-TUID: 8FzwIpQLhNdm Hi Mathieu! > Am 23.05.2020 um 10:02 schrieb Mathieu Othacehe : >=20 >> It reads this information form /var/guix/profiles/system/parameters: = (bootloader-name grub-efi-bootloader). >> With this again the hard-coded path =E2=80=9C/boot/grub.cfg=E2=80=9D = is used, ignoring any value overwritten in (configuration-file). >=20 > Oh, we need to fix that! It means that we would need to add a > "bootloader-configuration-file" field to record, is > that correct? Yes, I would guess so. But I=E2=80=99m not sure, if the field = bootloader-name can be dropped then from . But if, then = we could probably also drop the field name from the record.=20= >> Another issue is (install-dir (string-append mount-point "/boot")) in = (install-grub-efi), which ignores any (configuration-file) setting, too = =E2=80=93 well, it has no access to that setting =E2=80=93, and implies = at least =E2=80=9C/boot=E2=80=9D to be the prefix of (bootloader (target = =E2=80=A6)).=20 >>=20 >> Beside the wish to avoid this hard-coded =E2=80=9C/boot=E2=80=9C = assumption, I made this a function with two parameters for two more = reasons.=20 >=20 > Could it be an option to infer the bootloader installation directory = and > the efi subdir from the install-grub-efi/install-grub-efi-net = functions? > If TARGET is /boot-nfs/efi/Guix", could we suppose that the > boot-directory is "/boot-nfs" and the efi-subdir is "efi/Guix"? For the new install-grub-efi-net I see first of all no issue in keeping = it a function. This gives the needed flexibility. For the existing grub-efi-bootloader the assumption seems to be that = there will always be a /boot/grub.cfg. This is just not stated in the = documentation. But it gave me the impression that there is some control = about it with (bootloader (target =E2=80=A6) =E2=80=A6). But this is not = the case. For the legacy grub-bootlouder the (bootloader (target =E2=80=A6= ) =E2=80=A6) needs to be a device, and the /boot/grub.cfg is implied and = hard coded as well. Actually thinking about it again, mounting the efi partition at e.g. = /foo/efi, doesn't brake anything in the first place. Then GRUB will be = installed at the target /foo/efi, basically into the efi partition it = belongs. It will just read its configuration from /boot/grub.cfg, from a = different partition. The actual difference to the new grub-efi-net-bootloader is that it has = only TFTP access to its files and its configuration file; there is only = one place to lookup both, instead of two partitions in case of the = grub-efi-bootloader. For deleting system generations the path to the always present, not = configurable /boot/grub.cfg is looked up. This works for the existing = grub-efi-bootloader and grub-bootloader. But it does not work for the = grub-efi-net-bootloader, because its configuration file does not live at = /boot/grub.cfg, as its path is now implicitly configurable via = (bootloader (target =E2=80=A6) =E2=80=A6). In addition for my setup I = used a /boot-nfs folder instead of a /boot folder, and saw no benefit = then in keeping the /boot folder. I think there is a second possibility. It may be possible to create a = symlink from /boot-nfs/efi/boot/grub.cfg to ../../../boot/grub.cfg. Then = the assumption that there will always be a /boot/grub.cfg file stays = valid.=20 But personally I do not like this idea. In it seems =E2=80=93 but I=E2=80=99m not sure yet =E2=80= =93 that we only keep a symbol name to figure out the path to the = grub.cfg, although it is possible to just put that path directly there = instead. And using the symbol makes it hard do get a configurable = bootloader: A new bootloader has to be a variable, tricks with macros = come up. Also inheriting from a bootloader and overwriting the = configuration-file field =E2=80=93 for whatever reason =E2=80=93 is = problematic: It seems to work at the beginning, but only fails badly = when removing a system generation. It seems to have subtle bugs. It=E2=80=99= s not usable like other parts in guix. It=E2=80=99s not hackable. I=E2=80=99= d really prefer to change this. > The make-grub-efi-net-bootloader macro is a nice hack, but I fear that > it makes the bootloader configuration (even more) difficult. At least it gives me the flexibility which was missing so far. I suggest = to keep it for the moment and do a different patch once we are clear = which way to go. If we add a bootloader-configuration-file field to the = record, than the macro can be removed anyway. Bye Stefan=