nfsroot with kernel 3.X vs 4.X and kernel tftp options

[Rémy Dernat]

Hi,

I have a weird behaviour concerning my nfsroot configuration.

If I use a kernel 3.X (3.16.0-6-amd64) created with another fai server, my
clients boot fine, but if I try to create a kernel 4.9.0-8, my clients are
always stuck in a "read only file system" error ( The exact error message
is the same than this one:
https://lists.uni-koeln.de/pipermail/linux-fai/2008-January/005648.html ),
although my nfs configuration and the disks are the same.
I had also another boot behaviour on some other clients: it is just loading
vmlinuz + initrd and then, nothing, just a black screen with no warn/error
message.
Though, the creation of the nfsroot seems to be Ok (no error or warning
in /var/log/fai/fai-make-nfsroot.log).


I double checked my /etc/fai directory and particularly nfsroot.conf and my
NFSROOT file, but these files are the same on both fai servers.

I am thinking about a nfsroot option in my pxelinux/tftp file, and my nfs
version. However, both servers are listening for nfs version 3 and 4.
I found this thread, talking about nfsroot and the nfs versions on
bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=922031

My tftp files look like this:

# generated by fai-chboot for host 10.1.253.21 with IP 10.1.253.21
default fai-generated

label fai-generated
kernel vmlinuz-3.16.0-6-amd64
append initrd=initrd.img-3.16.0-6-amd64 rw aufs ip=dhcp root=/dev/nfs
nfsroot=10.1.254.41:/srv/fai/nfsroot:vers=3 rd.shell
FAI_FLAGS=verbose,sshd,createvt,reboot FAI_ACTION=install
server=faiserver.local FAI_CONFIG_SRC=nfs://faiserver.local/srv/fai/config
rd.md=0 rd.dm=0 rd.lvm=0 rd.luks=0


And, yes, I am using root=/dev/nfs and vers=3.
WHen, I am using sed to switch to kernel 4.9.0-8 and the corresponding
nfsroot, it does not work anymore as described above.

Could it be caused by this configuration ?

Kind regards,
Rémy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20181009/2a04ea10/attachment.html>