[bug#41011] [PATCH] gnu: grub: Support for network boot via tftp/nfs.

[Stefan <stefan-guix@vodafonemail.de>]

Hi Danny!

> (canonicalize-device-spec seems to expect a nfs share reference to be a
> string, too.  Is that on purpose?  No <nfs-share> 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") …). 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 …) …). If you specify for example "ext4" or "btrfs" the ‘device’ 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?
> 
> Hmm maybe.  @Stefan?

As explained in another e-mail, no, that’s 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… folder as its root, which gets filled by the new grub-efi-net bootloader. This folder name is specified by (bootloader-configuration (target …) …). 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 “TFTP server name” option number 66 and the “Bootfile name” option 67:

dhcp-option-force=66,10.10.10.10
dhcp-option-force=67,efi/boot/bootaa64.efi

The dnsmasq program can be configured with 

enable-tftp
tftp-root=/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’m 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 “TFTP server name” 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