Reporting a new bug since the fix for bug 1197484, as suspected, did not fix the issue. I am reporting again against isc-dhcp but the issue appeared for the first time when Linux version 3.10.0-2-generic was first used. Also, using utah this is easily reproducible irrespective of the host ( confirmed on precise and raring hosts) and appears to only happen during the first boot after the installation. I say this because, I tried to reboot an impacted VM a number of times (after sudo ifdown eth0 and sudo ifup eth0) but could not reproduce the issue. Logging into an impacted system, running ifconfig does not list an ipv4 address for eth0, when the issue occurs.
Summary of the issue:
The ssh/ ping requests from the host to the client VMs of preseeded saucy server installations fail on first reboot after fresh installations of 20130703 images onwards. The ping requests to the IP address allocated to the VMs during the installations fail with 'Destination Host Unreachable'. There does not appear to be anything wrong during installations.
The VMs use libvirt/KVM and using bridged interface. This issue happens not always but most of the time. With isc-dhcp - 4.2.4-7ubuntu3 we do NOT see the 'dhclient: execve (/sbin/dhclient-script, ...): Permission denied' in the boot log but still see
Jul 17 03:59:55 utah-11601-saucy-server-i386 kernel: [ 13.514969] type=1400 audit(1374047995.545:11): apparmor="DENIED" operation="file_mmap" parent=488 profile="/sbin/dhclient" name="/bin/bash" pid=591 comm="dhclient-script" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
The installer syslog and boot log of one of the latest failures are attached.
==============================================
How to reproduce:
1. Install utah using
sudo apt-add-repository -y ppa:utah/stable
sudo apt-get update
sudo apt-get install utah
2. Now run the installation test using
sudo -u utah -i run_utah_tests.py -i /path/to/saucy-server-amd64.iso -p lp:ubuntu-test-cases/server/preseeds/mail-server.preseed lp:ubuntu-test-cases/server/runlists/mail-server.run -x /etc/utah/bridged-network-vm.xml
3. Now it could be seen that the the connection to the VMs from the host after the installation fails.
Note that this:
Jul 17 03:59:55 utah-11601-
is a different denial than in bug #1197484. Bug #1197484 denied 'r' access, this is denying 'm' access. Can you boot/test with apparmor=0 to take apparmor completely out of the equation?