1021807 - Latest nightly and tinderbox builds too large to flash on Hamachi

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect, P1)

Description

[Dave Hunt [:davehunt] [he/him] ⌚BST]

It appears we're unable to flash mozilla-central builds to Hamachi's again.

Last good:
application_buildid: 20140605183157
application_changeset: c08a299f2163
build_changeset: 2a165bebfa19b11b697837409f9550dd2917c46c
gaia_changeset: 908f94fda04462001ece86e6b6c15ad8b05f7526

This has happened a number of times now. Can we somehow pick this up when we build, so that we don't have such downtime in test automation?

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

The last good build had the following free space after flashing:

Filesystem             Size   Used   Free   Blksize
/dev                    90M    48K    90M   4096
/mnt/asec               90M     0K    90M   4096
/mnt/obb                90M     0K    90M   4096
/system                200M   198M     1M   4096
/data                  161M     1M   159M   4096
/persist                 4M   908K     3M   4096
/cache                  40M     1M    38M   4096

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Dave Hunt (:davehunt) from comment #0)

> This has happened a number of times now. Can we somehow pick this up when we
> build, so that we don't have such downtime in test automation?

Yes, bug 1020050 is meant to address just that.

Comment 3

[Pi Wei Cheng [:piwei] (inactive)]

b2g-inbound Regression Window:

Last Working Environmental Variables:
Device: Buri
Build ID: 20140604233716
Gaia: a24a43bd0124f5ba49833aa30a44424dd18cef38
Gecko: 37a23a635be0
Version: 32.0a1
Firmware Version: v1.2device.cfg

First Broken Environmental Variables:
Device: Buri
BuildID: 20140605000718
Gaia: ad3fd209ffed635bdc650e400687514258e3860e
Gecko: 8fbf24c24b71
Version:  32.0a1
Firmware Version: v1.2device.cfg

Last Working Gaia / First Broken Gecko: Issue Does NOT reproduce. Build successfully flashes to device.
Gaia: a24a43bd0124f5ba49833aa30a44424dd18cef38
Gecko: 8fbf24c24b71

Last Working Gecko / First Broken Gaia: Issue DOES reproduce. Build fails to flash to device.
Gaia: ad3fd209ffed635bdc650e400687514258e3860e
Gecko: 37a23a635be0

Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/a24a43bd0124f5ba49833aa30a44424dd18cef38...ad3fd209ffed635bdc650e400687514258e3860e

Comment 4

[Jason Smith [:jsmith]]

Caused by 4 different bugs.

Comment 5

[Jason Smith [:jsmith]]

I need a backout of all 4 patches linked here.

Comment 6

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Hey all,
I think that the big problems are the images in `apps/collection/collections/` so ... if we need to backout the patches I think we need to backout only Bug 1020134 the others are only few small images. Patryk?

Comment 7

[Jason Smith [:jsmith]]

(In reply to Pavel Ivanov [:ivanovpavel] from comment #6)
> Hey all,
> I think that the big problems are the images in
> `apps/collection/collections/` so ... if we need to backout the patches I
> think we need to backout only Bug 1020134 the others are only few small
> images. Patryk?

Okay, sounds good.

Comment 8

[Patryk Adamczyk [:patryk] UX]

Let me know what I can do... we can "compress" certain assets further if needed. But I also want to make sure we are only including graphics needed for the image... ie. We are NOT including @1.5x graphics / wallpapers in the Hamachi image correct?

Comment 9

[Pavel Ivanov [:ivanovpavel][:pivanov] UX]

Yep, I think that we don't include the @1.5x images however, the image is big ... and maybe this is because we have a lot of new wallpapers there ... I think they are few megabytes ... not sure what we can do ... maybe Vivien can help us here?

Comment 10

[Walter Chen[:ypwalter][:wachen]]

Again???

Comment 11

[Hubert Figuiere [:hub]]

Also why did the auto_flash_from_pvt allowed to flash this?

Comment 12

[Kevin Grandon :kgrandon]

Can we flash a production build, or are they totally hosed also? It seems like instead of backing patches out we may instead want to make a more simple customization for hamachis with less assets (maybe no wallpapers), and maybe even less apps.

Comment 13

[Cristian Rodriguez (:crdlc)]

Backout of bug 1020134

https://github.com/crdlc/gaia/commit/ad83bab6e5fd681548e3915a41dff4f8378a7793

I think we need to implement some code in build time to copy only the specific wallpapers for a target device instead of all of them. Maybe this can be done here bug 1020152

Albert, could we copy only the collection folders that are pre-installed by OEMs? and also within those folders the specific wallpaper for the target device?

Thanks Albert

Comment 14

[Jason Smith [:jsmith]]

Closing as fixed via backout. If the backout in comment 13 isn't enough to resolve the problem, then please reopen.

We should file a followup though for what Kevin & Cristian is describing above to ensure that Hamachi's eng build size drops down significantly.

Comment 15

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Pavel Ivanov [:ivanovpavel] from comment #9)
> Yep, I think that we don't include the @1.5x images however, the image is
> big ... and maybe this is because we have a lot of new wallpapers there ...
> I think they are few megabytes ... not sure what we can do ... maybe Vivien
> can help us here?

In order to help I need to understand what is the total size of the 70 new wallpapers that we are trying to add to the build.

Also is it a |PRODUCTION=1| build or a eng build ? (there are more apps installed in the later case).

And what is the size of the profile/ generated for the hamachi build with / without the wallpapers.

If the difference is small we can probably found some spaces somewhere. If the difference is big, we need to do more drastic changes :/