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
> /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

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 via email to