Error on /usr/share/ubiquity/plugininstall.py", line 1687, affecting desktop images (preseeded install)

Bug #1023036 reported by Gema Gomez on 2012-07-10
44
This bug affects 6 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Critical
Colin Watson
Quantal
Critical
Colin Watson

Bug Description

Desktop smoke testing failing on plugininstall.py,

DEBUG:root:Jul 10 11:06:40 ubuntu plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 1687, in <module>
Jul 10 11:06:40 ubuntu plugininstall.py: install.run()
Jul 10 11:06:40 ubuntu plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 56, in wrapper
Jul 10 11:06:40 ubuntu plugininstall.py: func(self)
Jul 10 11:06:40 ubuntu plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 187, in run
Jul 10 11:06:40 ubuntu plugininstall.py: self.configure_hardware()
Jul 10 11:06:40 ubuntu plugininstall.py: File "/usr/share/ubiquity/plugininstall.py", line 830, in configure_hardware
Jul 10 11:06:40 ubuntu plugininstall.py: raise install_misc.InstallStepError("HwDetect failed with code %d" % ret)
Jul 10 11:06:40 ubuntu plugininstall.py: ubiquity.install_misc.InstallStepError: HwDetect failed with code 10
Jul 10 11:06:40 ubuntu plugininstall.py:

When I try to install manually today's desktop am64 image (20120710.1), it freezes on the Choose a Picture screen (not sure if related, but I thought it'd be worth mentioning.

Examples of failing jobs:
https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/63/console
https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO Testing Dashboard/job/quantal-desktop-amd64_encryptedhome/32/console
https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/63/console

Gema Gomez (gema) on 2012-07-10
affects: ubuntu → ubiquity (Ubuntu)
Changed in ubiquity (Ubuntu):
status: New → Confirmed
Pete Graner (pgraner) wrote :

This is blocking daily iso smoke testing, marking as critical

Changed in ubiquity (Ubuntu):
importance: Undecided → Critical
Colin Watson (cjwatson) wrote :

hw-detect is bailing out mysteriously just after a successful db_go call, as far as I can see. Unfortunately my attempts to debug this yesterday were unsuccessful since this seems to be quite racy.

Changed in ubiquity (Ubuntu):
importance: Critical → High
status: Confirmed → Triaged
Colin Watson (cjwatson) wrote :

So far I have reproduced this twice out of something like eight attempts locally ...

Changed in ubiquity (Ubuntu Quantal):
importance: High → Critical
Colin Watson (cjwatson) wrote :

Today's jenkins runs showed that the debconf protocol has got out of sync. In this sequence of commands:

        db_set hw-detect/select_modules "$LIST"
        db_input medium hw-detect/select_modules || true
        db_go || exit 10 # back up

... the db_input is receiving the reply to db_set, and db_go is receiving the reply to db_input. This certainly explains the peculiar bail-out, but it doesn't yet explain why the protocol is out of sync in the first place. I'm uploading 2.11.13 with some more debugging to try to find that out.

Colin Watson (cjwatson) on 2012-07-12
Changed in ubiquity (Ubuntu Quantal):
status: Triaged → In Progress
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson) wrote :

The protocol is out of sync on entry to hw-detect. I'm trying to insert debugging rather earlier.

Colin Watson (cjwatson) wrote :

The desynchronisation is happening in install_language_packs.

Colin Watson (cjwatson) on 2012-07-13
Changed in ubiquity (Ubuntu Quantal):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.11.15

---------------
ubiquity (2.11.15) quantal; urgency=low

  * Drop hw-detect debugging attempts.
  * Terminate status-to-debconf subprocess in DebconfInstallProgress more
    gracefully to avoid desynchronising the debconf protocol if the
    subprocess is killed between sending a command and receiving the
    response (LP: #1023036).
  * Make user-setup-encrypted-swap wait until partitioning has finished
    before attempting to adjust /target/etc/fstab (LP: #1024343).
  * Don't try and fail to set up encrypted swap if no swap partitions are
    configured (LP: #989279).
 -- Colin Watson <email address hidden> Sat, 14 Jul 2012 00:17:31 +0100

Changed in ubiquity (Ubuntu Quantal):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers