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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hello Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Stefan,
>
> On Tue, 9 Jun 2020 14:16:18 +0200
> Stefan <stefan-guix@vodafonemail.de> wrote:
>
>> I made your requested change (using <nfs-share>), but when trying a 'guix system reconfigure …' I only get this error:
>> 
>> guix system: error: #<nfs-share ":/volume5/guix-system">: invalid G-expression input
>> 
>> There is no backtrace, no nothing. I can’t figure out, which part of the code tries to read this serialisation. Do you have a clue?
>
> I think it's a problem in the transfer of the record from host side to build
> side, in this case mostly via Linux kernel command line arguments, which are
> strings.
>
> The host side code can use these records, but eventually the build side code
> has to get a string and reconstruct it.
>
> I don't know how to debug it except for running the translation in my head.
> The error reporting facility could be improved a lot :(
>
> gnu/build/linux-boot.scm is build side.  It runs when the system boots.
>
> In there it has 
>
>   (define (device-string->file-system-device device-string)
>     ;; The "--root=SPEC" kernel command-line option always provides a
>     ;; string, but the string can represent a device, a UUID, a
>     ;; label or a NFS spec.  So check for all three.
>     (cond ((string-prefix? "/" device-string) device-string)
>           ((uuid device-string) => identity)
>           (else (file-system-label device-string))))
>
> But looking at the condition (uuid device-string) I have no idea what that means,
> or is bound to!

It means that if the device-string (a string as its name imply) contains
something that represent a UUID, return its corresponding UUID object.
`uuid' comes from (gnu system uuid).  Does that answer your question?

> It was introduced by:
>
> commit 281d80d8e547fe663aaacb3226119166dd3100f9
> Author: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date:   Tue Feb 11 14:00:06 2020 -0500
>
>     linux-boot: Refactor boot-system.
>     
>     The --root option can now be omitted, and inferred from the root file system
>     declaration instead.
>     
>     * gnu/build/file-systems.scm (canonicalize-device-spec): Extend to support NFS
>     directly, and...
>     * gnu/build/linux-boot.scm (boot-system): ...remove NFS special casing from
>     here.  Remove nested definitions for root-fs-type, root-fs-flags and
>     root-fs-options, and bind those inside the let* instead.  Make "--root" take
>     precedence over the device field string representation of the root file
>     system.
>     * doc/guix.texi (Initial RAM Disk): Document that "--root" can be left
>     unspecified.
>
> If "--root" is not specified, it should then pick up the root from the root
> file system declaration. 
>
> @Maxim: How can we use your commit to boot from NFS?  I see no way to leave
> "--root" off in the first place for a regular user.  (Stefan's patch adds
> support for network boot via tftp/nfs via grub efi net) 

This commit just makes it so that if --root was ever removed from the
generated GRUB configuration, it'd still be able to find it
automatically.  It was added to be consistent with the fact that mount
options are automatically taken from the root file system without any
user option (and I initially had a rootflags user option but this was
deemed unnecessary at the time).  I'll probably add it back soon now
that I've found a valid use case for it (passing the 'degraded' mount
option for booting from a degraded Btrfs RAID is one).

Does it cause a problem for the NFS boot via 'grub efi net' (I know
nothing about it -- any link for a recommended reading?)  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?

Maxim