Re: [Libguestfs] Name resolution not working inside virt-customize

On Tue, Mar 10, 2015 at 04:41:22PM -0400, Lee Revell wrote: > Hi! > > I am trying to use virt-customize to add packages to an image. > However it seems that there is a problem where a resolv.conf is not > being installed and thus package installation fails. > > The command is: > > virt-customize -v -x -a trusty-server-cloudimg-amd64-disk1.img > --run-command "host openstack.org" > > I am having a hard time gathering complete output as the command > seems to corrupt my terminal somehow but I think the relevant lines > may be: > > [ 3.0] Running: host openstack.org > running command: > exec >>'/tmp/builder.log' 2>&1 > > > host openstack.org > > libguestfs: trace: sh "exec >>'/tmp/builder.log' 2>&1\n\n\nhost > openstack.org\n" > guestfsd: main_loop: new request, len 0x60 > mount --bind /dev /sysroot/dev > mount --bind /dev/pts /sysroot/dev/pts > mount: mount point /sysroot/dev/pts does not exist > mount --bind /proc /sysroot/proc > mount --bind /sys/fs/selinux /sysroot/selinux > mount: mount point /sysroot/selinux does not exist > mount --bind /sys /sysroot/sys > mount --bind /sys/fs/selinux /sysroot/sys/fs/selinux > mount: mount point /sysroot/sys/fs/selinux does not exist > renaming /sysroot/etc/resolv.conf to /sysroot/etc/g1fbx1fs > cp /etc/resolv.conf /sysroot/etc/resolv.conf > cp: cannot stat '/etc/resolv.conf': No such file or directory > /bin/sh -c exec >>'/tmp/builder.log' 2>&1 > > > host openstack.org > > And the command fails due to the missing resolv.conf. > > I am using version 1.28.6 build from source on ubuntu 14.04. The > same image file listed above works perfectly when launched as an > openstack instance. I'm afraid our handling of /etc/resolv.conf inside the chroot is a large (and continuing) source of problems. Currently this code is run: https://github.com/libguestfs/libguestfs/blob/master/daemon/command.c#L148 There are a couple of thing you could do: - Don't rely too heavily on name resolution. - Use --firstboot* scripts instead, since they genuinely run in guest context, and should therefore work more like you expect. (and I guess a third one .. suggest a better approach to resolv.conf handling).