1095380 - Unable to apply FOTA on v188

Status: RESOLVED INVALID

(Firefox OS Graveyard :: GonkIntegration, defect)

Description

[:gerard-majax]

STRs:
 0. Flash v188
 1. Do your own build, and flash. (boot.img, userdata.img, system.img)
 2. Build Gecko/Gaia MAR:
$ ./build.sh gecko-update-fota
 3. Apply:
$ python tools/update-tools/test-update.py
out/target/product/flame/fota-flame-update.mar
 4. Gecko will reboot, detect an OTA. Apply.

Expected:
 It reboots in recovery mode and applies update.

Actual:
 It reboots in recovery mode and fails to apply the update.

My device only has the internal sdcard.

Comment 1

[:gerard-majax]

Attachment: IMG_0142.jpg

Comment 2

[:gerard-majax]

Attachment: recovery.log

Comment 3

[:gerard-majax]

> $ adb shell ls -al /storage/sdcard0/updates/fota/update.zip
> -rwxrwxr-x root     sdcard_rw 62957810 2014-11-07 09:40 update.zip

Any idea why we send a /storage/sdcard1/ when triggering the recovery mode ?

Comment 4

[:gerard-majax]

I suspect this is coming from librecovery ...

Comment 5

[:gerard-majax]

Forcing librecovery to use /storage/sdcard0/ I'm blocked because v188 has not the proper keys.

Comment 6

[Dave Hylands [:dhylands]]

Yeah - librecovery does the mapping to the path used.

So it may depend on whether you're using the librecovery that comes with the base image, or the one which we build.

The one we build is only flashed if you do a full flash. If you do a shallow flash (or just OTA updates), the I don't think that librecovery is changed.

Comment 7

[Gabriele Svelto [:gsvelto]]

The /storage/sdcard1 mount point comes from the BoardConfig.mk file, see here:

https://github.com/mozilla-b2g/device-flame/blob/3e9d023ceead45b4abab535cf26243e640bfcda8/BoardConfig.mk#L17

It's picked up here:

https://github.com/mozilla-b2g/librecovery/blob/acd2abcd2114710e9bd87453218eba6ddcb0a314/librecovery.c#L158

Maybe I'm confused, but hadn't we discussed already of using our own recovery image wherever possible? I'm horribly short on sleep today so my memory is not at its best. Still, we can flash our self-built recovery image via fastboot like we did on the Hamachi and move forward from there, right?

Comment 8

[:gerard-majax]

(In reply to Gabriele Svelto [:gsvelto] from comment #7)
> The /storage/sdcard1 mount point comes from the BoardConfig.mk file, see
> here:
> 
> https://github.com/mozilla-b2g/device-flame/blob/
> 3e9d023ceead45b4abab535cf26243e640bfcda8/BoardConfig.mk#L17
> 
> It's picked up here:
> 
> https://github.com/mozilla-b2g/librecovery/blob/
> acd2abcd2114710e9bd87453218eba6ddcb0a314/librecovery.c#L158

Yep, but this means that we expect to use the *external* sdcard, which is optionnal. Is this really what we want ?

> 
> Maybe I'm confused, but hadn't we discussed already of using our own
> recovery image wherever possible? I'm horribly short on sleep today so my
> memory is not at its best. Still, we can flash our self-built recovery image
> via fastboot like we did on the Hamachi and move forward from there, right?

We cannot: see bug 1067005, when we build ourselves on KK it does not boots properly.
So yes, we should be able to use our own recovery, but for now it does not work, and nobody seems to be working on this for now.

Comment 9

[Gabriele Svelto [:gsvelto]]

(In reply to Alexandre LISSY :gerard-majax from comment #8)
> Yep, but this means that we expect to use the *external* sdcard, which is
> optionnal. Is this really what we want ?

We've seen FOTA being used to flash images from the SD-card so it's probably a reasonable default (i.e. you don't need adb access to upload the FOTA image, you load it on the card from another machine/device). It's inconvenient for the use-case where you download the image since then you'd need an SD-card in order to upgrade.

> We cannot: see bug 1067005, when we build ourselves on KK it does not boots
> properly.
> So yes, we should be able to use our own recovery, but for now it does not
> work, and nobody seems to be working on this for now.

We can't really do much then without help from the vendor :-( Who's in charge of keeping us in touch with T2M?

Comment 10

[Wesly Huang (EPM)]

Hi Alexandre, and Gabriele:

Sorry for catching up late, would you help me understand more about the need for Flame's vendor (T2M)? My last update is like mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1084041#c14, that T2M has provided some suggestion for the "can't mount SD card" issue w/ our own build.

Comment 11

[:gerard-majax]

(In reply to Wesly Huang from comment #10)
> Hi Alexandre, and Gabriele:
> 
> Sorry for catching up late, would you help me understand more about the need
> for Flame's vendor (T2M)? My last update is like mentioned in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1084041#c14, that T2M has
> provided some suggestion for the "can't mount SD card" issue w/ our own
> build.

We need to fix building a working recovery ourselves.

Comment 12

[Gabriele Svelto [:gsvelto]]

As Alexandre said the current recovery partition doesn't fit the bill and we have to build one ourselves instead.

Comment 13

[Wesly Huang (EPM)]

Thanks Alexandre, and Gabriele, then please let me know if any support needed from vendor then I will follow.

Comment 14

[:gerard-majax]

(In reply to Wesly Huang from comment #13)
> Thanks Alexandre, and Gabriele, then please let me know if any support
> needed from vendor then I will follow.

It's probably viral that you should ask for what he needs from vendor. I hacked recovery in the JB days, but I don't have time right now to hack it.

Comment 15

[viral [:viralwang]]

I think this question is same as https://bugzilla.mozilla.org/show_bug.cgi?id=1067005#c11
remove ni here and keep the ni in bug 1067005.

So far I still can not build our own recovery image with latest code. (it works in preview version)
Need some feedback from partner.

Comment 16

[Wesly Huang (EPM)]

clear my ni as this is followed by bug 1067005 which is fixed now.