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

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

Hello Stefan,

On Sun, 6 Sep 2020 13:52:28 +0200
Stefan <stefan-guix@vodafonemail.de> wrote:

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

Thanks!

> 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>") …).

Yeah.

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

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.

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

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.

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

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:

>* <server-ip> (IP address of the NFS server)
>* <root-dir> (name of the directory on the NFS server to mount as /, with %s as format string in order to substitute client IP address)
>* <nfs-options>: port (!), rsize, wsize, timeo, retrans, acregmin, acregmax, acregmin, acregmax, flags (hard, nointr, noposix, cto, ac).

>ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:
>   <dns0-ip>:<dns1-ip>:<ntp0-ip>
>
>  This parameter tells the kernel how to configure IP addresses of devices
>  and also how to set up the IP routing table. It was originally called
>  `nfsaddrs', but now the boot-time IP configuration works independently of
>  NFS, so it was renamed to `ip' and the old name remained as an alias for
>  compatibility reasons.
).

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.

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

Yeah, I agree.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]