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

Reply via email to