[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSOC 2020] network-boot-service

From: Brice Waegeneire
Subject: Re: [GSOC 2020] network-boot-service
Date: Thu, 02 Jul 2020 18:59:11 +0000
User-agent: Roundcube Webmail/1.3.13

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
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

It looks like it does support arm 32 and 64 bits EFI: 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
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
219.2 MiB, I manage to reduced it to 162.2 MiB which is still one order
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
or by libtirpc if it's not that first one. The problem is that
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
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

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

Great to hear about progress on this work!

live well,

[1]: [2]:

- Brice

reply via email to

[Prev in Thread] Current Thread [Next in Thread]