1.108ubuntu15.4 hangs on upgrade

According to #7 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure

if this issue is confirmed, the bug importance should be set to critical

I think it maybe that 15.3 had the issue, and 15.4 is OK. When I rebooted I was able to complete the 15.4 update, and another machine managed to do the 15.4 update without trouble.

The retention of console-setup in xenial-proposed is causing a side-effect on ubiquity [2.21.63.5] installation which depend specifically on that 1.108ubuntu15.4 version[1].
IMHO ubiquity should have been put on hold as well to make sure console-setup and ubiquity were release at the same time.

If the hang cannot be fix soon, meaning that console-setup will stay in -proposed for a while or maybe eventually drop ?
Maybe we should consider rolling back ubiquity to use console-setup 1.108ubuntu15.3 ? to at least unblock the dependencies created by last console-setup change[2]

[1] root@xenial:~# apt-get install ubiquity
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:
 ==> ubiquity : Depends: console-setup (>= 1.108ubuntu15.4) but 1.108ubuntu15.3 is to be installed <===
            Recommends: grub-pc but it is not going to be installed or
                        grub but it is not going to be installed or
                        grub-efi but it is not going to be installed
            Recommends: dmraid but it is not going to be installed
            Recommends: btrfs-tools but it is not going to be installed
            Recommends: ubuntu-drivers-common but it is not going to be installed
            Recommends: lvm2 but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

[2] debian/changelog

ubiquity (2.21.63.5) xenial; urgency=medium

  * Cherry-pick support for WPA2 Enterprise. LP: #1107935
  * Automatic update of included source packages: console-setup
    1.108ubuntu15.4.

 -- Dimitri John Ledkov <email address hidden> Tue, 31 Oct 2017 17:45:29 +0000

Note: If we activate xenial-proposed and then install ubiquity, it works because the dependency is met.

Thoughts ?

FYI and to make sure the discussion is updated on both bugs and seen by everybody directly or indirectly involve :

# cyphermox comment:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1721626/comments/8

Whether ubiquity is installable is a different issue than console-setup breaking on upgrade though. The ubiquity change is being reverted, but we still need to figure out why the console-setup upgrade fails.

I've attempted to set up a virtual machine with Ubuntu Server, where I can approximate the upgrade procedure for both server or desktop (by changing whether and which plymouth splash shows). I haven't been able to reproduce the issue yet.

It really looks to me like it's an issue with speaking to plymouth while doing updates unattended, but am I wrong on that assumption?

And if it's indeed unattended upgrades, what does /boot/grub/grub.cfg look like on the affected system?

On Fri, Nov 10, 2017 at 07:54:33PM -0000, Mathieu Trudel-Lapierre wrote:
> Whether ubiquity is installable is a different issue than console-setup
> breaking on upgrade though. The ubiquity change is being reverted, but
> we still need to figure out why the console-setup upgrade fails.

> I've attempted to set up a virtual machine with Ubuntu Server, where I
> can approximate the upgrade procedure for both server or desktop (by
> changing whether and which plymouth splash shows). I haven't been able
> to reproduce the issue yet.

> It really looks to me like it's an issue with speaking to plymouth while
> doing updates unattended, but am I wrong on that assumption?

During normal operations, plymouth --ping should return immediately because
plymouthd /should not be running/. plymouthd should only be running at boot
and shutdown, and in neither case should we be in the middle of an upgrade.

So this is absolutely a plymouth bug, or multiple distinct plymouth bugs.
It is impractical to know with 100% confidence when and if we have fixed
these bugs. This is why I agree with Adam's position that we should instead
fix the behavior of plymouth --ping so that it has some sort of timeout
mechanism instead of blocking indefinitely, in order to make maintainer
scripts that need to check plymouth more robust in the face of hanging
plymouthds.

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