From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SP0kBHm7Vl94XQAA0tVLHw (envelope-from ) for ; Mon, 07 Sep 2020 23:00:09 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id +MkkAHm7Vl+tQwAAbx9fmQ (envelope-from ) for ; Mon, 07 Sep 2020 23:00:09 +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 79EC294013C for ; Mon, 7 Sep 2020 23:00:08 +0000 (UTC) Received: from localhost ([::1]:51384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFQ7L-0008Ig-GU for larch@yhetil.org; Mon, 07 Sep 2020 19:00:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37974) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFQ7G-0008IH-LJ for guix-patches@gnu.org; Mon, 07 Sep 2020 19:00:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:39801) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kFQ7G-0004aq-Aa for guix-patches@gnu.org; Mon, 07 Sep 2020 19:00:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kFQ7G-0004p6-5F for guix-patches@gnu.org; Mon, 07 Sep 2020 19:00: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: Mon, 07 Sep 2020 23:00: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: Danny Milosavljevic Cc: 41011@debbugs.gnu.org Received: via spool by 41011-submit@debbugs.gnu.org id=B41011.159951959418497 (code B ref 41011); Mon, 07 Sep 2020 23:00:02 +0000 Received: (at 41011) by debbugs.gnu.org; 7 Sep 2020 22:59:54 +0000 Received: from localhost ([127.0.0.1]:51347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFQ78-0004oH-2K for submit@debbugs.gnu.org; Mon, 07 Sep 2020 18:59:54 -0400 Received: from vsmx011.vodafonemail.xion.oxcs.net ([153.92.174.89]:46874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kFQ74-0004o0-LE for 41011@debbugs.gnu.org; Mon, 07 Sep 2020 18:59:53 -0400 Received: from vsmx003.vodafonemail.xion.oxcs.net (unknown [192.168.75.197]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id 1401059D342; Mon, 7 Sep 2020 22:59:44 +0000 (UTC) Received: from macbook-pro.kuh-wiese.my-router.de (unknown [178.5.77.113]) by mta-7-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 9938D539A8F; Mon, 7 Sep 2020 22:59: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: <20200906163559.1b56c36f@scratchpost.org> Date: Tue, 8 Sep 2020 00:59:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45F0D825-F888-42E9-BDAE-7BB6FA010A6E@vodafonemail.de> References: <9AAFEFF4-8ACE-4C95-975F-67C3F4FDAF81@vodafonemail.de> <20200906163559.1b56c36f@scratchpost.org> X-Mailer: Apple Mail (2.3124) X-VADE-STATUS: LEGIT 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: -0.51 X-TUID: qMMZSLTCyLVH Hi Danny! > In this case, the man page grub-mknetdir(8) mentions "netboot" ? > Do you think "net" or "netboot" is a better name for this = functionality ? At there is = only a single hit for =E2=80=98netboot=E2=80=99 which is in =E2=80=9CTo = generate a netbootable directory, run:=E2=80=9D. All GRUB variables and commands have the prefix =E2=80=98net_=E2=80=99. But I agree, grub-netboot seems to be a more describing name. In the end this is a grub-efi for booting over network. Would = grub-efi-netboot be an even better name? It will not work with BIOS = machines. > Let's not use arcane Scheme anachronisms like "car". I know most = Scheme > programmers probably know what it does--but still, better not to use > names of registers of a machine no one uses anymore. >=20 > Better something like this: >=20 > (let* ((system-parts (string-split (or (%current-target-system) > (%current-system)) > #\-))) I only need the first list element here. I will use (first =E2=80=A6). >> + (efi-bootloader-link (string-append "/boot" >=20 >> + (match arch >> + ("i686" "ia32") >> + ("x86_64" "x64") >> + ("arm" "arm") >> + ("armhf" "arm") >> + ("aarch64" "aa64") >> + ("riscv" "riscv32") >> + ("riscv64" = "riscv64")) >> + ".efi")) >=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")) I=E2=80=99m not familiar with the match syntax yet. For me using the = first element as arch seems simpler. >> + (efi-bootloader (string-append (match arch >> + ("i686" "i386") >> + ("x86_64" "x86_64") >> + ("arm" "arm") >> + ("armhf" "arm") >> + ("aarch64" "arm64") >> + ("riscv" "riscv32") >> + ("riscv64" "riscv64")) >> + "-efi/core.efi"))) >=20 > 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")))) I=E2=80=99d prefer to keep the still grepable =E2=80=9C/core.efi=E2=80=9D = separate. >> + #~(lambda (bootloader target mount-point) >=20 >> + "Install GRUB as e.g. \"bootx64.efi\" or \"bootarm64.efi\" = \"into >> +SUBDIR, which is usually \"efi/boot\" or \"efi/Guix\" below the = directory TARGET >> +for the system whose root is mounted at MOUNT-POINT." >=20 > I think you mean: >=20 >> + "Install GRUB as e.g. \"bootx64.efi\" or \"bootarm64.efi\" = \"into >> +SUBDIR (which is usually \"efi/boot\" or \"efi/Guix\") below the = directory TARGET >> +for the system whose root is mounted at MOUNT-POINT." Yes. >> + (let* (;; Use target-depth and subdir-depth to construct = links to >> + ;; "../gnu" and "../../../boot/grub/grub.cfg" with = the correct >> + ;; number of "../". Note: This doesn't consider ".." = or ".", >> + ;; which may appear inside target or subdir. >=20 > Uhhhh... that could use some more explanationary comments in the = source code > of why it is done in the first place. I=E2=80=99ll put an explanation into the doc-string. This is because the = grub.cfg and the store both need to be accessible to GRUB via TFTP, but = the TFTP root is TARGET, which is usually /boot. > Also, is TARGET itself assumed to be an absolute path or is it = relative to > something else ? According to the rest of the patch it's relative to > MOUNT-POINT--but please state this explicitly in the docstring. TARGET is the (operating-system (boot-loader (target "/boot") =E2=80=A6) = =E2=80=A6). I think this has to be an absolute path, but I didn=E2=80=99t = find any checks for this. But the manual doesn=E2=80=99t mention this, = just all examples are using absolute paths. 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 nothing specific to the new installer, this is the usual = behaviour of Guix and the reason for the two parameters TARGET and = MOUNT-POINT to any bootloader installer. I don=E2=80=99t think stating = this inside the new doc-string is the right place. >> + (target-depth (length (delete "" (string-split target = #\/)))) >=20 >> + (subdir-depth (length (delete "" (string-split = #$subdir #\/)))) >=20 >> + (up1 (string-join (make-list target-depth "..") "/" = 'suffix)) >=20 > Maybe better name: escape-target or something. >=20 >> + (up2 (string-join (make-list subdir-depth "..") "/" = 'suffix)) >=20 > Maybe better name: escape-subdir or something. >=20 > So this is in order to get out of (string-append TARGET "/" SUBDIR), = correct? Yes, correct. I=E2=80=99ll rework this with the (symlink-relative) = function you mentioned. > Does the (string-append TARGET "/" SUBDIR) have an official name ? > If not, fine. No. The TARGET becomes the TFTP root for GRUB, the SUBDIR becomes the = =E2=80=98prefix=E2=80=99 variable for GRUB. >> + (net-dir (string-append mount-point target "/")) >=20 > So TARGET is relative to MOUNT-POINT ? > And MOUNT-POINT is assumed to have a slash at the end ? 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 absolute path, so it should be safe. At least (install-grub-efi) = makes the same mistake. What do you think? >> + (store-name (car (delete "" (string-split bootloader = #\/)))) >=20 > Maybe use match. I=E2=80=99ll use (first =E2=80=A6). > Also isn't there an official way to find out how the store is called ? > (%store-prefix) ? I only need the first path element to the store, which is usually /gnu. = The %store-prefix contains /gnu/store then. So it makes no difference. >> + (store (string-append up1 store-name)) >=20 > (string-append escape-target store-name) >=20 >> + (store-link (string-append net-dir store-name)) >=20 > *mumbles to self* (string-append MOUNT-POINT TARGET) is net-dir. > So it tries to get to (string-append MOUNT-POINT "/gnu"). The trouble is that GRUB shall load a file like = /gnu/store/=E2=80=A6-linux=E2=80=A6/Image via TFTP, but the TFTP root is = actually Guix=E2=80=99 final /boot folder. In the end this creates a relative symlink as ../gnu pointing from = /mnt/here/boot/gnu to /mnt/here/gnu. 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 = variable, which is set through the SUBDIR argument, which defaults to = Guix=E2=80=99 final /boot/efi/Guix. 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. 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/grub.cfg to /mnt/here/boot/grub/grub.cfg, = as the later is kind of hard-coded. >> ;;; Bootloader definitions. >> ;;; >> +;;; For all these grub-bootloader variables the path to = /boot/grub/grub.cfg >> +;;; is fixed. Inheriting and overwriting the field = 'configuration-file' will >> +;;; break 'guix system delete-generations', 'guix system = switch-generation', >> +;;; and 'guix system roll-back'. >=20 > I've added that comment to the source code in an extra commit > 3f2bd9df410e85795ec656052f44d2cddec2a060 in guix master. > Thank you very much for it. >=20 >> -(define* grub-minimal-bootloader >> +(define grub-minimal-bootloader >> (bootloader >=20 >> -(define* grub-efi-bootloader >> +(define grub-efi-bootloader >> (bootloader >=20 >> -(define* grub-mkrescue-bootloader >> +(define grub-mkrescue-bootloader >=20 > I've applied this hunk to guix master as commit > 8664c35d6d7fd6e9ce1ca8adefa8070a8e556db4. >=20 > Thanks. Thanks! Bye Stefan=