Fresh installs of vagga often fails to install ubuntu

[tailhook]

The error is often like this:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libc6-dev : Depends: libc6 (= 2.19-0ubuntu6.7) but 2.19-0ubuntu6.8 is to be installed
E: Unable to correct problems, you have held broken packages.
ERROR:vagga::builder: Error building container "rust-musl": step Install(["build-essential", "libc6-dev", "ca-certificates"]) failed: error running <Command "/usr/bin/apt-get" "install" "-y" "build-essential" "libc6-dev" "ca-certificates"; environ: {"LD_PRELOAD"="/usr/lib/libeatmydata/libeatmydata.so","TERM"="dumb","LANG"="en_US.UTF8","HOME"="/tmp","DEBIAN_FRONTEND"="noninteractive","PATH"="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games",}; chroot="/vagga/root"; work-dir="/work"> exited with code 100
ERROR:vagga::wrapper: Error executing _build: Builder exited with code 1
Command <Command "/proc/self/exe" ("vagga_wrapper") "_build" "rust-musl"; environ: {"_VAGGA_HOME"="/home/pc","RUST_LOG"="warn","TERM"="screen",}; uid_map=[UidMap { inside_uid: 0, outside_uid: 1000, count: 1 }, UidMap { inside_uid: 1, outside_uid: 100000, count: 65535 }]; gid_map=[GidMap { inside_gid: 0, outside_gid: 100, count: 1 }, GidMap { inside_gid: 1, outside_gid: 100000, count: 65535 }]> exited with code 124

The interesting part is this:

The following packages have unmet dependencies:
 libc6-dev : Depends: libc6 (= 2.19-0ubuntu6.7) but 2.19-0ubuntu6.8 is to be installed
E: Unable to correct problems, you have held broken packages.

(actual versions and even packages are not relevant, we'll just use them as example)

At closer investigation it turns out:

1. 2.19-0ubuntu6.7 is the libc version in trusty-updates and trusty-security (even fresh package indices on main ubuntu mirror)
2. 2.19-0ubuntu6.8 is the libc version in ubuntu daily image

I.e. the version of package in image is newer than in repositories.

This means that for users of vagga who have yesterday's image cached it's fine. But new users might need to wait for few hours for packages to be delivered even to central repository (archive.ubuntu.com), and it may take up to additional 6 hours for changes to propagate to regional mirror.

Additionally this kind of error:

The following packages have unmet dependencies:
 libssl-dev : Depends: zlib1g-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Is just the same. If you add zlib1g-dev to the list of explicitly installed packages, you will see the actual version conflict, like above.

What we can do:

1. Download yesterday's image https://cloud-images.ubuntu.com/daily/server/trusty/%Y%m%d/. This means we need user to have clock carefully set up. And may have a problem at around midnight.
2. Download release (=old) image. This means we have to upgrade more packages. Especially for older releases like precise and trusty.

Any other options? Any ways to force apt-get to downgrade packages? (Does the latter even makes sense?)

If you need a quickfix you can change your !Ubuntu trusty link to:

    - !UbuntuRelease
      url: https://cloud-images.ubuntu.com/daily/server/trusty/20160525/trusty-server-cloudimg-amd64-root.tar.gz

(Note this link will become obsolete in just a few days).

The biggest difficulty with this issues is that it ruins the first experience, so we can't fix it with another setting or whatever. It must work out of the box.

[tailhook]

Actually I was wrong about downloading yesterday's image. Here is what we have now:

[DIR]   20160422/   22-Apr-2016 22:11   -    
[DIR]   20160426/   26-Apr-2016 18:49   -    
[DIR]   20160503/   03-May-2016 16:00   -    
[DIR]   20160511/   11-May-2016 14:34   -    
[DIR]   20160525/   25-May-2016 23:54   -    
[DIR]   current/    25-May-2016 23:54   -    

I mean there is no any particular schedule as far as I understand. So hopefully this but will not be triggered too often and we don't need to have hacks to avoid it. (Actually it is an issue with ubuntu infrastructure rather than anything wrong with vagga).

So I'm removing it from this milestone.

Another question is that this kind of errors were most common reason for switching from random mirror to central default mirror (189baae1). And the http://archive.ubuntu.com actually fails more often than a random mirror. So we should probably rollback that change.

[lilianmoraru]

I am not sure only if I agree with the rallback to the mirrors. At least on Ubuntu 12.04, the mirrors are problematic, but only behind a proxy(Not an issue with vagga in itself, so...).

Yes, I guess I agree with all the points :smile:

[tailhook]

@lilianmoraru, well, so what do you use http://archive.ubuntu.com ?

[lilianmoraru]

@tailhook Behind the company's weird proxy, yes. At home, never...

Since using the mirrors in most cases should help with network speed, I don't think you should worry about a weird proxy configuration and satisfying its limitations.

[tailhook]

Anyway, I've created #268 to track mirror issues.