[PATCH] gnu: Handle nfs-root device strings.

set the root to tftp.

strings.

device strings.

of nfs file systems as in guix/scripts/system.scm.

device strings.

---

gnu/bootloader/grub.scm | 3 +++

gnu/build/file-systems.scm | 3 ++-

gnu/build/linux-boot.scm | 5 +++--

gnu/machine/ssh.scm | 2 ++

gnu/system.scm | 12 +++++++-----

5 files changed, 17 insertions(+), 8 deletions(-)

Hi!

I’d like to propose these minimal changes to support an NFS as a root file system.

Currently there are three ways to define the root file system:

• (file-system (device (label …)) …),

• (file-system (device (union …)) …),

• (file-system (device "<string>") …).

The manual does not mention that an NFS is currently not supported as a root file system. However, NFS mounts are possible already with (file-system (type "nfs") (device "<string>") …).

This patch enables users to use an NFS also as a root file system without introducing a new syntax.

I was asked before to introduce an <nfs-share> record to achieve the same. And I did so, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41820#20. But due to some other PXE efforts – for which I don’t see progress – that patch got on hold.

However, that <nfs-share> record would brake with the compatibility of how an NFS mount is defined today, and it makes the code much more complex without having a real gain.

I think this minimal patch will not conflict with that other PXE effort. Its only purpose is to enable the use of an NFS as a root file system already today.

Bye

Stefan

Hello Stefan,

On Sun, 6 Sep 2020 13:52:28 +0200

Stefan <stefan-guix@vodafonemail.de> wrote:

Thanks!

Yeah.

That sounds like a good idea.

For the time being, let's just use the string thing for your

functionality--nevermind the <nfs-share> thing for now.

First, I like to apologize for the huge delay in handling this stuff. My

original intent was to let Brice Waegeneire <brice@waegenei.re>, my GSoC intern

for network booting, handle your request--both because he needs it anyway and

because he presumably has more knowledge on network booting. He's missing in

action (no communication at all) and I gave up having Brice do it.

In any case, his GSoC is over.

I will now look at your request on my own. I obtained some Raspberry Pis, a

NAS with TFTP server support out of the box and I made sure I could manipulate

the DHCP server I use on my network, so the next step is to try to actually

use your patchset myself--which I didn't do before (sorry).

I want to note that patches with system tests are processed *much* faster--I

don't think many reviewers would go to those lengths I did (obtaining special

hardware) in order to test contributions--so usually, it would have been

basically stuck forever without system tests.

Thanks for persevering on this feature.

The real gain would be this:

There are a lot of options that one could need (see

https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt. They have:

).

I'm just saying that it will become a record over time anyway. But maybe

it will be something more general for PXE--hard to tell which is better at

this point in time. So nevermind for now.

Yeah, I agree.

However, I cannot see a patch as attachment to your E-Mail.

Hi Stefan,

On Sat, 5 Sep 2020 13:26:25 +0200

Stefan <stefan-guix@vodafonemail.de> wrote:

Why does having a NFS root "device" imply using TFTP?

I can see that it would be nice--but I've been using NFS for many years without

using TFTP.

What is that required for in practice?

Pushed all the other hunks except for the one above--for now.

Guix master commit 1c3b709edb8e6248a9a84dde57b27f3fdc997f21.

Hi Danny!

I'm glad to hear this. :-)

Nevermind.

That’s a pity.

Oh, I would never have expected that. I tried to do a system test, but for aarch64 substitutes where missing (I think basically qemu) and building locally on my small system took days and failed in the end, so I gave up. But please take a look here, it may help: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41820#17

Sure, its in my own interest. :-)

I know about them and used them before. I agree, a bigger record makes sense. But please consider that these options actually disable the use of an initrd, which brings more complications, as guix currently relies on having an initrd.

Oh, that was just my initial e-mail generating this ticket yesterday: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43219#5

Bye

Stefan

Hi Danny!

True.

If you use an NFS share as the root file system, it’s just very likely that you use a diskless setup.

It is uncommon, that you have some storage device, from which you load the kernel and the initrd, but which is not also your root file system device. Usually the kernel and the initrd are located in the root file system.

But take a closer look at (grub-root-search device file): This function gets a device record or device string, which is expected to contain the file to look for.

If that device string is an NFS share, then GRUB has only two possibilities to access that file: either via TFTP or HTTP. Actually there is no way yet to divide between these two possibilities.

GRUB does not support NFS, and the chance that the searched file on the NFS share is accessible on a local storage as well is very low.

I chose TFTP over HTTP because of this reasons:

• PXE specifies TFTP but seems not to specify HTTP.

• The ‘file’ field inside the DHCP header implies TFTP.

• For BOOTP/DHCPv4 the RFC 2132 defines a TFTP server for option 66.

• U-Boot supports TFTP but not HTTP (important for chain-loading).

• The Raspberry Pi only supports TFTP.

Only with DHCPv6 there is RFC 5970, which specifies option 59 to contain a boot-file-url, which may start with ‘http://’ but also allows ‘tftp://’.

As stated above, (grub-root-search device file) is used to find the device from which to load the file. It normally generates a GRUB search command to specify inside the root variable where to find that file. That the root variable gets set is not obvious from the generated search command. But take a look here, it is the default: https://www.gnu.org/software/grub/manual/grub/grub.html#search.

However, searching for files is not possible via TFTP, so with “set root=(tftp)” we specify not to search for the file, but to assume that it is accessible via TFTP. Beside a “set root=(http)” this is the only way to specify the root, if the device is an NFS share.

However, the grub.cfg is loaded via TFTP as well, so root must be preset to ‘(tftp)’ or even ‘(http)’ due to DHCP options. So omitting the search command could be enough and even allow the use of HTTP.

It could also be possible to keep the ‘search —file’ command, if it does not produce an error.

I’ll check that.

Thanks.

Bye

Stefan

Pushed "nfs-root-fs" system test--with minimal changes--to guix master as

commit a1a39ed5a46044161a71cbe6931c7e3006a82ecb.

Hi Danny!

I think we should use that change.

+ ((? (lambda (device)

+ (and (string? device) (string-contains device ":/"))) nfs-uri)

+ "set root=(tftp)")

The point is the following: It is possible that GRUB got loaded from a local storage and that the current system is also on a local storage. Then the root variable is set to some ‘(hd0,1)’ or similar.

If you then select to boot an older system generation or a custom menu entry, which is using TFTP and NFS, then the root variable has to be changed to ‘(tftp)’.

Bye

Stefan

Hi Danny!

One more remark to this.

If you used an NFS root file system without using TFTP during boot, then certainly your bootloader, the initrd and the kernel where stored locally and have been loaded from disk, not over the network.

In Guix the initrd and the kernel are loaded from the store. If the store is located on a local device, then (grub-root-search) will still load them from that local device, even if the root file system is on an NFS share.

But in Guix its likely that the store is on the same device as the root file system. And if the root file system containing the store is mounted via NFS, then GRUB needs to access the initrd and kernel via network.

Bye

Stefan

Hi!

Danny, Stefan: what’s the status of this patch?

https://issues.guix.gnu.org/43219

Thanks,

Ludo’.

Stefan <stefan-guix@vodafonemail.de> skribis:

Hi Ludo!

It got committed in two chunks:

1c3b709edb8e6248a9a84dde57b27f3fdc997f21

8c4f1aa85f3844fc8c989e74cef9d269dd30889c

Closing. Thanks for the reminder.

Bye

Stefan