[omap4] Package installation completely fails silently if no network is available

Bug #985280 reported by Michael Casadevall
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
livecd-rootfs (Ubuntu)
Fix Released
High
Unassigned

Bug Description

If networking is not present on the server omap4 image, package installation will silently fail to install any packages selected for tasksel. The installation will continue without any notification that it has failed, and drop you to a command prompt as per normal installation. However, no selected packages are installed and there is no notification that anything is out of the ordinary. This is a release-critical bug as both offline installation must be supported, and silent failure is not acceptable.

There is no relevant information in any log files created by oem-config.

Steps to reproduce:
1. Run through the installation with no ethernet cord
2. Select various tasks to install
3. Complete installation

Expected outcome:
1. Selected packages should be installed, or at the very least fail with notification.

Tags: iso-testing
Changed in ubiquity (Ubuntu):
importance: Undecided → High
milestone: none → ubuntu-12.04
Revision history for this message
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:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/985280

tags: added: iso-testing
affects: ubiquity (Ubuntu) → oem-config (Ubuntu)
affects: oem-config (Ubuntu) → ubiquity (Ubuntu)
Revision history for this message
Adam Conrad (adconrad) wrote :

FWIW, running tasksel manually and picking a task it can't install leads to it exiting with the following error:

tasksel: aptitude failed (100)

So, it may well be that oem-config is cleverly eating that error and just moving on with life.

Revision history for this message
Adam Conrad (adconrad) wrote :

So, if I change the way we provide our initial Packages cache on the server image only to behave more d-i-like (ie: to only have the local pool represented until first networked apt-get update), this would solve this, as well as the "too many tasks" bug.

Both of these options rely on my first getting task info on the image, but that actually doesn't look like as much effort as it did when I first tried.

affects: ubiquity (Ubuntu) → livecd-rootfs (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package livecd-rootfs - 2.65

---------------
livecd-rootfs (2.65) precise; urgency=low

  * Add (extra-)override parsing to the preinstalled pool to make sure
    we get task headers in the local pool for tasksel (LP: #819899)
  * Move temp directories under config so they get cleaned properly
  * Invoke apt-get update once with only the sources.list fragment
    for the local archive, so our package/task selection more closely
    mimics the CD experience (LP: #985258, #985737, #985280, #819900)
  * Write out a standard sources.list entry for preinstalled systems
    that's similar to the one generated by installers (LP: #985291)
 -- Adam Conrad <email address hidden> Fri, 20 Apr 2012 00:29:38 -0600

Changed in livecd-rootfs (Ubuntu):
status: New → Fix Released
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.