Since fai dirinstall does not need the nfsroot any more, it's now
possible to create the nfsroot with a fai dirinstall call using a
class NFSROOT inside the config space. The new class NFSROOT must be
created, since it does not exists yet.

My idea is to define a new action "nfsroot".

So, fai nfsroot would create the nfsroot. But since make-fai-nfsroot
has a lot of options, fai nfsroot should only do the base
setup and a new m-f-n script will call fai nfsroot. The option -r
should be removed, other options should remain.

One question is where the configs (like NFSROOT) and maybe hooks (for
building the nfsroot) should be stored. I'm not happy with /etc/fai,
but the list of packages (NFSROOT) for the nfsroot belongs in this
directory.

I fail to understand the concept behind this approach. What would we gain? An
action "nfsroot" that must not be used by anything else than m-f-n? So it
shouldn't be mentioned in the man pages but is still there?

The idea of using dirinstall was reusing code, as far as I understood. Maybe
this is impossible, then of course your proposed approach becomes more
interesting. Could you please elaborate, why you think this new idea is better
than the original one? I'm likely missing some very important aspect.

I think they could be moved to the config space, but I'm not entirely sure
whether this is really the best way to do it. A class NFSROOT with
hooks/bla.NFSROOT and package_config/NFSROOT as part of the simple example could
do the trick.

Best,
Michael

fai-make-nfsroot cannot be replaced by fai dirinstall, because
it supports options, which can't easily mapped to FAI classes.
And it's not possible to pass options to fai dirinstall.

But fai-make-nfsroot can use "fai dirinstall" internally.