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

[Gema Gomez]

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

[Pete Graner (pgraner)]

This is blocking daily iso smoke testing, marking as critical

[Colin Watson (cjwatson)]

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.

[Colin Watson (cjwatson)]

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

[Colin Watson (cjwatson)]

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)]

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

[Colin Watson (cjwatson)]

The desynchronisation is happening in install_language_packs.

[Launchpad Janitor (janitor)]

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