It appears to be largely undocumented, but a review of
/usr/share/initramfs/scripts/nfs shows that this package supports NFSv2
and v3 only.  I don't know why v4 isn't supported.

maximilian attems wrote:

NFSv4 and NFS over IPv6 would both be Very Good Things to have in klibc,
partially because it might actually satisfy Linus' requirement of "must
add new features above what the kernel already has."

I'm not an NFS expert, but I'd be willing to work with someone who is as
necessary to deal with the NFSv4 mount protocol.  I understand NFSv4
gets rid of mountd, so it should be simpler?

	-hpa

[ adding klibc ml to cc ]

yup,
this needs nfs v4 support in klibc nfsmount.
would be could to get that soon postetch,
but someone will have to implement it ;-)

Actually I have the same problem, a fix would be highly appreciated.
Currently I try to do a workaround, by including the normal dynamicly
linked mount in initramfs. but currently I get the error: Can't find
address for <my-host-name>. The increase in size is marginal.
Maybe /etc/hosts is missing or something, or I need a running DNS for my
network. If someone has an idea....

Johannes Frank

I've played around a bit with this and although I don't have anything that
works yet, here's some ideas on how it could be implemented:

I assume that DHCP and ip config is already taken care of (as the nfs
support has that code already). I also assume that most people will be
using NFSv4 with Kerberos authentication (it seems to be the most common
setup).

The following files would need to be added to the initramfs:
/usr/sbin/rpc.gssd
/usr/sbin/rpc.idmapd
Config files for kerberos and the two rpc daemons
Kernel modules (nfs and rpcsec_gss_krb5)
nfs4 capable mount program

Since it would probably be a bad thing to store the kerberos keytab inside
the initramfs image, my idea was to use kadmin to get the nfs principal
(usually nfs/host.domain@REALM) from the kdc, so /usr/sbin/kadmin would be
added as well.

A initramfs config file can hold the principal to use for nfs and the realm.

Then the setup would be:

1. Setup networking
2. Use kadmin to get nfs/host.domain@REALM and store to /etc/krb5.keytab:
   kadmin -r REALM -p userprincipal -q "ktadd -k /etc/krb5.keytab
                                        nfs/host.domain@REALM"
   (note: userprincipal defaults to root/admin)
3. Mount rpc_pipefs on /var/lib/nfs/rpc_pipefs
4. Load kernel modules
5. Start rpc.gssd and rpc.idmapd
6. Mount NFS root

When initramfs is done, it will nuke the contents of the initramfs
(including the keytab) from memory. The keytab to use thereafter is
expected to be found in /etc/krb5.keytab after pivot_root as usual.

The main problems seem to be:

o How and when should the rpc daemons be restarted so that the ones from
the nfs-root-fs are used instead of the ones from initramfs? This is
especially important if some of the hacks below are used...

o All these programs make for a quite fat initramfs and little use of
klibc (libc6 and a bunch of other libraries will be pulled in). A hacked
version of idmapd could possibly be written (the real one is about 1k
lines of code) which always maps everything to root (since we are running
in the initramfs context anyway), but I'm not so sure about the other
tools. Changes to the klibc nfsmount also seem doable, but that leaves
rpc.gssd and the kerberos tools. rpc.gssd might be simplified by the fact
that for the root user it uses the machine credentials, but there is still
a lot of code...

Hello,

I've just read through bts #409271 :"initramfs-tools: NFSv4 not
supported for root fs"
and I'm interrested in knowing the status of this bug for lenny.

Thanks,

@+,
	Fab

PS : ccing nfs-aware people.

AFAIK my understanding is: klibc's mount doesn't support NFSv4, initramfs
insists on using klibc's mount, stalemate.

/* Steinar */

* Steinar H. Gunderson <sgunderson@bigfoot.com> [Son Aug 10, 2008 at 05:03:28 +0200]:

maks, we should discuss this issue in further details,
we be great if we could resolve this in time for squeeze.

