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)