Debconf prompt on upgrade from quantal to raring

Bug #1105137 reported by Steve Magoun on 2013-01-25
This bug affects 3 people
Affects Status Importance Assigned to Milestone
eglibc (Ubuntu)

Bug Description

I used update manager to upgrade from Quantal to Raring during the raring development cycle. I was prompted - twice - with a debconf dialog asking about services to restart for the libc upgrade. Most end users will have no idea what to do; the prompt should be preseeded or otherwise hidden. Clicking the forward button on the dialog resulted in the same dialog popping up a second time. After I clicked forward again, the dialog went away for good.

See attached screenshot for the dialog in question.

Steve Magoun (smagoun) wrote :
description: updated
Adam Conrad (adconrad) wrote :

How was the upgrade performed? update-manager, do-release-upgrade, apt-get? In theory, we're supposed to skip past asking hard questions in a "desktop" upgrade scenario, but we may have missed a corner case.

Adam Conrad (adconrad) wrote :

Oh, hrm. You said update-manager above, I can't read. I'll have to try to reproduce this with an upgrade test and see if maybe we've accidentally regressed the "desktop upgrade" magic.

Launchpad Janitor (janitor) wrote :

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

Changed in eglibc (Ubuntu):
status: New → Confirmed

I've just reproduced this doing upgrade testing in a VM. I started with a clean 12.10 desktop install fully updated. I then upgraded to raring with 'update-manager -d -c'

During the upgrade I get a debconf prompt asking to restart rsync, cups, cron, and atd.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Brian Murray (brian-murray) wrote :

I was able to recreate and research this a bit during an upgrade from Q to R. I received the debconf prompt regarding rsync, cups, cron and atd. The preinst script for libc checks to see whether or not $RELEASE_UPGRADE_MODE = desktop. This evironmental variable is set by ubuntu-release-upgrader in DistUpgradeController. Additionally, the result of this check is logged in /var/log/dist-upgrade/main.log as "run in 'desktop' mode" or "running in server mode".

Inspecting the running process at the time of the distribution upgrade I found RELEASE_UPGRADE_MODE set to desktop for a dpkg process, a perl / debconf process, and a dpkg preinst. Its not quite clear where the problem lies but it doesn't look like it is an issue with ubuntu-release-upgrader.

Changed in eglibc (Ubuntu):
importance: Undecided → Medium
tags: added: rls-s-incoming
Brian Murray (brian-murray) wrote :

I tried recreating this during an upgrade from Ubuntu 12.10 to Ubuntu 13.04, on 2013-08-12 and was unsuccessful, so I am removing the rls-s-incoming tag.

tags: removed: rls-s-incoming
Brian Murray (brian-murray) wrote :

This is also happening when upgrading from Precise to Trusty.

Michael Vogt (mvo) wrote :

This appears to be a regression in the eglibc6 preinst script, see

Brian Murray (brian-murray) wrote :

This didn't get auto-fixed because the task is about ubuntu-release-upgrader.

eglibc (2.19-0ubuntu4) trusty; urgency=low

  * debian/
    - do not show glibc/restart-services question when the system
      is uprading via the desktop session (LP: #1298281)
 -- Michael Vogt <email address hidden>

Changed in eglibc (Ubuntu):
status: Confirmed → Fix Released
rsbrux (rsbrux) wrote :

Still happening (or happening again) on upgrade to xenial (16.04 LTS).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers