oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog

Sorry that I couldn't use ubuntu-bug, LP crashed on me when trying. Attaching logs manually.

From the beginning of term.log:
Use of uninitialized value $template in exists at /usr/share/perl5/Debconf/Template.pm line 81, <GEN2> chunk 1.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN2> chunk 1.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN2> chunk 1.
Use of uninitialized value $template in exists at /usr/share/perl5/Debconf/Template.pm line 81, <GEN2> chunk 2.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN2> chunk 2.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN2> chunk 2.
Use of uninitialized value $template in exists at /usr/share/perl5/Debconf/Template.pm line 81, <GEN2> chunk 3.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN2> chunk 3.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN2> chunk 3.
Use of uninitialized value $template in exists at /usr/share/perl5/Debconf/Template.pm line 81, <GEN2> chunk 4.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN2> chunk 4.

Then further in the log
debconf: Unable to initialise frontend: Gnome
debconf: (Unable to load Gtk -- is libgtk2-perl installed?)
debconf: falling back to frontend: Dialog
Use of uninitialized value $template in exists at /usr/share/perl5/Debconf/Template.pm line 81, <GEN0> chunk 1.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN0> chunk 1.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN0> chunk 1.
Use of uninitialized value $template in exists at /usr/share/perl5/Debconf/Template.pm line 81, <GEN0> chunk 2.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN0> chunk 2.
Use of uninitialized value $item in exists at /usr/share/perl5/Debconf/DbDriver/Cache.pm line 39, <GEN0> chunk 2.

As a consequent, the dialog asking to restart services on libc6 upgrade didn't show up and the question was invisible with the Dialog debconf frontend. From a user perspective the upgrade hanged.

debconf will automatically fall back from the Gnome frontend to Dialog, then Readline, then Teletype, then Noninteractive, depending on which one appears to be usable first. The problem is that update-manager creates a VTE terminal to run things in for logging purposes, which does a good enough job of being a terminal that debconf has no realistic way to tell that it isn't supposed to use it due to it not actually being visible. In fact, the solution isn't obvious because the terminal *might* be visible (expanded terminal widget or whatever).

What's a little curious is that update-manager isn't already overriding DEBIAN_FRONTEND at least to dialog, seeing as it contains this code:

        # if no libgtk2-perl is installed show the terminal
        frontend= os.environ.get("DEBIAN_FRONTEND") or "gnome"
        if frontend == "gnome" and self._cache:
          if (not "libgtk2-perl" in self._cache or
              not self._cache["libgtk2-perl"].is_installed):
            frontend = "dialog"
            self.expander.set_expanded(True)
        self.env = ["VTE_PTY_KEEP_FD=%s"% self.writefd,
                    "APT_LISTCHANGES_FRONTEND=none"]
        if not os.environ.has_key("DEBIAN_FRONTEND"):
          self.env.append("DEBIAN_FRONTEND=%s" % frontend)

So this should already cause upgrades without libgtk2-perl installed to run with the Dialog frontend and with the terminal expanded so that you can see it. (Perhaps not ideal UI, but it would at least work.)

My first thought was that perhaps libgtk2-perl had been removed during the upgrade, but no, that isn't so, and perl-base hasn't even been upgraded yet so this isn't a perl upgrade problem. So I'm a little puzzled at this point.

And indeed you do have libgtk2-perl installed, so the above code is actually irrelevant. It should have just worked ...

I believe that this may be specific to amd64 at this point in time. The problem is that libpango1.0-0 is upgraded quite early, and it Depends: libc6 (>= 2.14) on amd64 (but only >= 2.4 on other architectures). When libpango1.0-0 has been unpacked, 'use Gtk2;' fails:

Can't load '/usr/lib/perl5/auto/Pango/Pango.so' for module Pango: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0) at /usr/lib/perl/5.12/DynaLoader.pm line 192.
 at /usr/lib/perl5/Gtk2.pm line 31
Compilation failed in require at /usr/lib/perl5/Gtk2.pm line 31.
BEGIN failed--compilation aborted at /usr/lib/perl5/Gtk2.pm line 31.
Compilation failed in require.
BEGIN failed--compilation aborted.

Now, there's something else wrong, because the log shows the Gnome frontend failing to load even after the new libc6 has been unpacked. I think I'm along the right lines here, though.

I have a suspicion that fixing bug 850264 may work around this in practice; the unsatisfied pre-dependency while trying to unpack libnih1 points to a problem in apt, and fixing that might well force libc6 to be unpacked earlier and hence avoid this problem. I wouldn't mind some confirmation of that, though.

We've established on IRC that it isn't bug 850264 after all; but there is definitely an apt bug here, albeit possibly one fixed in precise that needs to be backported to oneiric. It wouldn't entirely surprise me if this had been fixed by the giant unpack/configure ordering rearrangement.

Oh, false alarm, sorry. debconf fails to configure libc6:amd64 due to this bug, and *that's* what causes libnih1 to fail.

/me -> bed

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

I'm not sure whether it's related, but my install process - which exhibited the errors above - culminated in this:

