TurnKey Linux Virtual Appliance Library

Slow progress and errors when doing apt-get update inside VirtualBox

I'm having trouble doing an apt-get update on a fresh install of Symfony Appliance through VirtualBox. I'm using the newest version of VB (3.1.6), downloaded the newest version of the turnkey Symfony Appliance (2009.10). After importing the appliance I start it up. I don't have DHCP running on my network, so I manually assign the IP address and DNS. I use google's DNS (8.8.8.8, 8.8.4.4). I restart it to make sure the network setting take effect, and everything seems to be working. I can ping various sites, including the repositories in my sources.list file:

[root:~]# ping google.com
PING google.com (72.14.204.147) 56(84) bytes of data.
64 bytes from iad04s01-in-f147.1e100.net (72.14.204.147): icmp_seq=1 ttl=51 time=16.0 ms

[root:~]# ping archive.turnkeylinux.org
PING turnkeylinux.org (97.107.134.22) 56(84) bytes of data.
64 bytes from turnkeylinux.org (97.107.134.22): icmp_seq=1 ttl=50 time=23.2 ms

[root:~]# ping archive.ubuntu.com
PING archive.ubuntu.com (91.189.88.45) 56(84) bytes of data.
64 bytes from prat.canonical.com (91.189.88.45): icmp_seq=1 ttl=49 time=93.8 ms

[root:~]# ping security.debian.org
PING security.debian.org (128.101.240.212) 56(84) bytes of data.
64 bytes from saens.debian.org (128.101.240.212): icmp_seq=1 ttl=48 time=53.5 ms

However when I try to run 'apt-get update' I get very slow execution, including some repositories being ignored and some errors. Some of the repositories will be updated normally (e.g. 1 second for each), some will wait between 1-10 minutes with the message "Waiting for headers" and the progress at either 0% or 99% (it varies each time I run apt-get update). If I let it run long enough (30-60 minutes) it will complete and look like this:

[root:~]# apt-get update
Get:1 http://security.debian.org lenny/updates Release.gpg [835B]
Get:2 http://archive.turnkeylinux.org hardy-security Release.gpg [481B]    
Get:3 http://archive.turnkeylinux.org hardy Release.gpg [481B]                                   
Get:4 http://archive.ubuntu.com hardy-security Release.gpg [189B]                                
Get:5 http://archive.ubuntu.com hardy Release.gpg [189B]                   
Get:6 http://archive.ubuntu.com hardy-updates Release.gpg [189B]           
Ign http://archive.turnkeylinux.org hardy-security Release                                                                                                                                        
Ign http://security.debian.org lenny/updates Release                 
Ign http://archive.ubuntu.com hardy-security Release                 
Ign http://archive.turnkeylinux.org hardy Release                                                
Hit http://archive.turnkeylinux.org hardy-security/main Packages     
Err http://security.debian.org lenny/updates/main Packages                                              
  Connection failed [IP: 128.31.0.36 80]
Ign http://archive.ubuntu.com hardy Release                                                             
Err http://archive.turnkeylinux.org hardy-security/universe Packages       
  Connection failed
Ign http://archive.ubuntu.com hardy-updates Release                               
Err http://archive.turnkeylinux.org hardy/main Packages                    
  Connection failed
Err http://archive.ubuntu.com hardy-security/main Packages                        
  Connection failed [IP: 91.189.88.40 80]
Err http://archive.turnkeylinux.org hardy/universe Packages                
  Connection failed
Err http://archive.ubuntu.com hardy-security/universe Packages
  Connection failed [IP: 91.189.88.45 80]
Err http://archive.ubuntu.com hardy/main Packages    
  Connection failed [IP: 91.189.88.40 80]
Err http://archive.ubuntu.com hardy/universe Packages
  Connection failed [IP: 91.189.88.45 80]
Err http://archive.ubuntu.com hardy-updates/main Packages
  Connection failed [IP: 91.189.88.40 80]
Err http://archive.ubuntu.com hardy-updates/universe Packages
  Connection failed [IP: 91.189.88.45 80]
