virtualbox http error

[anandvenkatanarayanan]

Hi,
When using Packer Version 0.7.2, the default http port and IP generated when using the virtualbox builder does not seem to work. See the GIST link for JSON, Kickstart and Packer Log.
https://gist.github.com/anandvenkatanarayanan/46f261ac0d70a7cea8ca

The exact error message from Anaconda is

I also did some tests to figure what is going on in the background, but that does not throw any clue.

I see a daemon process listening on port 8891

anandv@anandv-desktop:~/source/PackerFiles$ netstat -a | grep 8891
tcp6       0      0 [::]:8891               [::]:*                  LISTEN     

But a wget on the localhost fails.

anandv@anandv-desktop:~/source/PackerFiles$ wget http://localhost:8891/kickstart-rhel-server-6.5-x86_64.cfg
--2014-12-01 13:51:35--  http://localhost:8891/kickstart-rhel-server-6.5-x86_64.cfg
Resolving localhost (localhost)... 127.0.0.1
Connecting to localhost (localhost)|127.0.0.1|:8891... connected.
HTTP request sent, awaiting response... 404 Not Found
2014-12-01 13:51:35 ERROR 404: Not Found.

I cannot also connect to the 10.0.2.2 address.

However if I replace the http address in the JSON template with another IP, packer is able to build. So I guess this is a problem in figuring out the correct HTTP IP to use with VirtualBox?

Thanks
Anand V

[anandvenkatanarayanan]

This is on a Ubuntu 14.04.1 running virtualbox 4.3.20 with the extension pack.

[rickard-von-essen]

Could you provide the output of:

ifconfig
sudo iptables -L filter
sudo iptables -L nat

During a run just after you get

virtualbox-iso: Starting HTTP server on port XXXX

in your output.

[anandvenkatanarayanan]

On Terminal 1
==> RHEL-Server-6.5-x86_64-virtualbox-iso: Starting HTTP server on port 8838

On Terminal 2

anandv@anandv-desktop:~$ ifconfig
eth0 Link encap:Ethernet HWaddr fc:4d:d4:d6:e3:63
inet addr:10.74.146.121 Bcast:10.73.158.255 Mask:255.255.252.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1718682 errors:0 dropped:0 overruns:0 frame:0
TX packets:847909 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2395203755 (2.3 GB) TX bytes:60421038 (60.4 MB)
Interrupt:20 Memory:f7100000-f7120000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:2238 errors:0 dropped:0 overruns:0 frame:0
TX packets:2238 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:146870 (146.8 KB) TX bytes:146870 (146.8 KB)

virbr0 Link encap:Ethernet HWaddr 2e:73:a0:88:f9:b2
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

anandv@anandv-desktop:~$ sudo iptables -L filter
[sudo] password for anandv:
iptables: No chain/target/match by that name.

anandv@anandv-desktop:~$ sudo iptables -L nat
iptables: No chain/target/match by that name.

[dhartford]

Similar issue with packer server: centos6,5 guest setup: centos6.5/vmware-iso

The HTTP_DIRECTORY as packer's hosting webserver is only serving IPv6, but not IPv4. the .HTTPIP configuration is showing IPv4 address.

Similar confirmation approach - VNC to system-in-progress, see the HTTP_DIRECTORY port.

cmd> netstat -a |grep 8812
tcp6 0 0 [::]:8812 [::]:* LISTEN

Attempts to manually disable IPv6 did not help (http://wiki.centos.org/FAQ/CentOS6#head-d47139912868bcb9d754441ecb6a8a10d41781df).

No options visible to have the HTTP_DIRECTORY server force IPv4 usage (probably the ideal).

[pasikarkkainen]

For some reason this seems to still be broken in Packer v1.1.2.
http server only listens on tcp6.

I'm running Packer on CentOS 7.4 host.

[pasikarkkainen]

It seems even though the packer http server shows as listening on "tcp6" in netstat it doesn't matter, it still works over ipv4 aswell. The actual problem was elsewhere.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.