Le 17/11/2017 à 12:53, Christopher Huhn a écrit : > Dear Debian Cloud Team, > > on the occasion of re-investigating vagrant I stumpled upon the > debian-vm-templates and the fai-cloud-images git repos. > Esp. the latter is exactly what I was looking for. Nice!> Anyhow I have the > following problem (on a Stretch system) with both > `make stretch-image-vagrant`in fai-cloud-images and > `make -C vmdebootstrap-libvirt-vagrant stretch` in debian-vm-templates. > (This is no surprise as debian-vm-templates/helpers/vagrant-setup and > fai-cloud-images/config_space/scripts/VAGRANT/20-setup are more or less > identical.)
Hi Christopher fai-cloud-images is rather a work in progress for Vagrant Images, you should look at debian-vm-templates for the working stuff. I could not reproduce your problem with debian-vm-templates and vmdeboostrap 1.8-1 ( dpkg -l version) > > After the initial debootstrap further package installations fail because > DNS resolution does not work inside the chroot, eg.: > >> Enabling systemctl-resolved for DNS >> Running customize script >> /data.local1/debian-vm-templates/vmdebootstrap-libvirt-vagrant/../helpers/vagrant-setup >> >> [..] >> + chroot /tmp/tmpUo5_fS apt-get update >> Err:1 http://httpredir.debian.org/debian stretch InRelease >> Temporary failure resolving 'httpredir.debian.org' >> Reading package lists... Done >> W: Failed to fetch >> http://httpredir.debian.org/debian/dists/stretch/InRelease Temporary >> failure resolving 'httpredir.debian.org' >> [..] >> + chroot /tmp/tmpUo5_fS apt-get install -qy dctrl-tools >> [..] > Err:1 http://httpredir.debian.org/debian stretch/main amd64 > dctrl-tools amd64 2.24-2+b1 >> Temporary failure resolving 'httpredir.debian.org' >> E: Failed to fetch >> http://httpredir.debian.org/debian/pool/main/d/dctrl-tools/dctrl-tools_2.24-2+b1_amd64.deb >> >> Temporary failure resolving 'httpredir.debian.org' >> [..] >> EEEK! Something bad happened... > > Is that a known problem? > > My fix would be to drop the hosts /etc/resolv.conf to > /run/systemd/resolve/resolv.conf inside the image. > > Reading the manpage of systemd-resolved it looks like this problem may > be circumvented/hidden by running systemd-resolved on the host the image > is built on. Probably the client will implicitly use 127.0.0.53 as its > DNS server? > > We are not using systemd-resolved in our setup and I cannot easily test > it at the moment. > In general it would be nice if the scripts work without relying on a > specific host setup anyhow. vmdeboostrap has the unfornate choice of using systemd-networkd as the default, when everything else is still us ifupdown, and I don't a lot about about DNS resolution is supposed to take place. But I am not sure that the problem comes from having systemd-resolved on the host. I don't have it installed and it is working here ;) Emmanuel -- You know an upstream is nice when they even accept m68k patches. - John Paul Adrian Glaubitz