Ubuntu GNOME Trusty HWE upgrade fails to install libwayland-egl1-mesa-lts-xenial

I'm not sure what to think so far but I wanted to make some notes of things I've tried (and looked at) so far so I don't forget.

I performed the same identical test on Ubuntu amd64 Trusty w/Utopic HWE on the same hardware this AM and it boots fine. The Ubuntu GNOME install I performed this failed test on yesterday is i386 so I thought it might be either GNOME or arch specific.

To see if it was related to gdm I tried lightdm with lightdm-gtk-greeter but it also won't boot. The one difference is that I actually see the login screen but trying to login just bounces me back to the login screen. (gdm is set to auto-login)

I've tried renaming .Xauthority and .ICEauthority but that didn't change much, if anything. The one difference I notice since renaming those two files and changing back to gdm is that I no longer see "Restoring resolver state" but rather just a blank black screen.

I can always log into a TTY from the "frozen" state. Not sure if this is helpful but .xsession-errors shows:

Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
init: gnome-session (GNOME) main process (1565) terminated with status 1
init: logrotate main process (1491) killed by TERM signal
init: upstart-dbus-session-bridge main process (1533) terminated with status 1
init: Disconnected from notified D-Bus bus

Next I plan on performing another test using Ubuntu GNOME amd64 Trusty w/Wily HWE to see if this might be arch specific. Of course that may not be 100% definitive because the first (failed) test started with a Utopic HWE, but the passing Ubuntu test this AM was on an install using the Utopic HWE.

Have I confused anyone besides myself so far?

I'm subscribing Jeremy Bicha in case he may have some ideas.

The aforementioned HWE EOL upgrade test using Ubuntu GNOME amd64 Trusty w/Wily HWE failed in the same manner as the original test so I'm leaning towards this being Ubuntu GNOME specific. I'll try to test another flavor or two to verify that ASAP but I'll be AFK for several hours.

Attempting to boot a guest session also results in a login bounce.

Tested beginning with Lubuntu 14.04.2 i386 and the HWE EOL upgrade boots fine.

Also fresh installs of Ubuntu GNOME 14.04.5 work perfectly well on the same hardware. I even applied all available updates to a freshly installed 14.04.5 and it still boots just fine.

So, based on current results, this is somehow limited only to HWE EOL upgrades on Ubuntu GNOME.

This hardware is also affected running either the nouveau or nvidia drivers:

AMD Sempron Processor LE-1250 @ 2.2 GHz
nVidia C61 [GeForce 7025 / nForce 630a] (rev a2)
nVidia MCP61 High Definition Audio (rev a2)
nVidia MCP61 Ethernet (rev a2)
2GB DDR2 RAM

I'm pretty sure I figured this out. The HWE upgrade process fails to install libwayland-egl1-mesa-lts-xenial. If I do so from TTY (or recovery mode) and reboot all seems well!

I need to wipe these failed HWE upgrades to make space for more testing so I'm attaching apt logs from one in case they may be helpful to the X-Swat team.

And term.log

From what I have been able to determine it looks like libwayland-egl1-mesa-lts-xenial isn't depended on in the same way libwayland-egl1-mesa-lts-utopic was.

bdmurray@upgrade-trusty-amd64:~$ apt-cache rdepends libwayland-egl1-mesa-lts-xenial
libwayland-egl1-mesa-lts-xenial
Reverse Depends:
  libwayland-egl1-mesa-lts-xenial:i386
  libwayland-egl1-mesa-lts-xenial:i386
  libegl1-mesa-dev-lts-xenial
  libegl1-mesa-dev
bdmurray@upgrade-trusty-amd64:~$ apt-cache rdepends libwayland-egl1-mesa-lts-utopic
libwayland-egl1-mesa-lts-utopic
Reverse Depends:
  libwayland-egl1-mesa-lts-utopic:i386
  libwayland-egl1-mesa-lts-utopic:i386
  libwayland-egl1-mesa-lts-utopic-dbg
  libegl1-mesa-drivers-lts-utopic

bdmurray, by the way, I don't see any bug subscriber for the xorg-lts-xenial,-wily, etc. packages which goes against Ubuntu policy for "main". I'm guessing they should have the same team subscribers as

https://launchpad.net/ubuntu/+source/xorg

