Bug#837992: nfs problem might be related to rpcbind installation in chroot
On 2016-09-19 14:46:55, Marcin Kulisz wrote: > On 2016-09-16 11:59:01, Emmanuel Kasper wrote: > > @marcin: since you're a bootstrap-vz expert here, > > haha that's a bold statement, I'd say Tiago and Anders are :-) > > > 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) > > No idea sorry I had a quick look into init implementation and looks like it should start, but ... Bootstrap-vz upstream version (from Anders github) is not working very well with systemd (yet). I just uploaded 0.9.10+20160920git to the archive, but for now it's in new (due to introducing new doc binary) and in it we have patches for Stretch which should cope nicely with systemd. It also will enable all installed services by default, unless specified otherwise. I was testing it with EC2 provider but this part is shared so should work with other providers as well. I didn't made Stretch support public yet nor created PR for it in github as I'm still testing it a bit (even if all seams to be working). -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
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)
