Bug 1224795 - On Ubuntu, virt-builder --install and --update cannot use the network
Summary: On Ubuntu, virt-builder --install and --update cannot use the network
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
: 1419315 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-25 18:55 UTC by Richard W.M. Jones
Modified: 2017-02-06 08:47 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-08-04 13:16:18 UTC
Embargoed:


Attachments (Terms of Use)
virt-builder -v -x output (244.92 KB, text/plain)
2015-05-25 18:55 UTC, Richard W.M. Jones
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1632405 0 None None None 2017-02-06 08:46:54 UTC

Description Richard W.M. Jones 2015-05-25 18:55:32 UTC
Created attachment 1029597 [details]
virt-builder -v -x output

Description of problem:

(Reported by darius93 on IRC)

virt-builder --install and --update options don't work.  The network
is not initialized correctly.

Version-Release number of selected component (if applicable):

Host: Ubuntu 14.04
libguestfs 1.28.10 (self-compiled)

How reproducible:

100%

Steps to Reproduce:
1. virt-builder ubuntu-14.04 -v -x --cache /var/lib/libvirt/templates 
                  --format raw --size 8G -o /var/lib/libvirt/images/test-1x.img --hostname ubuntu --update --install 
                  "openjdk-7-jre"

Actual results:

See the attached virt-builder log.

Comment 1 Richard W.M. Jones 2015-05-26 15:51:13 UTC
Good news is that I'm able to reproduce this.  I compiled
supermin 5 & libguestfs 1.28 on an Ubuntu 14.04 virtual machine,
and then used virt-builder similar to the description in the
bug, and the network is not available.

Using:

  virt-rescue --scratch --network

shows why it happens.  The init script (appliance/init in libguestfs
source, /init in the rescue shell) tries to run dhclient in order to
configure the network.  dhclient exits after doing nothing:

><rescue> ip a show eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
><rescue> dhclient
><rescue> ip a show eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
><rescue> ps ax | grep dhc
  146 ttyS0    S+     0:00 grep dhc

Note that the interface eth0 is down & unconfigured both before and
after running dhclient.  Using debugging mode:

><rescue> dhclient -d
Internet Systems Consortium DHCP Client 4.2.4
Copyright 2004-2012 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

No broadcast interfaces found - exiting.

(Even bringing eth0 up first does not help)

This does appear to be a bug in dhclient.

Comment 2 Richard W.M. Jones 2015-05-26 16:44:02 UTC
I really do think this is a bug in Ubuntu's dhclient utility.

The "No broadcast interfaces" error is explained here.  It seems to be
plainly a bug:
https://lists.isc.org/pipermail/dhcp-users/2013-March/016584.html

Patching the appliance so that we specify which interface we bring
up instead causes qemu to crash(!)  However maybe it would work better
on baremetal.  Make sure you delete the libguestfs appliance after
doing this so that it gets re-built/cached on the next run.

diff --git a/appliance/init b/appliance/init
index 3c5ef1b..106a900 100755
--- a/appliance/init
+++ b/appliance/init
@@ -87,7 +87,7 @@ ip link set dev lo up
 
 if grep -sq guestfs_network=1 /proc/cmdline; then
     if dhclient --version >/dev/null 2>&1; then
-        dhclient
+        dhclient eth0
     else
         dhcpcd
     fi

Comment 3 Richard W.M. Jones 2015-05-26 17:07:09 UTC
I tried it with dhclient from vivid, which still has the
"No broadcast interfaces" bug, but doesn't crash dhcp.  However
it has a different bug where /etc/fstab must exist else it goes
into an infinite loop.

The patch below fixes all this nonsense, but it's totally not
upstreamable.

diff --git a/appliance/init b/appliance/init
index 3c5ef1b..49775c2 100755
--- a/appliance/init
+++ b/appliance/init
@@ -87,7 +87,9 @@ ip link set dev lo up
 
 if grep -sq guestfs_network=1 /proc/cmdline; then
     if dhclient --version >/dev/null 2>&1; then
-        dhclient
+        # dhclient on Ubuntu breaks if /etc/fstab doesn't exist.  WTF?
+        touch /etc/fstab
+        dhclient eth0
     else
         dhcpcd
     fi

Comment 4 Pino Toscano 2016-08-04 13:16:18 UTC
This has been fixed/worked around with
https://github.com/libguestfs/libguestfs/commit/fd60be95091a1923e108f72caf251f5549eeccd0
which is in libguestfs >= 1.33.47.

Comment 5 Pino Toscano 2017-02-06 08:47:44 UTC
*** Bug 1419315 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.