virt-customize: dhclient can't get IP address
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libguestfs (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Ubuntu 18.04 LTS
When running virt-customize against an existing raw image, it seems to hang for a while trying to get IP address, and then gives up. Functionality worked on Ubuntu 17.10, and expected to be working on 18.04. Below are logs from 18.04 and 17.10 of virt-customize running to modify ubuntu-
With verbose flag passed, the logs of temporary VM launch:
Ubuntu 18.04 LTS:
+ ip addr add 127.0.0.1/8 brd + dev lo scope host
+ ip link set dev lo up
+ test 1 = 1
++ ls -I all -I default -I lo /proc/sys/
+ iface=eth0
+ touch /etc/fstab
+ dhclient --version
+ dhclient eth0
=== waits for timeout here ===
+ ip a
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
=== NOTE: no ip address above ===
+ ip r
+ cat /etc/resolv.conf
cat: /etc/resolv.conf: No such file or directory
virt-customize works perfectly on Ubuntu 17.10:
+ ip addr add 127.0.0.1/8 brd + dev lo scope host
+ ip link set dev lo up
+ test 1 = 1
++ ls -I all -I default -I lo /proc/sys/
+ iface=eth0
+ touch /etc/fstab
+ dhclient --version
+ dhclient eth0
=== gets IP almost immediately ===
...
+ ip a
1: lo: <LOOPBACK,
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
inet 169.254.2.15/16 brd 169.254.255.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fec0::5054:
valid_lft 86400sec preferred_lft 14400sec
inet6 fe80::5054:
valid_lft forever preferred_lft forever
=== NOTE: ip address above ===
+ ip r
default via 169.254.2.2 dev eth0
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.2.15
...
Ubuntu 18.04 LTS:
$ dpkg -l | egrep "guestfs|
ii ipxe-qemu 1.0.0+git-
ii ipxe-qemu-
ii libguestfs-
ii libguestfs-perl 1:1.36.13-1ubuntu3 amd64 guest disk image management system - Perl bindings
ii libguestfs-
ii libguestfs-tools 1:1.36.13-1ubuntu3 amd64 guest disk image management system - tools
ii libguestfs-
ii libguestfs0:amd64 1:1.36.13-1ubuntu3 amd64 guest disk image management system - shared library
ii libsys-virt-perl 4.0.0-1 amd64 Perl module providing an extension for the libvirt library
ii libvirt0:amd64 4.0.0-1ubuntu8 amd64 library for interfacing with different virtualization systems
ii qemu-block-
ii qemu-system-common 1:2.11+
ii qemu-system-x86 1:2.11+
ii qemu-utils 1:2.11+
$
$ lsb_release -rd
Description: Ubuntu 18.04 LTS
Release: 18.04
$
Ubuntu 17.10:
$ dpkg -l | egrep "guestfs|
ii ipxe-qemu 1.0.0+git-
ii libguestfs-
ii libguestfs-perl 1:1.34.6-7ubuntu1 amd64 guest disk image management system - Perl bindings
ii libguestfs-
ii libguestfs-tools 1:1.34.6-7ubuntu1 amd64 guest disk image management system - tools
ii libguestfs-
ii libguestfs0:amd64 1:1.34.6-7ubuntu1 amd64 guest disk image management system - shared library
ii libsys-virt-perl 3.5.0-1build1 amd64 Perl module providing an extension for the libvirt library
ii libvirt0:amd64 3.6.0-1ubuntu6.5 amd64 library for interfacing with different virtualization systems
ii qemu-block-
ii qemu-system-common 1:2.10+
ii qemu-system-x86 1:2.10+
ii qemu-utils 1:2.10+
$ lsb_release -rd
Description: Ubuntu 17.10
Release: 17.10
$
Thank you.
tags: | added: bionic |
I'm not sure, but can you try a few simple tests:
$ virt-rescue --scratch --network -v -x
$ virt-rescue --scratch -v -x
Do those commands fail in the same way? Does it make a difference if the
--network option is present?
Also it might be worth using the latest version 1.38.