Fetched 2364B in 36min2s (1B/s)
W: Failed to fetch http://archive.turnkeylinux.org/ubuntu/dists/hardy-security/universe/bin...  Connection failed
W: Failed to fetch http://security.debian.org/dists/lenny/updates/main/binary-i386/Packages.gz  Connection failed [IP: 128.31.0.36 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hardy-security/main/binary-i386/P...  Connection failed [IP: 91.189.88.40 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hardy-security/universe/binary-i3...  Connection failed [IP: 91.189.88.45 80]
W: Failed to fetch http://archive.turnkeylinux.org/ubuntu/dists/hardy/main/binary-i386/Pack...  Connection failed
W: Failed to fetch http://archive.turnkeylinux.org/ubuntu/dists/hardy/universe/binary-i386/...  Connection failed
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hardy/main/binary-i386/Packages.gz  Connection failed [IP: 91.189.88.40 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hardy/universe/binary-i386/Packag...  Connection failed [IP: 91.189.88.45 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hardy-updates/main/binary-i386/Pa...  Connection failed [IP: 91.189.88.40 80]
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/hardy-updates/universe/binary-i38...  Connection failed [IP: 91.189.88.45 80]
E: Some index files failed to download, they have been ignored, or old ones used instead.

I've been searching for a solution for a few days now and have tried everything I can think of (hardcoding IPs in /etc/hosts, using ftp instead of http, deleting the entire Symfony Appliance and recreating it, XX). I don't know if it matters, but I'm on a Verizon FiOS connection with an ActionTec router in a very default configuration (no proxy, etc). My desktop computer is connected to the router, and VB is running on my desktop with Symfony Appliance set up in that.

Other things that might be of help. Note that this LAN uses IPs in the format 192.0.0.*, where 192.0.0.203 is the Symfony Appliance and 192.0.0.9 is the router/gateway:

[root:~]# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 symfony

#Required for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
[root:~]# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 8.8.8.8
nameserver 8.8.4.4
[root:~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 08:00:27:60:80:22  
          inet addr:192.0.0.203  Bcast:192.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe60:8022/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:15944 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10614 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1381016 (1.3 MB)  TX bytes:1697671 (1.6 MB)
          Interrupt:10 Base address:0xd020 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:32 errors:0 dropped:0 overruns:0 frame:0
          TX packets:32 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2676 (2.6 KB)  TX bytes:2676 (2.6 KB)
[root:~]#  route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.0.0       0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.0.0.9       0.0.0.0         UG    100    0        0 eth0
[root:~]# cat /etc/apt/sources.list.d/sources.list
deb http://archive.turnkeylinux.org/ubuntu hardy main
deb http://archive.turnkeylinux.org/ubuntu hardy universe

deb http://archive.ubuntu.com/ubuntu hardy main
deb http://archive.ubuntu.com/ubuntu hardy universe
# deb http://archive.ubuntu.com/ubuntu hardy restricted
# deb http://archive.ubuntu.com/ubuntu hardy multiverse

deb http://archive.ubuntu.com/ubuntu hardy-updates main
deb http://archive.ubuntu.com/ubuntu hardy-updates universe
# deb http://archive.ubuntu.com/ubuntu hardy-updates restricted
# deb http://archive.ubuntu.com/ubuntu hardy-updates multiverse

# deb http://archive.ubuntu.com/ubuntu hardy-backports main
# deb http://archive.ubuntu.com/ubuntu hardy-backports universe
# deb http://archive.ubuntu.com/ubuntu hardy-backports restricted
# deb http://archive.ubuntu.com/ubuntu hardy-backports multiverse
[root:~]# cat /etc/apt/sources.list.d/security.sources.list
deb http://archive.turnkeylinux.org/ubuntu hardy-security main
deb http://archive.turnkeylinux.org/ubuntu hardy-security universe

deb http://archive.ubuntu.com/ubuntu hardy-security main
deb http://archive.ubuntu.com/ubuntu hardy-security universe
# deb http://archive.ubuntu.com/ubuntu hardy-security restricted
# deb http://archive.ubuntu.com/ubuntu hardy-security multiverse

deb http://security.debian.org/ lenny/updates main

 

Any help anyone could provide would be greatly appreciated.

Jeremy's picture

Not sure

It may not even be remotely related to this problem but I was under the impression that of the 192.x.x.x series of IPs only 192.168.x.x was set aside for private networking (class C). According to this table, 192.0.0.x IP range is 'reserved' (for what I don't know).

Beyond that, assuming that your host machine is not suffering from slow networking I'd perhaps try an alternate VM hosting software, to see if its something to do with that. VMware may be an option, even if just trying for the sake of troubleshooting.

Liraz Siri's picture

Scientific debugging

I recommend you zero in on the bug via process of scientific experimentation/elimination. Make an hypothesis about what could be going wrong and come up with an experiment that would confirm/debug your hypothesis. This way you gradually (or quickly!) close in on the real problem. As JedMeister points out it could be any number of things. There's no way to know for sure without doing a bunch of experiments on your end.

Doing some more testing

Thanks for your suggestions. I've been testing everything I can think of over the last three days to no avail. I'll try using VMware and a few more things and report back my results.

Running into this too

I'm running into this as well. I'm running VirtualBox 3.1.6 on OS X 10.6 Server. It seems to happen regardless of the enabled sources (unless I disable them all of course!).

I just tried this in another

I just tried this in another Ubuntu 8.04 VM I have, not from a TurnKey image, and apt-get update works fine. The VM settings are nearly identical (bridged networking, etc).

Works fine in a stock Ubuntu install

I just tried this in another Ubuntu 8.04 VM I have, not from a TurnKey image, and apt-get update works fine. The VM settings are nearly identical (bridged networking, etc).

I'm also on OSX 10.6

I'm also on OSX 10.6, so that might be a commonality. I've also since found out there isn't a version of VMware for OSX, so I can't test that out. Right now I'm in the process of testing out a stack from Bitnami to see if it works any better. If the Bitnami stack is also having problems then it might be with the version of VirtualBox for Mac. I'll let you know what I find out.

Actually, there is VMWare

Actually, there is VMWare Fusion for OS X. I can't install it on the server I have access to though.

Sorry, I should have been more clear

Sorry, I should have been more clear. I was looking for VMware Player which isn't made for the Mac (as far as I can tell).

Different results on different computers

Well now this is strange. I've been having this problem on my office Mac when trying to "apt-get update" using VirtualBox with a Turnkey VM. So I tried a VM from Bitnami on my office Mac, and it did the update just fine. (This seems to be the same results as Andrew.) However I just tested it on my home Mac, using the same version of VirtualBox and the same Turnkey VM, and it worked just fine. Which makes me think it's related to a networking issue.

In the past three days of searching for a solution, a lot of problems similar to this one seemed to involve apt-proxy. All of the recommended solutions seem to be turning off the proxy or changing the proxy configuration. I don't believe that the Turnkey VM uses any proxy by default, does it? Could my problem be related to the way that VirtualBox is functioning as a network proxy? Any idea how I could diagnose this? The inner working of networks and proxies are out of my league.

Jeremy's picture

No TKL doesn't have any preconfigured proxy setup

Perhaps another thing you could try is to use the ISO install (rather than the VM). It probably shouldn't make any difference but perhaps it will?

Here's what I've found so

Here's what I've found so far:

  • The VM works fine as is on VB 3.1.6 on OS X 10.6.3 client and on Windows 7.
  • On 10.6.3 server, by default the above problem appears.
  • If I switch to NAT networking, apt-get update works fine.
  • Or, if I change the network card to the Intel PRO/1000 MT Desktop (82540M), it works fine.

So, it appears to either be a kernel driver bug or a bug in Virtualbox. At least there is a workaround of either changing the network card or using NAT.

Update: Workaround implemented, don't know why it's working

 

I've done some more testing. First, I'm not using OSX server anywhere (these are all desktop OS). I installed VB and the Symfony Appliance on my home Mac (also 10.6) and it worked just fine. I then installed it on my MacBook Pro (MBP) at my house, and it worked fine. I then brought my MBP to my office and it worked just fine. So the only place that it's not working is my Mac Pro at my office. But as far as I can tell, the setup on the Mac Pro is identical to the setup on both the MBP and my home Mac. Here are other things I've tested on my Mac Pro (none of which have worked):
  • Changing the repositories in my sources.list file to be ftp instead of http
  • Changing the repositories in my sources.list file to be specific to the US (e.g. us.archive.ubuntu.com)
  • Installing different turnkey stacks (Tomcat, Symfony, Redmine)
  • Using different name servers
  • I switched my office network to use IP addresses in the range 192.168.1.* (since previously I was using the non-standard 192.0.0.*)
  • I tried setting the VE to use NAT for networking, but I wasn’t able to access the network at all. Right now I have it set to use "PCnet-FAST III) since that is the default and it works on all of my other computers.
  • My Mac Pro has two built-in Ethernet cards. I had been using eth1, so switched the cable to the other card and configured it to use eth0.
So right now I'm sitting here with a Mac Pro and a MBP sitting right next to each other. I just completely removed the Turnkey Appliance from both, and downloaded the TurnKey Lamp appliance and re-imported the appliance on both machines. I left all of the defaults so that the setups are identical. After starting the appliances on both computers, the booted normally and got their IP info from DHCP normally. I then logged into both and ran a apt-get update. It worked fine on the MBP but failed on the Mac Pro.
 
UPDATE: I switched the Network Adapter Type to Intel PRO/1000 MT Desktop and it started working. I don't know why it's working, but at least it's working. Note that this configuration is different than the setups on all of my other working computers (whith are still using PCnet-FAST III). I'm going to write up a summary and post it on the VB forums and see if they have any idea. Thanks to everyone for your help.
Jeremy's picture

Nice work on the troubleshooting

and good on you for sharing the info around and feeding the info back to VirtualBox. yes

Thanks!

I'm running VirtualBox 3.1.6r59338 in Windows 7 with an Ubuntu 10.04 LTS Beta 2 VM and had this same problem. The only NIC that worked properly was the Intel Desktop. WEIRD bug.

I retract that statement....

My speeds are totally random, but some to most often cap out at 2k, even with the different driver. I even switch my repositories because in another forum someone said the US repositories are capped for some reason.

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account, used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <strike> <caption>

More information about formatting options

Leave this field empty. It's part of a security mechanism.
(Dear spammers: moderators are notified of all new posts. Spam is deleted immediately)