[GSOC 2020] network-boot-service

[Brice Waegeneire]

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 https://git.sr.ht/~bricewge/guix.

[1]: https://ltsp.org/
[2]: 
https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt

Have a good day,
- Brice