Upgrade to cups-bsd_1.4.3-1ubuntu1.2 hangs during preseeded install

Bug #605149 reported by Todd Taft
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cups (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: cups

When my system runs aptitude -y full-upgrade during an preseeded (automated) install, the upgrade to the cups-bsd package hangs the upgrade. The system is installing the 64-bit version of 10.04.

The aptitude upgrade is run from a script called by the late_command string in the preseed file (d-i preseed/late_command)

The last message in the install log before the hang is:
Preparing to replace cups-bsd 1.4.3-1 (using .../cups-bsd_1.4.3-1ubuntu1.2_amd64.deb)

If I do a ps, I get the following processes (not counting the aptitude/dpkg commands) related to the cups upgrade:
/bin/sh /var/lib/dpkg/info/cups-bsd.prerm upgrade 1.4.3-1ubuntu1.2
/usr/bin/perl -w /usr/share/debconf/frontentd /usr/sbin/update-inetd --pattern cups-lpd --disable printer

If I kill the second process (it's a child of the first), then things continue on.

Running this command on a live (normal booted) system works, as does running this upgrade from a live system.

Revision history for this message
Max Bowsher (maxb) wrote :

Confirmed exact same symptoms attempting the same sort of preseed upgrade during an install of Ubuntu 10.10

Changed in cups (Ubuntu):
status: New → Confirmed
Revision history for this message
Max Bowsher (maxb) wrote :

I have not figured out why it was hanging, but I have discovered that wrapping the call in debconf-apt-progress not only presents a proper progress bar, but also somehow avoids the hang.

So, my full late_command is:

d-i preseed/late_command string in-target sh -c "debconf-apt-progress --logstderr -- aptitude -q --without-recommends -y -o DPkg::options=--force-confnew full-upgrade"

(The options that I'm using are there because I copied them from the pkgsel code handling the pkgsel/upgrade step.)

Revision history for this message
Till Kamppeter (till-kamppeter) wrote :

The hanging process is part of debconf, seems to be a debconf bug. Moving to debconf ...

affects: cups (Ubuntu) → debconf (Ubuntu)
Revision history for this message
Colin Watson (cjwatson) wrote :

We probably need a trace with DEBCONF_DEBUG=developer set in the environment in order to do anything about this. (And usually this kind of thing is a package bug anyway.)

Changed in debconf (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Colin Watson (cjwatson) wrote :

Actually, this rings a bell and I know what the problem is. cups-bsd.prerm executes update-inetd, which uses debconf. Normally, you can use debconf in child processes without a problem. However, because of some odd bits in the way the debconf shell and Perl bindings work together, if cups-bsd.prerm is being run from within something that uses debconf (debconf-apt-progress, in this case), IIRC the only way update-inetd is going to work properly is if cups-bsd.prerm sources the debconf confmodule; otherwise it will send debconf commands to the wrong place. I know this is a bit weird since cups-bsd.prerm doesn't itself use debconf directly.

In short, I think this will go away if you ensure that cups-bsd.prerm does '. /usr/share/debconf/confmodule' at the very top, immediately below 'set -e'. You'll need to test that, though.

affects: debconf (Ubuntu) → cups (Ubuntu)
Changed in cups (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Max Bowsher (maxb) wrote :

Actually, the problem does not occur when debconf-apt-progress is involved.

The hang occurs if aptitude is invoked directly from preseed/late_command. Wrapping the aptitude call in debconf-apt-progress seems to somehow perturb the debconf communications sufficiently that it does not hang.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.