From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id SL3lMkGU4148HgAA0tVLHw (envelope-from ) for ; Fri, 12 Jun 2020 14:42: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 mp2 with LMTPS id +P2oLkGU416SIAAAB5/wlQ (envelope-from ) for ; Fri, 12 Jun 2020 14:42: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 371D49400B7 for ; Fri, 12 Jun 2020 14:42:09 +0000 (UTC) Received: from localhost ([::1]:51614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjksh-00069S-L2 for larch@yhetil.org; Fri, 12 Jun 2020 10:42:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46232) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jjksc-00069L-F4 for guix-patches@gnu.org; Fri, 12 Jun 2020 10:42:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:57094) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jjksc-0008CD-5t for guix-patches@gnu.org; Fri, 12 Jun 2020 10:42:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jjksc-0005Bc-2S for guix-patches@gnu.org; Fri, 12 Jun 2020 10:42: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: Fri, 12 Jun 2020 14:42: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, Maxim Cournoyer Received: via spool by 41011-submit@debbugs.gnu.org id=B41011.159197288619888 (code B ref 41011); Fri, 12 Jun 2020 14:42:02 +0000 Received: (at 41011) by debbugs.gnu.org; 12 Jun 2020 14:41:26 +0000 Received: from localhost ([127.0.0.1]:40407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjks2-0005Ai-Df for submit@debbugs.gnu.org; Fri, 12 Jun 2020 10:41:26 -0400 Received: from vsmx009.vodafonemail.xion.oxcs.net ([153.92.174.87]:42994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjkrz-0005AS-EI for 41011@debbugs.gnu.org; Fri, 12 Jun 2020 10:41:24 -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 D2397159E3BD; Fri, 12 Jun 2020 14:41:16 +0000 (UTC) Received: from macbook-pro.kuh-wiese.my-router.de (unknown [145.254.41.74]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTPA id 35102159D105; Fri, 12 Jun 2020 14:41:08 +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: <20200611151937.204ad14d@scratchpost.org> Date: Fri, 12 Jun 2020 16:41:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B2DD68D-AD33-4D82-B375-78097A326E13@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> <92DB8E2B-1CA2-41AE-9265-53C4F5337686@vodafonemail.de> <20200606193721.1e126131@scratchpost.org> <46CD97B3-9994-4AB7-AA7D-4DE39AB7A238@vodafonemail.de> <20200609154400.4c7d2f90@scratchpost.org> <87bllqi66g.fsf@gmail.com> <20200611151937.204ad14d@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: s391SqWt3TVm Hi Danny! > (canonicalize-device-spec seems to expect a nfs share reference to be = a > string, too. Is that on purpose? No record? That's = kinda > weird when we even have records for device labels and uuids--but we = don't > have them for something that's actually complicated to specify? [1] :) = ) I think you are already able today to specify a (file-system (type = "nfs") (device "my-server:/srv/nfs/music") =E2=80=A6). It is just not = sufficient yet for an NFS root file system. And using this style is = still possible. Therefore I started to use a simple string for an NFS share, too. That = canonicalize-device-spec expects a string is due to an older patch from = me in (boot-system), which Maxim moved from there. Actually I see a difference between an NFS share and a file system label = and an UUID, and this is (file-system (type =E2=80=A6) =E2=80=A6). If = you specify for example "ext4" or "btrfs" the =E2=80=98device=E2=80=99 = field can still have multiple representations, whereas for the type = "nfs" the device field can only have one representation. >> When booting >> from NFS using the nfsroot Linux option, it's possible to specify a >> '/dev/nfs' as the root kernel parameter. /dev/nfs is not a real = block >> device, it's just a stub hinting the kernel that its root file system = is >> on NFS. Perhaps that can be used? >=20 > Hmm maybe. @Stefan? As explained in another e-mail, no, that=E2=80=99s not an option. > Also, could we have a system test testing this stuff? I can write the > actual test--but could you tell me how to use the functionality = introduced > in this patch? A system test would be great! You need a TFTP server serving the content of some /boot=E2=80=A6 folder = as its root, which gets filled by the new grub-efi-net bootloader. This = folder name is specified by (bootloader-configuration (target =E2=80=A6) = =E2=80=A6). So lets assume you will use /boot-tftp for this. The bootloader installer will create a link /boot-tftp/gnu pointing to = ../gnu, and a link /boot-tftp/efi/boot/grub.cfg pointing to = ../../../boot/grub/grub.cfg. So the TFTP server needs to have access to = the store and the grub.cfg through these links as well. You need a DHCP server pointing the guix machine to the TFTP server and = to the file to boot. I use dnsmasq for this. My relevant configuration = lines are the =E2=80=9CTFTP server name=E2=80=9D option number 66 and = the =E2=80=9CBootfile name=E2=80=9D option 67: dhcp-option-force=3D66,10.10.10.10 dhcp-option-force=3D67,efi/boot/bootaa64.efi The dnsmasq program can be configured with=20 enable-tftp tftp-root=3D/srv/tftp/ to act as a TFTP server, too. This is probably preferable. You need an NFS server serving the root file system. And you need a guix machine, capable to boot via network. Possibly any = UEFI system could work, I think using qemu is possible as well. I=E2=80=99m using a Raspberry Pi 3b. It is not PXE compliant, but = capable to boot via network. For example it can only handle an IP = address but no hostname inside the =E2=80=9CTFTP server name=E2=80=9D = option. After specific firmware blobs have been loaded, it is loading = the U-Boot, which then acts as an UEFI implementation and uses PXE. = However, I do not use special PXE functionality, but finally the U-Boot = will try to load /efi/boot/bootaa64.efi via TFTP, which in fact is GRUB. GRUB then loads more files via TFTP from /efi/boot, most interestingly = /efi/boot/grub.cfg, which is a link to ../../../boot/grub/grub.cfg. And = that file points GRUB to the store. Up to here no NFS is involved at all. GRUB will load the initrd and = start Linux. Then the guix system is running and will mount its root = file system via NFS. If it is possible to start qemu with just an initrd, a kernel, and = kernel arguments, then it would be possible to avoid DHCP, TFTP, and = GRUB. This might be a much simpler first step for a test, only requiring = an NFS server. Bye Stefan=