[Top][All Lists]

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

[GSOC 2020] network-boot-service

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

Hello Danny, Gábor,

Sorry for the very late update on the status of this GSOC about network
booting. At the moment I have working network boot service which I'm using
to boot various baremetal machines, I'm currently working on adding NFS
support to the initrd.

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.

For the DHCP/TFTP servers I choose dnsmasq instead of isc-dhcp-server with
a separate TFTP server mainly because it support ProxyDHCP mode which is
required for one of the most used case.

Those technical choice where instructed from the LTSP[1] project and some
Guixers advice, Vagrant and Giovani to name a few.

Speaking of uses cases for the network boot service, I see three of them. Configuration wise, the most straight-forward is as an authoritative DHCP
server where all of the interfaces of the server provide the only DHCP
server. I'm guessing it won't be used a lot yet since it imply that the
machine running Guix is a router which quite rare ATM since our networking configuration are limited ATM. Probably the most popular use case will be as a ProxyDHCP, in a network where there is already a non-PXE authoritative
DHCP server, the authoritative server provides IP addresses where our
dnsmasq server only send PXE entries and provides images through TFTP. The
last one is as a interface specific DHCP server, where dnsmasq attach to
one interface to avoid messing around on an already configured network, a NAT can be put in place to allow client to access Internet. That's the one
I'm currently using to develop and test the network boot features.

The new network-boot-service allows all of those use cases for clients
doing PXE boot or UEFI HTTP Boot, arbitrary images to boot from can be
specified or extended from an other service.

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

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.

I tried to workaround NFS mounting by copying the image from HTTPS using
(web client) but it's not really elegant since the image has to be loaded
in RAM and even simple Guix images can be relatively large.

After that the intrd work is done I will need to add support for PXE to
qemu so that network boot functionality and the network-boot-service can be
tested in Guix; I'll try doing so with OVMF.

You can find the part of my work which is committed in the
'wip-network-boot' at


Have a good day,
- Brice

reply via email to

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