utopic had libegl1-mesa-drivers as an actual package, later releases carry a dummy one

IIRC stock-Ubuntu installs libwayland-egl1-mesa(-lts-foo) as well, and doesn't have issues with upgrades.. so why does GNOME?

While xenial itself has a libegl1-mesa-drivers as a dummy package:

 $ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"
[ 8:40AM 10006 ] [ bdmurray@impulse:~ ]
 $ apt-cache search libegl1-mesa-drivers
libegl1-mesa-drivers - transitional dummy package
libegl1-mesa-drivers-lts-utopic - Transitional package for libegl1-mesa-drivers-lts-utopic
libegl1-mesa-drivers-lts-utopic-dbg - Transitional package for libegl1-mesa-drivers-lts-utopic-dbg

There are no libgel1-mesa-drivers-lts-(vivid|wily|xenial) packages.

bdmurray@upgrade-trusty-amd64:~$ apt-cache search libegl1-mesa-drivers-lts
libegl1-mesa-drivers-lts-quantal - Transitional package for libegl1-mesa-drivers
libegl1-mesa-drivers-lts-quantal-dbg - Transitional package for libegl1-mesa-drivers-dbg
libegl1-mesa-drivers-lts-raring - Transitional package for libegl1-mesa-drivers
libegl1-mesa-drivers-lts-raring-dbg - Transitional package for libegl1-mesa-drivers-dbg
libegl1-mesa-drivers-lts-saucy - Transitional package for libegl1-mesa-drivers
libegl1-mesa-drivers-lts-saucy-dbg - Transitional package for libegl1-mesa-drivers-dbg
libegl1-mesa-drivers-lts-trusty - Transitional package for libegl1-mesa-drivers
libegl1-mesa-drivers-lts-trusty-dbg - Transitional package for libegl1-mesa-drivers-dbg
libegl1-mesa-drivers-lts-utopic - free implementation of the EGL API -- hardware drivers
libegl1-mesa-drivers-lts-utopic-dbg - free implementation of the EGL API -- driver debugging symbols

I've recreated the situation described in the bug description by installing a virtual machine with Ubuntu Gnome 14.04.2 and using 'hwe-support-status --show-replacements' to determine packages to upgrade I ended up with a system that booted without X. The file /var/log/gdm/:0-greeter.log seems to contain information about the problem.

** (gnome-settings-daemon:1161): WARNING **: Error activating plugin 'Background'
gnome-shell: error while loading shared libraries: libwayland-egl.so.1: cannot open shared object file: No such file or directory

Hello Erick, or anyone else affected,

Accepted update-manager into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/update-manager/1:0.196.18 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I tested update-manager version 0.196.18 from trusty-proposed and libwayland-egl1-mesa-lts-xenial was installed (on a system that had the -vivid version) after installing the new HWE stack.

Also libwayland-egl1-mesa-lts-xenial was not recommended for install if its vivid counterpart isn't already installed.

bdmurray@upgrade-trusty-amd64:~$ hwe-support-status --show-replacements
xserver-xorg-lts-xenial libgl1-mesa-glx-lts-xenial linux-generic-lts-xenial linux-image-generic-lts-xenial
bdmurray@upgrade-trusty-amd64:~$ apt-cache policy libwayland-egl1-mesa-lts-vivid
libwayland-egl1-mesa-lts-vivid:
  Installed: (none)
  Candidate: 10.5.9-2ubuntu1~trusty2
  Version table:
     10.5.9-2ubuntu1~trusty2 0
        500 http://192.168.10.7/ubuntu/ trusty-updates/main amd64 Packages
        100 /var/lib/dpkg/status

I still encountered a failure beginning with Ubuntu GNOME Trusty i386 w/Vivid HWE. There was a kernel upgrade prior to performing the HWE upgrade (most recent prior updates performed on 2016-08-07 followed by installing update-manager from proposed):

