Can't upgrade from 15.10 Wily to 16.04 Xenial in LXC container

I encountered a similar problem when upgrading a container from 13.04 to 13.10.

The problem was that the listed dependencies for ubuntu-release-upgrader-core were not sufficient.

The solution was to install python-apt. (Even that was a bit difficult; I had to manually create an empty file, /etc/python2.7/sitecustomize.py).

If python-apt doesn't solve the problem, then you could try searching for other missing dependencies. Here's one way to do that:

(1) List the reverse-dependencies of ubuntu-release-upgrader-core:

apt-cache rdepends ubuntu-release-upgrader-core

On ubuntu-14.04 the reverse-dependencies include update-manager-core.

(2) List the dependencies of update-manager-core,

apt-cache depends update-manager-core

Try installing some or all of these dependencies and see whether it solves the problem.

same thing happens with vivid->wily upgrade.

It does this in an unprivileged (true root) as well as a apparmor-unconfined container.

I'm seeing this in Vivid -> Wily too, but in a Xen VM, not an LXC container. None of the above suggestions worked, it logs the same errors as Serge.

I tried to upgrade to 16.04 RC1 running Ubuntu Gnome 15.10 and get error messages that the update manager exited with an unspecified code. Even the bug report choked when trying to report the issue.

I'm running into the same thing trying to upgrade from 14.04 to 16.04.

After Googling around about the issue, this link at first looked like a promising lead, as I'm running into this on Haswell hardware and I have Core2 hardware that was unaffected:

https://groups.google.com/forum/#!topic/mechanical-sympathy/QbmpZxp6C64

So I tried using a custom-compiled 4.4 series kernel to see if that resolved the issue, and it does cause the upgrade to stop hanging in the futex wait channel, but, unfortunately, does not cause the upgrade to stop hanging. On the 4.4 kernel, system monitor shows the process to be in waiting channel 0 instead of the futex wait channel, but gdb shows the process to be hung in "sem_wait()".

I am running into this on bare hardware, not a container or VM.

Given that I'm seeing it on a Haswell machine but my Core2 laptop did not experience the hang, and given that using a newer kernel version changed the specifics of how the hang is occuring, it seems to be related to the kernel bug discussed at the Google Groups link above, but the kernel bug can't be the whole story, or else the new kernel would have fixed it.

As an update to my comment above, while the release upgrader hung and did not finish the upgrade, it *did* disable all my ppa's and switch over to the Xenial repositories, which ended up leaving my system broken next time I tried pulling in updates (thinking the upgrade had failed completely and the system was still using Trusty repositories). I'm not sure what packages are at Xenial versions and what packages are at still at Trusty versions, there seems to be a mix.

So it seems I can't expect Ubuntu to upgrade between LTS versions without barfing all over itself. Gee, what fun.