SRT: 1. Download latest master build 2. run flash.sh Expected: 2. the phone is flashed and boots up Actual: 2. we and up on a black screen: flash.sh output: < waiting for device > erasing 'cache'... OKAY [ 0.033s] finished. total time: 0.033s erasing 'userdata'... OKAY [ 0.007s] finished. total time: 0.008s sending 'userdata' (41796 KB)... OKAY [ 3.561s] writing 'userdata'... OKAY [ 7.737s] finished. total time: 11.298s sending 'boot' (8420 KB)... OKAY [ 0.717s] writing 'boot'... OKAY [ 1.577s] finished. total time: 2.294s sending 'system' (190005 KB)... OKAY [ 16.086s] writing 'system'... FAILED (status read failed (No such device)) finished. total time: 21.288s adb devices List of devices attached 0123456789ABCDEF device adb logcat - exec '/system/bin/sh' failed: Not a directory (20) -

making this a blocker as we can't use the phone with this build

Can you provide a link to the engineering build you flashed specifically?

v1-train/b2g-18 nightly build is OK.

I downloaded the build from: https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-central-unagi-eng/latest/unagi.zip

Until we have enough Hamachis (which we don't; on order) and the accompanying builds (bug 912617), we're "stuck" with a lot of Unagis -- :mwu, can you take a look at this? Perhaps it was a bad checkin, and will be fixed by tomorrow's build. /me hopes.

Spoke with :mwu in IRC today, and he doesn't have access to an Unagi -- Hema, who's best to pick up this critical work? Thanks!

I took a look at this, and it seems to be caused by the system image getting too big. From my own build tree (updated today), the system.img file is 171M (VARIANT=userdebug, DEBUG build). I was able to flash the 2013-09-11-04-02-01 image (size = 184 Mb) When I tried the 2013-09-13-04-02-01 imsage (size = 186 Mb) then it failed. Since this is failing during the flash, it's purely a size issue. The most likely solution is to remove some languages. The FTU shows 20 languages.

Talked with djf about this - he's the person who could look into something like this. This is also related to problem we see in bug 907444. He also mentions we need bug 884752 to solve this, so I'm adding it as a dependency.

So the fundamental problem is that the system.img file is too big. The unagi has loads of space on /system but the bootloader seems to only be able to flash images of around 185 Mb. The hamachi has much more limited space in /system, and the images can be flashed, but the OTA updates fail due to running out of space. Both problems can benefit of a smaller system.img The first order reduction is to reduce the number of locales/languages that the image is built with. I think that this is something that releng controls. The second order reduction is to then further reduce the keyboard dictionaries being used.

I sent an email to b2g-release-drivers, we'll see what happens....

It seems that eng builds are the ones that are too big. The only significant difference between eng and user builds are the webapps which are included. eng builds include about 32 Mb of extra webapps. The largest offenders are: uitest - 19.5 Mb cubevid - 8.5 Mb image-uploader - 2 Mb The next largest extra webapp is crystal skull at 344 Kb Just removing cubevid from the eng build would make the unagi build small enough to flash.

Dropping cubevid made my test build system.img drop from 192 Mb to 184 Mb, or a reduction of 8 Mb.

I'm wondering in general if we should just take the test apps out of the Gaia build entirely if it going to help save space. We could easily get them back on device by users by doing: 1. Serving up zip file forms of each test app 2. Allowing them to be downloaded 3. Providing instructions on how to push the test app via the simulator

(In reply to Jason Smith [:jsmith] from comment #13) > I'm wondering in general if we should just take the test apps out of the > Gaia build entirely if it going to help save space. We could easily get them > back on device by users by doing: > > 1. Serving up zip file forms of each test app > 2. Allowing them to be downloaded > 3. Providing instructions on how to push the test app via the simulator Doesn't that pretty much get you to the non eng build? (i.e. userdebug) Normal eng builds put the webapps in /data, so we don't have any issues. I think that you could do a userdebug build and provide a mechanism to install any of the test apps.

:djf and I chatted today, and he said that bug 884752 (and its dependent work) should help with the ability to custom-choose dictionaries (helping with the size issues). It appears that Inari engineering builds on master are now also now affected by this, so I cross-posted to dev.gaia, dev.b2g and gaia-ui-automation, in an attempt to find someone who can help by removing some test apps. I also got approval from Jonas, in lieu of of Vivien, in bug 917144, to remove the set listed there.

Updating summary to indicate that Inari devices are also now affected

Adding bug 884752 since that will be able to contribute to a fairly significant reduction in image size.

This has been resolved and latest master builds are now flashing successfully.

Verified FIXED.

is this really fixed? I have the exact same problem with my ZTE Open – Inari – device: huti-zentrale B2G # ./flash.sh < waiting for device > erasing 'cache'... OKAY [ 0.528s] finished. total time: 0.528s erasing 'userdata'... OKAY [ 1.397s] finished. total time: 1.397s sending 'userdata' (66670 KB)... OKAY [ 5.608s] writing 'userdata'... FAILED (status read failed (No such device)) finished. total time: 10.991s huti-zentrale B2G # adb devices List of devices attached roamer2 device I moved both the uitest and cubevid directories out of the build directory, built the thing but this does not help anything. huti-zentrale B2G # ls -lsah out/target/product/inari/system.img 108M -rw------- 1 root root 108M Okt 16 20:13 out/target/product/inari/system.img

This is definitely fixed and still working well in our CI system. I've clarified the summary with regards to this issue being related to the engineering builds. Are you using one of those? If not, you may be best raising a new issue.

This is currently failing on Inari https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g18-inari-eng/latest/ which are needed for payments testing as we need to be able to test with 1.1. Can those builds be slimmed down too? By all means if there's an alternative build we can use please let me know what that is.

Stephen, do you know who fixed this, and if it's possible to uplift it to b2g18?

(In reply to Dave Hunt (:davehunt) from comment #23) > Stephen, do you know who fixed this, and if it's possible to uplift it to > b2g18? Sorry; I don't know -- besides comment 15, that is.