Start-Date: 2016-08-13 09:58:41
Commandline: apt-get dist-upgrade
Install: linux-headers-3.19.0-66:i386 (3.19.0-66.74~14.04.1, automatic), linux-headers-3.19.0-66-generic:i386 (3.19.0-66.74~14.04.1, automatic), linux-image-3.19.0-66-generic:i386 (3.19.0-66.74~14.04.1, automatic), linux-image-extra-3.19.0-66-generic:i386 (3.19.0-66.74~14.04.1, automatic)
Upgrade: nautilus-data:i386 (3.10.1-0ubuntu9.9, 3.10.1-0ubuntu9.11), modemmanager:i386 (1.0.0-2ubuntu1, 1.0.0-2ubuntu1.1), initramfs-tools:i386 (0.103ubuntu4.3, 0.103ubuntu4.4), linux-generic-lts-vivid:i386 (3.19.0.65.47, 3.19.0.66.48), libmm-glib0:i386 (1.0.0-2ubuntu1, 1.0.0-2ubuntu1.1), firefox:i386 (47.0+build3-0ubuntu0.14.04.1, 48.0+build2-0ubuntu0.14.04.1), libgd3:i386 (2.1.0-3ubuntu0.2, 2.1.0-3ubuntu0.3), libdrm-intel1:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), avahi-autoipd:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libcurl3:i386 (7.35.0-1ubuntu2.6, 7.35.0-1ubuntu2.8), oxideqt-codecs-extra:i386 (1.15.8-0ubuntu0.14.04.1, 1.16.5-0ubuntu0.14.04.1), grub-common:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), libdrm-radeon1:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), nautilus:i386 (3.10.1-0ubuntu9.9, 3.10.1-0ubuntu9.11), isc-dhcp-client:i386 (4.2.4-7ubuntu12.4, 4.2.4-7ubuntu12.5), grub-pc:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), libnautilus-extension1a:i386 (3.10.1-0ubuntu9.9, 3.10.1-0ubuntu9.11), libavahi-common-data:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libxrandr2:i386 (1.4.2-1, 1.5.0-1~trusty1), libavahi-client3:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libdrm2:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), base-files:i386 (7.2ubuntu5.4, 7.2ubuntu5.5), language-pack-gnome-en:i386 (14.04+20150219, 14.04+20160720), libavahi-common3:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libdrm-nouveau2:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), language-pack-en:i386 (14.04+20150219, 14.04+20160720), linux-libc-dev:i386 (3.13.0-92.139, 3.13.0-93.140), avahi-utils:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), grub2-common:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), avahi-daemon:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), grub-pc-bin:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), libavahi-gobject0:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libcurl3-gnutls:i386 (7.35.0-1ubuntu2.6, 7.35.0-1ubuntu2.8), libavahi-glib1:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), language-pack-en-base:i386 (14.04+20150219, 14.04+20160720), initramfs-tools-bin:i386 (0.103ubuntu4.3, 0.103ubuntu4.4), firefox-locale-en:i386 (47.0+build3-0ubuntu0.14.04.1, 48.0+build2-0ubuntu0.14.04.1), isc-dhcp-common:i386 (4.2.4-7ubuntu12.4, 4.2.4-7ubuntu12.5), linux-headers-generic-lts-vivid:i386 (3.19.0.65.47, 3.19.0.66.48), linux-image-generic-lts-vivid:i386 (3.19.0.65.47, 3.19.0.66.48), language-pack-gnome-en-base:i386 (14.04+20150219, 14.04+20160720), libavahi-core7:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1)
En...

I have no idea why I had that previous failure. I've since run two more tests. One was a repeat test beginning with a fresh install of Ubuntu GNOME 14.04.3 i386 (just like above) and it worked fine. I ran another test beginning with a fresh install of Ubuntu GNOME 14.04.2 amd64 and it also worked just fine. I'm going to run one additional test beginning with 14.04.4 just to be sure, but I think that one failure must have been a fluke - or something I did wrong.

I've run several more tests today and all seems well. I can only assume that the failure in comment #17 was an error on my part. So I think we're good to go.

