Flashing Unagi or Inari devices with latest master engineering build fails and we end up with a black screen

VERIFIED FIXED

Status

Firefox OS
GonkIntegration
--
blocker
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: Bebe, Unassigned)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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) -
(Reporter)

Updated

5 years ago
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Summary: Flashing with latest master build fails and we end up with a black screen → Flashing Unagi with latest master build fails and we end up with a black screen
(Reporter)

Comment 1

5 years ago
making this a blocker as we can't use the phone with this build
Severity: normal → blocker
Can you provide a link to the engineering build you flashed specifically?
Blocks: 884399
Keywords: regression

Comment 3

5 years ago
v1-train/b2g-18 nightly build is OK.

Updated

5 years ago
blocking-b2g: --- → koi?
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.
Flags: needinfo?(mwu)
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!
Flags: needinfo?(hkoka)
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.
Depends on: 884752
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
Depends on: 917144
(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.

Updated

5 years ago
Flags: needinfo?(hkoka)

Updated

5 years ago
Flags: needinfo?(mwu)
: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
Summary: Flashing Unagi with latest master build fails and we end up with a black screen → Flashing Unagi or Inari devices with latest master build fails and we end up with a black screen
Whiteboard: [qa-automation-blocked]
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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [qa-automation-blocked]
Verified FIXED.
Status: RESOLVED → VERIFIED

Updated

5 years ago
blocking-b2g: koi? → ---

Comment 20

5 years ago
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.
Summary: Flashing Unagi or Inari devices with latest master build fails and we end up with a black screen → Flashing Unagi or Inari devices with latest master engineering build fails and we end up with a black screen
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.
Flags: needinfo?(dave.hunt)
Stephen, do you know who fixed this, and if it's possible to uplift it to b2g18?
Flags: needinfo?(dave.hunt) → needinfo?(stephen.donner)
(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.
Flags: needinfo?(stephen.donner)
You need to log in before you can comment on or make changes to this bug.