[Bug 1233521] Re: system-image cannot recover from a partial download without rebooting

[Launchpad Bug Tracker]

This bug was fixed in the package system-image - 1.9.1-0ubuntu1

---------------
system-image (1.9.1-0ubuntu1) saucy; urgency=low

  * New upstream release:
    - LP: #1240105 - Further refinement of permission checking/fixing.
    - LP: #1240106 - Work around some failures in DEP 8 tests.
  * d/control: Point Vcs-Bzr and Vcs-Browser to the packaging branch.
  * d/system-image-common.dirs: Add /var/log/system-image.
  * d/rules, d/tests/unittests: Set $SYSTEMIMAGE_REACTOR_TIMEOUT to 1200
    seconds to avoid random timeout errors.
  * d/system-image-common.postinst, system-image-common.postrm: debhelper
    scripts for ensuring the proper permissions and for purging directories.
 -- Barry Warsaw <barry at ubuntu.com>   Tue, 15 Oct 2013 11:23:54 -0400

** Changed in: system-image (Ubuntu Saucy)
       Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to system-image in Ubuntu.
https://bugs.launchpad.net/bugs/1233521

Title:
  system-image cannot recover from a partial download without rebooting

Status in Ubuntu system image (server/client/updater):
  Fix Released
Status in “system-image” package in Ubuntu:
  Fix Released
Status in “system-image” source package in Saucy:
  Fix Released

Bug description:
  In response to bug #1228254, u-d-m now throws a dbus error if it's
  asked in unconfined mode for a file that already exists.  This
  combines with system-image behavior to make it impossible to recover
  from a failed download without rebooting the device. I think system-
  image needs to check for already-downloaded files on the system in the
  expected path, and either remove them unconditionally for redownload,
  or spot-verify their sums and omit any correctly-downloaded files from
  the request to u-d-m.

  Relatedly, system-image needs to stop using a well-known path under
  /tmp for these files.  This needs to move to a root-only directory
  instead.  (While s-i could use proper tmpdir handling to create a
  private directory under /tmp without risking a DoS or symlink attack,
  this would have undesirable semantics wrt retries, because subsequent
  s-i processes would necessarily be asking u-d-m to download files to
  different directories each time.)  From an FHS standpoint, I think the
  correct location for these downloads is /var/cache/system-image.  That
  would need to be coordinated with lxc-android-config to get this
  directory made writable.  Alternatively, the files should just be
  downloaded directly to /android/cache/recovery (under an appropriate
  tmp/"in-progress" directory name), which would save having to do a
  cross-filesystem copy after download.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-system-image/+bug/1233521/+subscriptions