regards,
-mika-

in a week i'm a back, but this is over ambitious.

* maximilian attems <max@stro.at> [Wed Jun 09, 2010 at 04:25:09AM +0200]:

Fair enoug,. though if we have a conclusion regarding
klibc<->libc<->busybox... solving this problem might not be that
much work. But yeah, let's discuss that when you're back.

thanks && regards,
-mika-

hi,

we have the same problem. We need the security features form NFSv4 for
our diskless clients. I build the initramfs under Squeeze but it seems,
that it isn't working, if I tell Solaris to support only NFSv4.

So, how can I get the NFSv4 working ?

cu denny

[Adding Jan-Marek to Cc]

* Denny Schierz [Fri Mar 11, 2011 at 11:29:51AM +0100]:

I'd like to see this issue resolved.

Jan-Marek, IIRC the company you're working for has some patches
addressing this issue. Is there any chance that you could share them
with us so we could provide official support for NFSv4 within
initramfs-tools?

regards,
-mika-

Just for the record.

The dracut package has NFS v4 support. Maybe it's easier to use dracut
instead of waiting for klibc supporting it.

Hi.

ltsp-client-core depends on initramfs (and has hooks into it). dracut
conflicts with initramfs. So dracut is not the solution.

I'd be happy with NFSv4 without any of the security stuff as I only use
it for the LTSP root fs, which is readonly and non-secret anyway. IPv6
would be nice though.

Any chances?

Best regards,
Wilfried

What is the status of this bug report?  NFSv3 is becoming obsolete, and
this bug report is over *9 years* old now!

For now, since klibc does not have NFSV4 support, the attached file works
around the problem (place in /usr/share/initramfs-tools/hooks/nfsv4).

Though it doesn't work with read-only NFSv4.1 and OverlayFS with TmpFS on
Stretch, both kernels 4.9 and 4.19.
Any ideas?
In the hook I added your workaround and:
manual_add_modules overlay

Then on /etc/initramfs-tools/scripts/init-bottom/local:
mkdir -m 700 /ovl
mkdir /ovl/lower /ovl/ram /ovl/merged
mount -n -o move $rootmnt /ovl/lower
mount -n -t tmpfs -o 'mode=755,size=75%' tmpfs /ovl/ram
mkdir /ovl/ram/upper /ovl/ram/work
mount -n -t overlay -o
"lowerdir=/ovl/lower,upperdir=/ovl/ram/upper,workdir=/ovl/ram/work,_netdev"
overlay /ovl/merged
mount -n -o move /ovl/merged $rootmnt
mkdir -m 700 $rootmnt/ovl
mkdir $rootmnt/ovl/lower $rootmnt/ovl/ram
mount -n -o move /ovl/lower $rootmnt/ovl/lower
mount -n -o move /ovl/ram $rootmnt/ovl/ram

This works with NFSv3.
Also, if I test it on an already booted system with mounting NFSv4.1
manually and doing the overlay it works.
So, something in the initramfs is different to the booted up system that
causes the problem, but couldn't find it.
If anyone has any idea of things to try I can report back the results and
try to provide a fully working solution afterwards.
Thanks!

There's still no progess in adding NFSv4 to klibc nfsmount for
initramfs-tools.

Here's the info how to use overlayfs and NFSv4 for a read-only
nfsroot but with dracut instead of initramfs-tools:

http://blog.fai-project.org/posts/overlayfs/
http://fai-project.org/fai-guide/#_a_id_nfsv4_a_how_to_use_nfs_v4_with_the_nfsroot

There's still no progess in adding NFSv4 to klibc nfsmount for
initramfs-tools.

Here's the info how to use overlayfs and NFSv4 for a read-only
nfsroot but with dracut instead of initramfs-tools:

http://blog.fai-project.org/posts/overlayfs/
http://fai-project.org/fai-guide/#_a_id_nfsv4_a_how_to_use_nfs_v4_with_the_nfsroot