On Sat, Aug 13, 2016 at 05:10:16PM -0000, Erick Brunzell wrote:
> I still encountered a failure beginning with Ubuntu GNOME Trusty i386
> w/Vivid HWE. There was a kernel upgrade prior to performing the HWE
> upgrade (most recent prior updates performed on 2016-08-07 followed by
> installing update-manager from proposed):
>
> Start-Date: 2016-08-13 09:58:41
> Commandline: apt-get dist-upgrade
> Install: linux-headers-3.19.0-66:i386 (3.19.0-66.74~14.04.1, automatic), linux-headers-3.19.0-66-generic:i386 (3.19.0-66.74~14.04.1, automatic), linux-image-3.19.0-66-generic:i386 (3.19.0-66.74~14.04.1, automatic), linux-image-extra-3.19.0-66-generic:i386 (3.19.0-66.74~14.04.1, automatic)
> Upgrade: nautilus-data:i386 (3.10.1-0ubuntu9.9, 3.10.1-0ubuntu9.11), modemmanager:i386 (1.0.0-2ubuntu1, 1.0.0-2ubuntu1.1), initramfs-tools:i386 (0.103ubuntu4.3, 0.103ubuntu4.4), linux-generic-lts-vivid:i386 (3.19.0.65.47, 3.19.0.66.48), libmm-glib0:i386 (1.0.0-2ubuntu1, 1.0.0-2ubuntu1.1), firefox:i386 (47.0+build3-0ubuntu0.14.04.1, 48.0+build2-0ubuntu0.14.04.1), libgd3:i386 (2.1.0-3ubuntu0.2, 2.1.0-3ubuntu0.3), libdrm-intel1:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), avahi-autoipd:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libcurl3:i386 (7.35.0-1ubuntu2.6, 7.35.0-1ubuntu2.8), oxideqt-codecs-extra:i386 (1.15.8-0ubuntu0.14.04.1, 1.16.5-0ubuntu0.14.04.1), grub-common:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), libdrm-radeon1:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), nautilus:i386 (3.10.1-0ubuntu9.9, 3.10.1-0ubuntu9.11), isc-dhcp-client:i386 (4.2.4-7ubuntu12.4, 4.2.4-7ubuntu12.5), grub-pc:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), libnautilus-extension1a:i386 (3.10.1-0ubuntu9.9, 3.10.1-0ubuntu9.11), libavahi-common-data:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libxrandr2:i386 (1.4.2-1, 1.5.0-1~trusty1), libavahi-client3:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libdrm2:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), base-files:i386 (7.2ubuntu5.4, 7.2ubuntu5.5), language-pack-gnome-en:i386 (14.04+20150219, 14.04+20160720), libavahi-common3:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libdrm-nouveau2:i386 (2.4.64-1~ubuntu14.04.1, 2.4.67-1ubuntu0.14.04.1), language-pack-en:i386 (14.04+20150219, 14.04+20160720), linux-libc-dev:i386 (3.13.0-92.139, 3.13.0-93.140), avahi-utils:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), grub2-common:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), avahi-daemon:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), grub-pc-bin:i386 (2.02~beta2-9ubuntu1.11, 2.02~beta2-9ubuntu1.12), libavahi-gobject0:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), libcurl3-gnutls:i386 (7.35.0-1ubuntu2.6, 7.35.0-1ubuntu2.8), libavahi-glib1:i386 (0.6.31-4ubuntu1, 0.6.31-4ubuntu1.1), language-pack-en-base:i386 (14.04+20150219, 14.04+20160720), initramfs-tools-bin:i386 (0.103ubuntu4.3, 0.103ubuntu4.4), firefox-locale-en:i386 (47.0+build3-0ubuntu0.14.04.1, 48.0+build2-0ubuntu0.14.04.1), isc-dhcp-common:i386 (4.2.4-7ubuntu12.4, 4.2.4-7ubuntu12.5), linux-headers-generic-lts-vivid:i386 (3.19.0.65.47, 3.19.0.66.48), linux-image-generic-lts-vivid:i386 (3.19.0.65.47, 3.19.0.66.48), language-pack-gnome-en-base:i386 (14.04+2015...

"This is because you didn't first upgrade update-manager."

I figured something like that. I was convinced that it must have been an error on my part after repeating several more tests with no issue. Chalk that up to either too little (or too much) coffee.

This bug was fixed in the package update-manager - 1:0.196.19

---------------
update-manager (1:0.196.19) trusty-proposed; urgency=medium

  * hwe-support-status: utilize a virtualbox metapackage set. (LP: #1498059)

 -- Brian Murray <email address hidden> Mon, 15 Aug 2016 11:14:48 -0700

Status changed to 'Confirmed' because the bug affects multiple users.