NFSv4 boot worked in 20.04, doesn't in 22.04

By dint of a nasty hack I was able to boot Ubuntu 20.04 LTS with an NFSv4 root on a Raspberry Pi 4B. When I tried the same with Ubuntu 22.04 LTS it failed.

The Raspberry passes kernel parameters to Ubuntu in its cmdline.txt file. Mine looks like this:

console=serial0,115200
console=tty1
root=/dev/nfs
nfsrootdebug
rootfstype=nfs4
nfsroot=192.168.8.20:/RPi4/Ubuntu/root,vers=4,tcp
rw
ip=dhcp
rootwait

(I have replaced space separators with newlines for legibility.)

The string vers=4 causes an error during parsing of cmdline.txt because klibc-utils only implements NFSv2 and NFSv3. The nasty hack I referred to above involved replacing the executable /usr/lib/klibc/bin/nfsmount with something that didn't check the vers= string and proceeded to mount something appropriate using NFSv4.

In 22.04 this no longer works. It appears that 22.04 no longer calls nfsmount at all. I deleted nfsmount from libc-utilscompletely, did an update-initramfs -u and got exactly the same error as with it. So the error I am seeing is not coming from nfsmount, whereas in 20.04 it did.

Examination of the source code of klibc-utils leads me to believe that the nfsmount functionality has been refactored into a file called .../klibc/usr/kinit/nfsmount/mount.c which is now (also) called from /usr/lib/klibc/bin/kinit.

Could someone confirm this for me? Or anybody with a deeper knowledge of this area of Ubuntu point me in a more productive direction?

The origin of the problem is a bug in Debian that has been known since 2007. I am not an expert in Linux kernels, initramfs or the like: in fact I'm only here because I foolishly thought that network booting my Raspberry Pi devices in my home network would be nice and simple, and ended up drilling down. But it would appear that I am going to have to try and fix this ancient bug since no-one else seems to want to.

To help me on my way: could someone point me at how to recompile the klibc-utils sources in Ubuntu 22.04?

And any other advice, thoughts and clarifications are always welcome, of course.

This is a false alarm. I boot the my Pis from my NAS, which stores the RPi Ubuntu partitions in two separate directories (boot and root), which are later mounted as two separate shares at /boot/firmware and / respectively.

The initramfs phase of the Ubuntu boot occurs from the initrd.img file stored in the boot directory.

Now, for reasons I do not fully understand, Ubuntu is the proud owner of two initrd.img files, one in /boot and one in /boot/firmware. As far as I can tell, they are identical, and they both get updated if you perform update-initramfs -u, which you have to do after you have replaced your nfsmount image.

I can't run update-initramfs -u on the NAS, so I do it on an SD-booted RPi and sync the resultant files back to the NAS. Well, I do now. I was only sync'ing the root share, and each time I rebooted it was with the unchanged /boot/firmware/initrd.img, which continued to contain the original NFSv4-unfriendly nfsmount.

Sorry.