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 7CSfNtMHWF/wBAAA0tVLHw (envelope-from ) for ; Tue, 08 Sep 2020 22:38:11 +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 0FPrMdMHWF8HcgAA1q6Kng (envelope-from ) for ; Tue, 08 Sep 2020 22:38:11 +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 165C49404CB for ; Tue, 8 Sep 2020 22:38:11 +0000 (UTC) Received: from localhost ([::1]:39222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFmFc-000226-KG for larch@yhetil.org; Tue, 08 Sep 2020 18:38:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48006) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFmFW-00021w-Ib for guix-patches@gnu.org; Tue, 08 Sep 2020 18:38:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45144) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kFmFW-0007Ji-9r for guix-patches@gnu.org; Tue, 08 Sep 2020 18:38:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kFmFW-0005vP-6v for guix-patches@gnu.org; Tue, 08 Sep 2020 18:38:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs. Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Tue, 08 Sep 2020 22:38: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: Stefan Cc: 41011@debbugs.gnu.org Received: via spool by 41011-submit@debbugs.gnu.org id=B41011.159960466222751 (code B ref 41011); Tue, 08 Sep 2020 22:38:02 +0000 Received: (at 41011) by debbugs.gnu.org; 8 Sep 2020 22:37:42 +0000 Received: from localhost ([127.0.0.1]:56690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFmFB-0005ur-Tw for submit@debbugs.gnu.org; Tue, 08 Sep 2020 18:37:42 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:42092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFmF8-0005ud-Vq for 41011@debbugs.gnu.org; Tue, 08 Sep 2020 18:37:40 -0400 Received: from localhost (80-110-126-103.cgn.dynamic.surfer.at [80.110.126.103]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 2C09C3363C04; Wed, 9 Sep 2020 00:37:36 +0200 (CEST) Date: Wed, 9 Sep 2020 00:37:32 +0200 From: Danny Milosavljevic Message-ID: <20200909003732.5c401932@scratchpost.org> In-Reply-To: <45F0D825-F888-42E9-BDAE-7BB6FA010A6E@vodafonemail.de> References: <9AAFEFF4-8ACE-4C95-975F-67C3F4FDAF81@vodafonemail.de> <20200906163559.1b56c36f@scratchpost.org> <45F0D825-F888-42E9-BDAE-7BB6FA010A6E@vodafonemail.de> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/84XO61oIHrsS/4w0YjT3vGx"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) 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: -1.11 X-TUID: Df+SQslVGPtY --Sig_/84XO61oIHrsS/4w0YjT3vGx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Stefan, On Tue, 8 Sep 2020 00:59:38 +0200 Stefan wrote: > In the end this is a grub-efi for booting over network.=20 >Would grub-efi-netboot be an even better name? It will not work with BIOS = machines. Oh, then definitely let's use that name. > I only need the first list element here. I will use (first =E2=80=A6). Okay. (I leave it to the others to comment on here if they have a problem with it= --I see no downside in this case) > >> + (efi-bootloader-link (string-append "/boot" =20 > > =20 > >> + (match arch > >> + ("i686" "ia32") > >> + ("x86_64" "x64") > >> + ("arm" "arm") > >> + ("armhf" "arm") > >> + ("aarch64" "aa64") > >> + ("riscv" "riscv32") > >> + ("riscv64" "riscv64")) > >> + ".efi")) =20 > >=20 > > Also, I have a slight preference for greppable file names even when it'= s a > > little more redundant, so more like that: > >=20 > > (match system-parts > > (("i686" _ ...) "ia32.efi") > > (("x86_64" _ ...) "x64.efi") > > (("arm" _ ...) "arm.efi") > > (("armhf" _ ...) "arm.efi") > > (("aarch64" _ ...) "aa64.efi") > > (("riscv" _ ...) "riscv32.efi") > > (("riscv64" _ ...) "riscv64.efi")) =20 >=20 > I=E2=80=99m not familiar with the match syntax yet. For me using the firs= t element as arch seems simpler. Match just does pattern matching. The pattern here is for example ("i686" = _ ...). That means it will match anything that is a list that is starting with "i68= 6". It will put the remainder (...) into the variable "_" (which is customary to use as "don't care" variable). The major advantage of using "match" is its failure mode. If the thing mat= ched on is not a list (for some unfathomable reason) or if the first element is = not matched on (!) then you get an exception--which is much better than doing w= eird unknown stuff. You have used "match" before--but only on parts of the list. Why not use it on the whole list? It makes little sense to do manual destructuring and th= en use match--when match would have done the destructuring bind anyway. > > Likewise: > >=20 > > (efi-bootloader (match system-parts > > (("i686" _ ...) "i386-efi/core.efi") > > (("x86_64" _ ...) "x86_64-efi/core.efi") > > (("arm" _ ...) "arm-efi/core.efi") > > (("armhf" _ ...) "arm-efi/core.efi") > > (("aarch64" _ ...) "arm64-efi/core.efi") > > (("riscv" _ ...) "riscv32-efi/core.efi") > > (("riscv64" _ ...) "riscv64-efi/core.efi")))) = =20 >=20 > I=E2=80=99d prefer to keep the still grepable =E2=80=9C/core.efi=E2=80=9D= separate. Sure. > And yes, when using =E2=80=98guix system init /etc/config.scm /mnt/here= =E2=80=99, then MOUNT-POINT and TARGET are concatenated. But this is nothin= g specific to the new installer, this is the usual behaviour of Guix and th= e reason for the two parameters TARGET and MOUNT-POINT to any bootloader in= staller. I don=E2=80=99t think stating this inside the new doc-string is th= e right place. Ah, so that's what it means. Well, it should be stated *somewhere* at least. It probably is and I just didn't see it. > Yes, correct. I=E2=80=99ll rework this with the (symlink-relative) functi= on you mentioned. Thanks! > > So TARGET is relative to MOUNT-POINT ? > > And MOUNT-POINT is assumed to have a slash at the end ? =20 >=20 > MOUNT-POINT is either =E2=80=98/=E2=80=99 or depends on the argument to = =E2=80=98guix system init=E2=80=99. On the other side TARGET has to be an a= bsolute path, so it should be safe. At least (install-grub-efi) makes the s= ame mistake. What do you think? If grub-efi does it then it seems to be fine to do it--at least we didn't g= et bug reports caused by it. Let's just keep using it for the time being. > >> + (store-name (car (delete "" (string-split bootloader #= \/)))) =20 > >=20 > > Maybe use match. =20 >=20 > I=E2=80=99ll use (first =E2=80=A6). >=20 > > Also isn't there an official way to find out how the store is called ? > > (%store-prefix) ? =20 >=20 > I only need the first path element to the store, which is usually /gnu. T= he %store-prefix contains /gnu/store then. So it makes no difference. I have no strong opinion either way, except please add a comment that you are extracting part of the store prefix (or whatever) from the in-store name of the bootloader store item. It seems weird to me to do that--but then again I don't get why Guix has two directories (/gnu and /gnu/store) to the store anyway. Fine, I guess. I'm not sure whether it would be technically possible to have a custom store directory like "/foo" without "/gnu" as the store. That would be a problem--and I'm sure someone somewhere does that--otherwise, why have %store-prefix as a variable otherwise? > >> + (store (string-append up1 store-name)) =20 > >=20 > > (string-append escape-target store-name) > > =20 > >> + (store-link (string-append net-dir store-name)) =20 > >=20 > > *mumbles to self* (string-append MOUNT-POINT TARGET) is net-dir. > > So it tries to get to (string-append MOUNT-POINT "/gnu"). =20 >=20 > The trouble is that GRUB shall load a file like /gnu/store/=E2=80=A6-linu= x=E2=80=A6/Image via TFTP, but the TFTP root is actually Guix=E2=80=99 fina= l /boot folder. >=20 > In the end this creates a relative symlink as ../gnu pointing from /mnt/h= ere/boot/gnu to /mnt/here/gnu. >=20 > And GRUB=E2=80=99s =E2=80=9Cworking directory=E2=80=9D to search for its = modules and the grub.cfg is defined by its =E2=80=98prefix=E2=80=99 variabl= e, which is set through the SUBDIR argument, which defaults to Guix=E2=80= =99 final /boot/efi/Guix. >=20 > This requires a relative symlink as ../../../boot/grub/grub.cfg pointing = from /mnt/here/boot/efi/Guix/grub.cfg to /mnt/here/boot/grub/grub.cfg. >=20 > And be aware that TARGET may be /boot, but could be something else like /= tftp-root. Then the symlink would point from /mnt/here/tftp-root/efi/Guix/g= rub.cfg to /mnt/here/boot/grub/grub.cfg, as the later is kind of hard-coded. Please add that to comments in the source code. Otherwise, it would be very probable to be broken by further maintenance. --Sig_/84XO61oIHrsS/4w0YjT3vGx Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl9YB60ACgkQ5xo1VCww uqUmIAgAic8c/mwPCrQCQ2NIhg2W6JHUdqKba5gsezZDi3nZe+js+SNZ8UYDgfXu GypYlur6DTfPrTb3VtZxubkJEvmKhGD8Ld7sgziGqKbA8hUY4w7cHaJ6gMkm9XKW cwj59VkY+Y4TqCMO0aM7rPC2zJmI9fIe+v+rwn/BB0VawA55QUuOLEV13Fjni0s7 RspHPkl/YCQuquHDG+Mf7dE3oBRTfXQ0ME4e7XqYPpvdEn/db0IaZUqX+/deP5yA 25FYV9Zx+4LpqZpaXX3TThYpvwWnmGhbsak/DkAoLQIn9Z18YrT+/A+1aXNtORqg nJOLspGdq+s7/DPOsFk9CNk3BQ75Jg== =pqkk -----END PGP SIGNATURE----- --Sig_/84XO61oIHrsS/4w0YjT3vGx--