ubuntu-phone team mailing list archive

[Gran PC <gran.pc@xxxxxxxxx>]

The OTA updates are deltas unless you skip one, in which case it downloads
the entire filesystem.

On Thu, Aug 27, 2015 at 1:17 PM Thomas A. Moulton <tom@xxxxxxxxxx> wrote:

> From watching the various updates my Tablet (flo) has received, aren't
> the OTA updates deltas? If so, then would it be expected to have >500MB
> of changes between updates often? In the most recent update I think I
> saw about 148MB downloaded.
>
> Could this be a temporary problem, because aren't  we going to migrate
> to a Snappy based system at some point? Then with the System-ab
> partitions some of the rules may change, such as writing updates to
> System-B while we're running in A, not requiring a single download to
> have everything.
>
> TOTAL Speculation on my part...
>
> I am also not sure of the sequence of events of Snappy and Convegence.
>
> Tom
>
> On 08/27/2015 06:14 AM, John McAleely wrote:
> > As we begin to prepare for new features associated with converged
> > devices, it seems likely that some image configurations will be *much*
> > larger than our current phone images on system-image.ubuntu.com
> > <http://system-image.ubuntu.com>
> >
> > As an example, I've been anecdotally informed that if an OEM wanted to
> > bundle libreoffice (a likely scenario) that may add around 500M to the
> > image size.
> >
> > Currently, we download images three ways:
> >
> >  - Via system updates to the phone, where the download is pulled to the
> > cache partition
> >  - Via a host desktop and then via ubuntu-device-flash to the phone.
> > Again, this writes the (compressed) images to the cache partition as a
> > staging step
> >  - Via various factory flashing tools, which simply write whole
> > partitions as-is (similar to how dd might work)
> >
> > Typically, the cache partition on android devices seems to be in the
> > range 500-700M, and it it certain that some desirable converged device
> > configurations will have images that (in compressed form) are much
> > larger than this. The first two flashing methods will clearly break.
> >
> > A simple solution to this problem is to increase the size of the cache
> > partition on devices where large applications might be installed. Fine
> > for those devices where we control the partition table, but impossible
> > on those devices where we co-exist with android and don't change that
> table.
> >
> > Those devices where the partition table can't be modified includes Mako,
> > Flo, etc.
> >
> > For those devices, we clearly need to make changes to how images can be
> > downloaded, if we wish to support these devices for convergence images.
> >
> > One choice would simply be to reserve a sufficiently large amount of
> > space in the userdata area of the android partition table, and ask our
> > image flashing tools to use that. We would then ignore the cache
> > partition entirely for the flashing process on these phones.
> >
> > Is it just the download/updater (including recovery) that is impacted,
> > or are other actors involved in preparing system updates?
> >
> > J
> >
> >
> >
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>