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 qIhUJZEu/l5hAgAA0tVLHw (envelope-from ) for ; Thu, 02 Jul 2020 18:59:29 +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 2KgSIZEu/l5ueQAAbx9fmQ (envelope-from ) for ; Thu, 02 Jul 2020 18:59:29 +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 4413E9400C1 for ; Thu, 2 Jul 2020 18:59:29 +0000 (UTC) Received: from localhost ([::1]:55142 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jr4Qi-0006le-43 for larch@yhetil.org; Thu, 02 Jul 2020 14:59:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jr4QY-0006kh-Nv for guix-devel@gnu.org; Thu, 02 Jul 2020 14:59:18 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:38727) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jr4QW-0000qw-5H for guix-devel@gnu.org; Thu, 02 Jul 2020 14:59:18 -0400 Received: from webmail.gandi.net (webmail19.sd4.0x35.net [10.200.201.19]) (Authenticated sender: brice@waegenei.re) by relay6-d.mail.gandi.net (Postfix) with ESMTPA id 6D0A0C0005; Thu, 2 Jul 2020 18:59:11 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 02 Jul 2020 18:59:11 +0000 From: Brice Waegeneire To: Vagrant Cascadian Subject: Re: [GSOC 2020] network-boot-service In-Reply-To: <87lfk1anaw.fsf@ponder> References: <87lfk1anaw.fsf@ponder> Message-ID: X-Sender: brice@waegenei.re User-Agent: Roundcube Webmail/1.3.13 Received-SPF: pass client-ip=217.70.183.198; envelope-from=brice@waegenei.re; helo=relay6-d.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/02 14:59:12 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.01 X-TUID: 5bF5N6VlAoVr Hello Vagrant, On 2020-07-02 16:34, Vagrant Cascadian wrote: > On 2020-07-02, Brice Waegeneire wrote: >> To support the widest hardware and boot options possible I went with >> iPXE >> as a chainloader. Meaning that any machine doing a PXE boot (or with >> builtin iPXE with restricted feature set) will load the iPXE >> bootloader >> first, which will then properly load the initrd. > > iPXE is really cool! The main downside is I don't think the support for > non-x86 architectures is there, but would be happy to find out > otherwise. > It looks like it does support arm 32 and 64 bits EFI: https://ipxe.org/appnote/buildtargets. Anyway dnsmasq can be configured to provide PXE entries by on the client's architecture or feature it support. For example using network-boot-service, a iPXE client without http support will chainload Guix's iPXE which has http support. >> Currently I'm working on the initrd part to add NFS mounting >> capability >> to >> it. At this point I'm blocked by building a lightweight staticly built >> 'nfs-utils' package to be included in the initrd. It's current total >> size >> 219.2 MiB, I manage to reduced it to 162.2 MiB which is still one >> order >> of >> magnitude larger than my initrd at 19 MiB. >> >> My issue building a static 'nfs-utils' is that it can't find >> 'getrpcbynumber{,_r}' “configure: error: Neither getrpcbynumber_r nor >> getrpcbynumber are available”. This function should be provided by the >> libc >> or by libtirpc if it's not that first one. The problem is that >> 'libtirpc' >> don't build it's own 'getrpcbynumber' because it find one in libc but >> nfs-utils can't find it... > > Have you looked into using klibc (or maybe busybox) instead? They might > be smaller and have enough capability to mount NFS. Non I did not, thanks for the tip. Busybox is smaller that was I expecting, 1.0 MiB by itself, but it doesn't seems it would follow the Guix way of doing most of the work in Guile (and using boot-to-Guile™) and it's unique binary forbid us to extract only the NFS part. As for klibc, it seems to be what NixOS[1] is using and TIL that it also the the original source of Arch's mkinitcpio-nfs-utils which is unmaintained. So klibc may work here, I'll try packaging it. >> Some other distros are using the kernel parameter 'nfsroot'[2], but we >> probably don't want to use it since it can't be used together with an >> initrd and it also mean we need built-in modules for NFS and network >> card >> driver in the kernel. > > Debian at least implements support for the nfsroot kernel parameter by > emulating the behavior in the initrd, using kernel modules instead of > built-ins. Seems like Guix could do the same? Do you happen to know which package implement it in Debian? Yes, there will be a need to pass parameters to the initrd so we better use the common syntax. > If you're trying to use user-space NFS, I suspect you'll run into a lot > of issues... Debian at least dropped support for parts of the > user-space > NFS stack years ago as it had huge numbers of bugs and little activity > upstream. What do you mean by “user-space NFS”, be it nfs-utils, busybox or klibc, they all are user-space tools to used to mount NFS shares? Do you have some reference about this, I would like to learn more about it. It's true that I did not find anyone trying to build a static nfs-utils... > Great to hear about progress on this work! > > > live well, > vagrant [1]: https://github.com/NixOS/nixpkgs/commit/d25c1a8fdc383b8997f6e7b4e1479875df1f06b2 [2]: https://github.com/NixOS/nixpkgs/blob/84cf00f98031e93f389f1eb93c4a7374a33cc0a9/pkgs/os-specific/linux/mkinitcpio-nfs-utils/default.nix - Brice