dpkg: error processing libgtk2.0-0 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of librsvg2-common:
 librsvg2-common depends on libgdk-pixbuf2.0-0 (>= 2.22.0); however:
  Package libgdk-pixbuf2.0-0 is not configured yet.
 librsvg2-common depends on libgtk2.0-0 (>= 2.21.5); however:
  Package libgtk2.0-0 is not configured yet.
 librsvg2-common depends on librsvg2-2 (= 2.36.1-0ubuntu1); however:
  Package librsvg2-2 is not configured yet.
dpkg: error processing librsvg2-common (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of libgdk-pixbuf2.0-dev:
 libgdk-pixbuf2.0-dev depends on libgdk-pixbuf2.0-0 (= 2.26.1-1); however:
  Package libgdk-pixbuf2.0-0 is not configured yet.
 libgdk-pixbuf2.0-dev depNo apport report written because MaxReports is reached already
       No apport report written because MaxReports is reached already
                                                                     No apport report written because MaxReports is reached already
                                                   ends on gir1.2-gdkpixbuf-2.0 (= 2.26.1-1); however:
  Package gir1.2-gdkpixbuf-2.0 is not configured yet.
dpkg: error processing libgdk-pixbuf2.0-dev (--configure):
 dependency problems - leaving unconfigured
Setting up libatk1.0-dev (2.4.0-0ubuntu1) ...
Setting up xorg-sgml-doctools (1:1.10-1) ...
Setting up libxext-dev (2:1.3.0-3build1) ...
Setting up libxinerama-dev (2:1.1.1-3build1) ...
Setting up libxi-dev (2:1.6.0-0ubuntu2) ...
Setting up x11proto-fixes-dev (1:5.0-2ubuntu1) ...
Setting up libxfixes-dev (1:5.0-4ubuntu4) ...
Setting up libxcomposite-dev (1:0.4.3-2build1) ...
Setting up libxdamage-dev (1:1.1.3-2build1) ...
Setting up libxml2-utils (2.7.8.dfsg-5.1ubuntu4) ...
dpkg: dependency problems prevent configuration of gir1.2-gtk-2.0:
 gir1.2-gtk-2.0 depends on gir1.2-gdkpixbuf-2.0; however:
  Package gir1.2-gdkpixbuf-2.0 is not configured yet.
 gir1.2-gtk-2.0 depends on libgtk2.0-0 (>= 2.24.0); however:
  Package libgtk2.0-0 is not configured yet.
dpkg: error processing gir1.2-gtk-2.0 (--configure):
 dependency problems - leaving unconfigured
dpkg: too many errors, stopping
Processing triggers for libc-bin ...
No apport report written because MaxReports is reached already
                                                              ldconfig deferred processing now taking place
Errors were encountered while processing:
 libtiff4
 libgdiplus
 libmono-system-web2.0-cil
 libmono2.0-cil
 libmono-system-drawing4.0-cil
 libmono-system-web4.0-cil
 libmono-http4.0-cil
 libmono-microsoft-web-infrastructure1.0-cil
 libmono-system-windows-forms4.0-cil
 libmono-system-messaging4.0-cil
 libmono-system-servicemodel4.0-cil
 libmono-system-web-extensions4.0-cil
 libmono-system-servicemodel-web4.0-cil
 libmono-system-data-services4.0-cil
 libmono-system-drawing-design4.0-cil
 libmono-system-design4.0-cil
 libmono-system-runtime2.0-cil
 libmono-system-runtime4.0-cil
 libmono-system-servicemodel-discovery4.0-cil
 lib...

Hi Tim, thanks for reporting. Your problem is caused a package failing to configure, either libgdk-pixbuf2.0-0 or one of its dependencies. Perhaps your issue is related, perhaps not. You could open a new bug report for this (and provide the full log, because this is not enough to analyse it fully).

i'd like to know if what i experienced on 3 different updates in the last 2 days, is this bug or if something else needs to be reported?

i suck explaining things in detail, but will give it my best shot:

all 3 upgrades appeared to freeze at the point: "Preparing libc6". in the bottom of the update window, there is an option to show details with a little arrow thing next to it....i had to click the arrow to reveal the terminal window below, and there i saw that the update/install was actually prompting me to reply to some question (i cannot remember exactly what it was, so i will not try to guess), i needed to reply by saying "ok"....i did that by pressing the "tab" key. that highlighted the word "ok" in the terminal, then i pressed "enter" on my keyboard to complete and continue.

the update would not continue unless i replied to the question. it sat, apparently frozen waiting for me to press "show details" and answer the question.

there are 2 or 3 more such prompts before the update completes. the good news is....the upgrades went flawlessly after that on all 3 computers: a lenovo T61 thinkpad, a lenovo t410 thinkpad, and a lenovo k330 ideacentre desktop.

...i think the update should open the terminal window automatically when it gets to that point (Preparing libc6?), as a new user will not know enough to open the "show details" window to reveal the prompt and continue.

On Fri, May 04, 2012 at 05:48:18PM -0000, jackel wrote:
> i'd like to know if what i experienced on 3 different updates in the
> last 2 days, is this bug or if something else needs to be reported?

Yes, this is exactly the same bug.

> ...i think the update should open the terminal window automatically when
> it gets to that point (Preparing libc6?), as a new user will not know
> enough to open the "show details" window to reveal the prompt and
> continue.

I quite agree, and I understand there's meant to be code already here to do
that, which seems to be failing.

thanks steve, i have never tried repoting a bug before...hope my explanation was sufficient and helps some others. i have seen a few threads in the forums which sounded like those who encountered this same "freezing" episode eventually gave up, and pressed the power button to restart....leaving them with a unbootable system.

On Fri, May 04, 2012 at 06:07:13PM -0000, Steve Langasek wrote:
> I quite agree, and I understand there's meant to be code already here
> to do that, which seems to be failing.

The current code for this in update-manager checks if DEBIAN_FRONTEND is
set to "gnome" without libgtk2-perl installed at the start of the
upgrade, and in that case it sets the frontend to "dialog" and expands
the terminal widget. However, what's happening here is that
libgtk2-perl gets temporarily deconfigured or removed during the
upgrade, probably due to a major Perl transition. There's no code in
update-manager to handle that case; it would have to keep an eye on the
terminal to notice attempts to read from it, and expand the terminal
widget then.

(Didn't synaptic or something use to do this, once upon a time?)

Note that the terminal window may also not be visible due to bug #663457 (screen captures attached).

Here is a screen capture of the blocking Debconf dialog that appears during the upgrade on an amd64 system (I have upgraded 2 computers so far and have not seen that on the i386 one): this is during the libc upgrade.
At that moment the glibc does not seem to be available (I have not been able to launch the usual screen capture applications because Gtk relies on glibc so I did use xwd for the capture), so that's probably the reason of the Debconf dialog downgrade.
Combined with #663457 this is a major issue on netbook systems.

08:56 < mvo> * fix automatic expand of the terminal if no activity happened for >300s (LP: #993190)
08:56 < mvo> this one?
08:56 < slangasek> mvo: yes
08:56 < mvo> this needs reupload to proposed
08:56 < mvo> its in the precise branch of u-m

Hi

  Would an alternate solution be to timeout the dialog after a long wait ( >300s), and for libc to either restart the service or ignore the dialog ?

-- ritz

There is no mechanism for libc to do this, and I doubt we'd be
interested in adding such a thing to debconf; it's in too generic a
position to be able to have any remote idea whether a timeout is safe.

This happened to a friend this morning. Luckily I was able to point the issue out to him. I'm sure this was fixed at one point and has regressed again.

This is fixed in quantal, but there doesn't seem to have been a changelog ref for it.

I can confirm that upgrading from 11.10 to 12.04 will auto expand terminal dialog if upgrade idles in excess of 300s.

Thanks,
Adam

I am confused. This is listed as being fixed in 1:0.156.14.2 in precise-proposed, but then the latest upload in the queue, 1:0.156.14.6, claims to fix it again. Is that a type-o in the changelog or did the issue actually not get fixed in the previous upload?

If its a type-o, then the upload needs to be re-done. If it wasn't actually fixed in the previous upload, then that should probably be noted in the changelog.

Hello Gema, or anyone else affected,

Accepted update-manager into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/update-manager/1:0.156.14.6 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 change the bug tag from verification-needed to verification-done. If it does not, 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!

So I'm confused as to how this could have been fixed already in precise, given that the changes in DistUpgradeViewGtk3.py to support this were backed out as a result of the 1:0.156.14.5 security update. It's possible that when Adam tested, he did so against the right (precise-proposed) release-upgrader tarball to allow this to work, but that's definitely all superseded now by the security update - hence the new SRU upload.

A diff against precise-updates confirms that 1:0.156.14.2 is not part of the revision history of the currently published package. Hence the new SRU.

After having install the version of update-manager from precise-proposed I updated libreoffice, and a bunch of mono packages with no issue.

@Brian: I don't think upgrading packages on precise verifies of a bugfix for an oneiric-to-precise dist-upgrade issue.

SRU verification for Precise:

I did the following test:
1. Installed Oneiric + updates
2. Copied meta-release and meta-release-proposed to /root/update-manager
3. Changed the entry URI to file:///root/update-manager in /etc/update-manager/meta-release
4. Upgraded with update-manager -p

I couldn't reproduce the original issue and tried to force it by removing libgtk2-perl but in that case the terminal opens directly when installation of packages starts. Despite this, I did 3 upgrades from Oneiric to Precise with version 1:0.156.14.6 from -proposed and didn't see any regression.

Marking as verification-done

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

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

---------------
update-manager (1:0.156.14.6) precise-proposed; urgency=low

  * lp:~ember/update-manager/ubuntu.bug1002956:
    - fix missing ReleaseNotesViewerWebkit.py support, thanks to
      Pedro Fragoso (LP: #1002956)
  * DistUpgrade/DistUpgradeCache.py:
    - increase estimated kernel size slightly to match the precise
      kernels
  * fix automatic expand of the terminal if no activity happend
    for >300s (LP: #979661)
  * DistUpgrade/ReleaseAnnouncement:
    - add "LTS" to the version
 -- Michael Vogt <email address hidden> Wed, 20 Jun 2012 19:52:49 +0200