Bug#837992: nfs problem might be related to rpcbind installation in chroot
Le 16/09/2016 à 10:17, Emmanuel Kasper a écrit :
> Package: cloud.debian.org
> Severity: normal
>
> The libvirt box has problem with the default shared mode (NFS)
>
> A fresh vagrant up from the atlas box brings:
>
> mount -o vers=3,udp
> 192.168.121.1:/home/manu/Projects/vagrenvs/jatlavirtdef /vagrant
> if command -v /sbin/init && /sbin/init --version | grep upstart; then
> /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/vagrant
> fi
> mount.nfs: rpc.statd is not running but is required for remote locking.
> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
> mount.nfs: an incorrect mount option was specified
>
> this seens to relate to this bug in Jessie: #775542
> NFS exports fail due to rpcbind not starting before nfs-common and
> nfs-kernel-server
further debugging showed me that the problem is not related to #775542
but to rpcbind itself
vagrant base boxes include all packages with standard|important
https://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/tree/helpers/vagrant-setup#n35
this pulls rpcbind which is needed for NFSv3 mounts
now this package installation happens within a chroot with
automatic service startup disabled with
printf '#!/bin/sh\nexit 101\n' > $fs/usr/sbin/policy-rc.d
I don't know how much this plays a role, but the rpcbind service
afterwards _never_ starts on boot in the resulting image
even if you try to reenable it manually via
systemctl enable rpcbind in the created image
I am now wondering if the problem comes from our script or inoperant
startup sequence from rpcbind
@marcin: since you're a bootstrap-vz expert here, do you know if a
debian image created with boostrap-vz exhibits the same behaviour ?
ie when adding rpc package in a boostrap-vz manifest, is the service
started on boot (systemctl status rpcbind)
Reply to: