JeOS does not have name resolution in place when boot.sh is executed.

[Jarl]

Binary package hint: python-vm-builder

Jaunty server on AMD64 quad-core AMD Phenom(tm) II X4 920 Processor

I am creating a JeOS using vmbuilder (following the official documentation) as this:
sudo vmbuilder kvm ubuntu --suite jaunty --flavour virtual --arch amd64 --bridge br0 --libvirt qemu:///system --ip dhcp --firstboot boot.sh

With a boot.sh containing this:
apt-get update >> /var/aptget_update.out 2>> /var/aptget_update.err

When booting the sytem the files /var/aptget_update.out contains
Err http://archive.ubuntu.com jaunty Release.gpg
  Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com jaunty-updates Release.gpg
  Could not resolve 'archive.ubuntu.com'
Err http://security.ubuntu.com jaunty-security Release.gpg
  Could not resolve 'security.ubuntu.com'
Reading package lists...

and /var/aptget_update.err contains:
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jaunty/Release.gpg Could not resolve 'archive.ubuntu.com'

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jaunty-updates/Release.gpg Could not resolve 'archive.ubuntu.com'

W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/jaunty-security/Release.gpg Could not resolve 'security.ubuntu.com'

W: Some index files failed to download, they have been ignored, or old ones used instead.
W: You may want to run apt-get update to correct these problems

However when the system is done booting. Network is OK after I have logged in. Further, if I introduce a "sleep 1" in the begining of boot.sh, it solves the problem.

Jarl

[Jarl (jarl-dk)]

I have made the same machine with a boot.sh that contains
ifconfig >> /var/ifconfig.out 2>> /var/ifconfig.err
apt-get update >> /var/aptget_update.out 2>> /var/aptget_update.err

Now the output of ifconfig.out shows:
eth0 Link encap:Ethernet HWaddr 52:54:00:0a:08:14
          inet6 addr: fe80::5054:ff:fe0a:814/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:1336 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1788808 (1.7 MB) TX bytes:258 (258.0 B)

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: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)

That is no IP address has been assigned when boot.sh is executed.

[Nick Barcet (nijaba)]

Thanks a lot for taking the time to help us make vmbuilder better.

Could you please try adding a wait loop for DHCP to have finished its setup in boot.sh such as

   while (! ping -c 1 dk.archive.ubuntu.com); do sleep 1; done

If that solves your issue, we could consider adding this wait before invoking the boot script, but it would have to be generalized first. In the mean time we could add a note for other that may run in a similar problem at https://help.ubuntu.com/community/JeOSVMBuilder

[Jarl (jarl-dk)]

I can confirm that a single line with
  sleep 1
in the begining of the boot.sh script solves the problem

I do not suggest to add such a loop, because if th server is not attached to the network, or the specific host is down, you will have a long waiting time. But I do suggest to add a "sleep 1" or "sleep 2", or at least mention the problem and a proposed solution in the documentation.

Jarl

[Jarl (jarl-dk)]

Further note that if you install a lot of other packages such as apache2, mysql (with vmbuilder option --addpkg), etc. which will have some boot scripts running at start up, you will not experience this bug, as these rc.d scripts will run before boot.sh, and hence DHCP is up when execution reaches boot.sh.

Jarl

[Jarl (jarl-dk)]

Hint: If you want to reproduce this bug, it might help to do as me; run the DHCP server on a really slow machine, overload it with respect to cpu-load and memory-usage. Then boot your JeOS maing a DHCP request to this slow server.

And further when considering a real solution to this bug (some DHCP waiting mechanism), don't forget to have a time-out mechanism, there might not be a DHCP server in the network.

Jarl