Bug #16249
rake build: Waiting for domain to get an IP Address... vagrant-libvirt
0%
Description
Hello,
I try create a ISO from doc: https://tails.boum.org/contribute/build/
On step: rake build && rake vm:halt
rake build
Using HTTP proxy: http://vagrant-stretch:3142
Bringing machine ‘default’ up with ‘libvirt’ provider…
> default: Cleaned up shared folders
> default: Cleaned up shared folders
> default:
> default: Machine id: a16f76d7-a2a0-4e90-8225-28707b6d8333
> default: Should be mounting folders
> default: /vagrant, opts: {:type=>:“9p”, :readonly=>true, :guestpath=>“/vagrant”, :hostpath=>“/home/andrey/tails-project/tails/vagrant”, :disabled=>false, :__vagrantfile=>true, :target=>“/vagrant”, :accessmode=>“passthrough”, :mount=>true, :mount_tag=>“0e3837df0e8db96cdcc36f9bde77ab7”}
> default:
> default: Machine id: a16f76d7-a2a0-4e90-8225-28707b6d8333
> default: Should be mounting folders
> default: /amnesia.git, opts: {:type=>:“9p”, :readonly=>true, :guestpath=>“/amnesia.git”, :hostpath=>“/home/andrey/tails-project/tails”, :disabled=>false, :__vagrantfile=>true, :target=>“/amnesia.git”, :accessmode=>“passthrough”, :mount=>true, :mount_tag=>“64a458bbf9e5cc195e07ddf7b309345”}
> default: Starting domain.
> default: Waiting for domain to get an IP address…
^Crake aborted!
Debug in vagrant:
~/tails-project/tails/vagrant$ vagrant —debug up
> default: /amnesia.git, opts: {:type=>:"9p", :readonly=>true, :guestpath=>"/amnesia.git", :hostpath=>"/home/andrey/tails-project/tails", :disabled=>false, :__vagrantfile=>true, :target=>"/amnesia.git", :accessmode=>"passthrough", :mount=>true, :mount_tag=>"64a458bbf9e5cc195e07ddf7b309345"}
INFO warden: Calling IN action: #<VagrantPlugins::ProviderLibvirt::Action::PrepareNFSSettings:0x007f53a0364b60>
INFO warden: Calling IN action: #<VagrantPlugins::ProviderLibvirt::Action::ShareFolders:0x007f53a03273f0>
INFO interface: info: Creating shared folders metadata...
INFO interface: info: > default: Creating shared folders metadata…
> default: Creating shared folders metadata...
INFO warden: Calling IN action: #<VagrantPlugins::ProviderLibvirt::Action::CreateNetworks:0x007f53a02f1fc0>
INFO create_networks: Using vagrant-libvirt at 192.168.121.0/24 as the management network nat is the mode
DEBUG create_networks: In config found network type forwarded_port options {:guest=>22, :host=>2222, :host_ip=>"127.0.0.1", :id=>"ssh", :auto_correct=>true, :protocol=>"tcp"}
DEBUG create_networks: Searching for network with options {:iface_type=>:private_network, :network_name=>"vagrant-libvirt", :ip=>"192.168.121.0", :netmask=>"255.255.255.0", :dhcp_enabled=>true, :forward_mode=>"nat", :guest_ipv6=>"no", :autostart=>false}
DEBUG create_networks: looking up network with ip 192.168.121.0
DEBUG create_networks: Checking that network name does not clash with ip
DEBUG create_networks: looking up network named vagrant-libvirt
DEBUG create_networks: generating name for bridge
DEBUG create_networks: looking up bridge named virbr0
DEBUG create_networks: looking up bridge named virbr1
DEBUG create_networks: found available bridge name virbr1
DEBUG create_networks: created network
INFO create_networks: Saving information about created network vagrant-libvirt, UUID=1e8f91dd-24aa-4d98-a932-d5e8e853207e to file /home/andrey/tails-project/tails/vagrant/.vagrant/machines/default/libvirt/created_networks.
INFO warden: Calling IN action: #
INFO create_network_interfaces: Using vagrant-libvirt at 192.168.121.0/24 as the management network nat is the mode
DEBUG create_network_interfaces: In config found network type forwarded_port options {:guest=>22, :host=>2222, :host_ip=>“127.0.0.1”, :id=>“ssh”, :auto_correct=>true, :protocol=>“tcp”}
DEBUG create_network_interfaces: Adapter not specified so found slot 0
DEBUG create_network_interfaces: Found network by name
INFO create_network_interfaces: Creating network interface eth0 connected to network vagrant-libvirt.
INFO warden: Calling IN action: #
INFO warden: Calling IN action: #
INFO interface: info: Starting domain.
INFO interface: info: > default: Starting domain.
> default: Starting domain.
INFO warden: Calling IN action: #
DEBUG wait_till_up: Searching for IP for MAC address: 52:54:00:c7:d7:b4
INFO interface: info: Waiting for domain to get an IP address…
INFO interface: info: > default: Waiting for domain to get an IP address...
> default: Waiting for domain to get an IP address…
INFO retryable: Retryable exception raised: #<Fog::Errors::TimeoutError: The specified wait_for timeout (2 seconds) was exceeded>
INFO retryable: Retryable exception raised: #<Fog::Errors::TimeoutError: The specified wait_for timeout (2 seconds) was exceeded>
Host OS: cat /etc/issue
Debian GNU/Linux 9 \n \l
Any idea?
Subtasks
History
#1 Updated by mercedes508 2018-12-30 11:31:31
- Assignee set to intrigeri
#2 Updated by intrigeri 2019-01-02 19:54:14
- Category set to Build system
- Status changed from New to Confirmed
- Assignee changed from intrigeri to a.leb
- Type of work changed from Debian to Research
I’ve seen this error from time to time but was never able to reproduce it: usually, retrying fixes it. So I’m sorry I can’t be of much help here :/
#3 Updated by a.leb 2019-01-03 13:11:20
root@tails-dev:/home/andrey# ifconfig -a
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.11 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::20c:29ff:fe06:fd6b prefixlen 64 scopeid 0x20
ether 00:0c:29:06:fd:6b txqueuelen 1000 (Ethernet)
RX packets 1013420 bytes 1351764943 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 377710 bytes 59622353 (56.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1 (Local Loopback)
RX packets 40 bytes 4048 (3.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 40 bytes 4048 (3.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.121.1 netmask 255.255.255.0 broadcast 192.168.121.255
ether 52:54:00:6e:9a:86 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
virbr1-nic: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 52:54:00:6e:9a:86 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::fc54:ff:fe25:7bde prefixlen 64 scopeid 0x20
ether fe:54:00:25:7b:de txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 90 (90.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@tails-dev:/home/andrey# ps ax | grep dns
1442 ? S 0:00 /usr/sbin/dnsmasq —conf-file=/var/lib/libvirt/dnsmasq/vagrant-libvirt.conf —leasefile-ro —dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
1443 ? S 0:00 /usr/sbin/dnsmasq —conf-file=/var/lib/libvirt/dnsmasq/vagrant-libvirt.conf —leasefile-ro —dhcp-script=/usr/lib/libvirt/libvirt_leaseshelper
23802 pts/1 S+ 0:00 grep dns
root@tails-dev:/home/andrey# tcpdump -i virbr1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on virbr1, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@tails-dev:/home/andrey# brctl show
bridge name bridge id STP enabled interfaces
virbr1 8000.5254006e9a86 yes virbr1-nic
vnet0
root@tails-dev:/home/andrey# tcpdump -i vnet0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
https://github.com/vagrant-libvirt/vagrant-libvirt/issues/560
“@infernix What do I do if my machine is NOT issuing a DHCP request?
Using wireshark I find nothing.” ©
Same.
OS: Debian 9.
Platform: VMware® Workstation 15 Pro
root@tails-dev:/home/andrey# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel® Core™ i5-2400 CPU @ 3.10GHz
stepping : 7
microcode : 0x29
cpu MHz : 3109.456
cache size : 6144 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm kaiser tpr_shadow vnmi ept vpid tsc_adjust arat
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips : 6220.32
clflush size : 64
cache_alignment : 64
address sizes : 43 bits physical, 48 bits virtual
power management:
#4 Updated by a.leb 2019-01-09 18:18:32
a.leb wrote:
Workaround:
Behavior corrected if update version of libvirt-daemon-system & vagrant-libvirt to “last”.
Before:
apt-cache policy libvirt-daemon-system
libvirt-daemon-system:
Installed: 3.0.0-4+deb9u3
Candidate: 3.0.0-4+deb9u3
Version table:
* 3.0.0-4+deb9u3 700
700 http://deb.debian.org/debian stretch/main amd64 Packages
700 http://security.debian.org/debian-security stretch/updates/main amd64 Packages
100 /var/lib/dpkg/status
After upgrade:
apt-cache policy libvirt-daemon-system
libvirt-daemon-system:
Installed: 4.10.0-2
Candidate: 4.10.0-2
Version table:
* 4.10.0-2 500
500 http://ftp.us.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
apt-cache policy vagrant-libvirt
vagrant-libvirt:
Installed: 0.0.45-2
Candidate: 0.0.45-2
Version table:
* 0.0.45-2 500
500 http://ftp.us.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status
https://tracker.debian.org/media/packages/v/vagrant-libvirt/changelog-0.0.45-2
https://tracker.debian.org/media/packages/libv/libvirt/changelog-4.10.0-2
http://changelogs.ubuntu.com/changelogs/pool/main/libv/libvirt/libvirt_4.0.0-1ubuntu8.2/changelog
Something has been fixed between “stable” and “unstable” version.
#5 Updated by intrigeri 2019-06-01 14:49:25
- Status changed from Confirmed to Rejected
> Behavior corrected if update version of libvirt-daemon-system & vagrant-libvirt to “last”.
Cool, I’m glad you’ve found a solution!
I’m afraid it’s unlikely we’ll go to the root of this problem and fix it so I’m rejecting this ticket :/