Closed Bug 1213331 Opened 9 years ago Closed 9 years ago

isOSUpdate="true" needs to be added to the wiki docs for FOTA

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

Product:
Firefox OS Graveyard
Component:
GonkIntegration
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: nhirata, Unassigned)

References

Details

(Keywords: qablocker)

Attachments

(8 files)

log.txt
70.39 KB, text/plain
Details
recovery_logs.zip
11.68 KB, application/zip
Details
logcat_10092015.zip
49.76 KB, application/zip
Details
update.xml
458 bytes, text/xml
Details
IMG_0012.jpg
4.82 MB, image/jpeg
Details
IMG_0014.jpg
351.69 KB, image/jpeg
Details
build.prop
5.09 KB, text/plain
Details
update_b.xml
603 bytes, text/xml
Details 
1. flash v18D_nightly_v4
2. point update channel to the update.xml that points to a flame FOTA build
3. update

Expected: it boots up
Actual: no boot up; logcat show : 
W/linker  ( 1865): could not load library "/system/b2g/libmozglue.so" from LD_PRELOAD for "getprop"; caused by library "/system/b2g/libmozglue.so" not found
Need to check if the latest nightly shows this issue.  We have to update the base build anyhow due to bluetooth changes, hopefully it has something to do with this...
Still happens on latest flame build. I also built my own build with a ./build.sh gecko-update-fota-full
and ran into the issue.
Also tried with ./build.sh gecko-update-fota and ran into the same issue.
Flags: needinfo?(lissyx+mozillians)
Note: sideloading the update.zip file created in the same package boots up correctly.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #4)
> Note: sideloading the update.zip file created in the same package boots up
> correctly.

It makes no sense, sideloading has no difference regarding that
Flags: needinfo?(lissyx+mozillians)
Attached file log.txt — 
logcat.  there's no recovery log.
Attached file recovery_logs.zip — 
Recovery log of sideloading the update.zip file.

There is no recovery log when trying to update via pointing a xml to the mar file.
Hash verification will fail as expected. Please build with FOTA_FINGERPRINTS=... with the value of the property ro.build.fingerprint of the target build
(In reply to Alexandre LISSY :gerard-majax from comment #9)
> Hash verification will fail as expected. Please build with
> FOTA_FINGERPRINTS=... with the value of the property ro.build.fingerprint of
> the target build

Multiple target fingerprint can be specified as coma-separated value in the environment variable FOTA_FINGERPRINTS.
Attached file logcat_10092015.zip — 
logcat when using the xml file to push an update.
(In reply to Alexandre LISSY :gerard-majax from comment #10)
> (In reply to Alexandre LISSY :gerard-majax from comment #9)
> > Hash verification will fail as expected. Please build with
> > FOTA_FINGERPRINTS=... with the value of the property ro.build.fingerprint of
> > the target build
> 
> Multiple target fingerprint can be specified as coma-separated value in the
> environment variable FOTA_FINGERPRINTS.

https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_update_packages#Generating_a_partial_Gecko.2FGaia_FOTA_update_MAR
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #12)
> Created attachment 8672149 [details]
> update.xml

That lacks at least | isOSUpdate="true" | as an attribute of the |update| node. Without that, then the update will not be applied as a recovery one.

Generating update.xml with:
> ANDROID_TOOLCHAIN=[...]/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7/bin/ ./tools/update-tools/build-update-xml.py out/target/product/flame/fota-flame-update.mar

should produce something valid
Attached image IMG_0012.jpg — 
With the XML change, the device enters recovery mode and errors out in an assert failure of the sha1_check failing.

The update.zip file is located in the sdcard0 directory.  This is from the nightly_v4; I think the nightly_v4 needs to be updated once again in order to update correctly.
Just refreshed this bug and saw comment 9.  going to give that a try.
Attached image IMG_0014.jpg — 
Error with the fingerprint set to qcom/flame/flame:4.4.2/KOT49H/eng.cltbld.20150527.043015:userdebug/test-keys
Attached file build.prop — 
/system/build.prop does exist and here's the file.
I think at this point:
1) I might close this bug out as invalid, 
2) ask for a doc update for https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_update_packages to explicitly call out the xml change for FOTA.
3) split off the fingerprint issue and look at that off in more detail to see what I'm doing wrong.
4) and work on a new flame base build for community that's more recent.
Great, at least that last error with build.prop makes sense, is in recovery and is something I already had in the past :)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #19)
> I think at this point:
> 1) I might close this bug out as invalid, 

I don't think you should, that bug shows that we still have some documentation lacking at least, otherwise you would not have been caught by this.

> 2) ask for a doc update for
> https://developer.mozilla.org/en-US/Firefox_OS/
> Building_and_installing_Firefox_OS/Firefox_OS_update_packages to explicitly
> call out the xml change for FOTA.
> 3) split off the fingerprint issue and look at that off in more detail to
> see what I'm doing wrong.

You're not doing anything wrong, it seems that some device do force mount /system and some do not. Just adding a mount before checking for the fingerprint fixes the issue for me!

I am going to fix that in another bug and we will keep that one for documentation and tracking.
Depends on: 1213538
So, I have followed those steps:
 - applying bug 1213538
 - reflashed my Flame device with v18D_v4
 - producing a FOTA: FOTA_FINGERPRINTS="qcom/flame/flame:4.4.2/KOT49H/eng.cltbld.20150527.043015:userdebug/test-keys" ./build.sh gecko-update-fota
 - applied the FOTA with the test-update.py script, to avoid messing around bad XML file

The result is a device upgraded as expected. Sorry for those two issues delaying :(

It means we will have to add the FOTA_FINGERPRINTS env var into both Buildbot and TaskCluster configs.
Flags: needinfo?(nhirata.bugzilla)
Depends on: 1213824
bug 1213944 is created for the buildbot solution.
Attached file update_b.xml — 
I created an xml file to point to this taskcluster build and that seemed to work well.

Serial: e481d8da (State: device)
Build ID               20151012134109
Gaia Revision          74b0d4b17f39d238a7997800bd9363d3c60f20c3
Gaia Date              2015-10-09 19:27:39
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/22972293353f04e58068110aad8a240ae9834322
Gecko Version          44.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150527.043015
Firmware Date          Wed May 27 04:30:24 EDT 2015
Bootloader             L1TC000118D0

Gonk did not change, the gaia/gecko did.  Doing further testing to see what happens with newer builds.
Side note: Update URL changed back.  Channel also changed.  Not sure what other settings might be reset from this.  I'll have to do profile FOTA testing as well following the new build testing.
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #26)
> Side note: Update URL changed back.  Channel also changed.  Not sure what
> other settings might be reset from this.  I'll have to do profile FOTA
> testing as well following the new build testing.

That is probably the fix we landed in bug 1206741 ?
Chris, can we have an update on the XML portion of update; isOSUpdate="true" has to be in the update.xml file in order to do a FOTA.  Using the tool to create the xml will generate this, having said that, the portion is not explicitly mentioned in the documentation(s):

* https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_update_packages#Hosting_updates_and_polling_for_updates_on_the_client_side

* https://wiki.mozilla.org/Software_Update:updates.xml_Format

[Note: that this comment and comment 14 are probably the only comments you need to look at in this bug; I can create a separate bug if you prefer to update the docs]
Flags: needinfo?(cmills)
ok, good to know about the update url.  I am still going to test a few other preferences to make sure that didn't get affected.

In terms of the testing, I took the full build of 2015-10-11-15-02-08 (from pvtbuild server) and fullflashed that, and then tried FOTAing, and it came out with an error in the signature.

I also tried with a v4 base build, with an OTA and then a FOTA.  This worked, I guess the signature wasn't overwritten in this instance.  So as long as the base build is set.

I think I do need to update the base build due to bluetooth.  How can we cleanly keep the signature key up to date?  I guess I would have to file a bug to update the signature key any time we have T2M host a new build.  Unless someone can think of any better method?
Testing Update: No other preference or data seemed to be touched in an unexpected way from what I can tell, going from update to update.

I think the question of fingerprints + some backend releng work remains in order to get flame FOTA (gecko/gaia updates) out to contributors
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #28)
> Chris, can we have an update on the XML portion of update; isOSUpdate="true"
> has to be in the update.xml file in order to do a FOTA.  Using the tool to
> create the xml will generate this, having said that, the portion is not
> explicitly mentioned in the documentation(s):
> 
> *
> https://developer.mozilla.org/en-US/Firefox_OS/
> Building_and_installing_Firefox_OS/
> Firefox_OS_update_packages#Hosting_updates_and_polling_for_updates_on_the_cli
> ent_side
> 
> * https://wiki.mozilla.org/Software_Update:updates.xml_Format
> 
> [Note: that this comment and comment 14 are probably the only comments you
> need to look at in this bug; I can create a separate bug if you prefer to
> update the docs]

I've updated both pages that you cite with some information about isOSUpdate. Can you check it and let me know if this is sufficient? Thanks!
Flags: needinfo?(cmills)
Thanks Chris;

1) I think a notice that 1.8 is mentioned on https://wiki.mozilla.org/Software_Update:updates.xml_Format; is it ok if we change that to 2.5?

2) on 
https://developer.mozilla.org/en-US/Firefox_OS/Building_and_installing_Firefox_OS/Firefox_OS_update_packages#Hosting_updates_and_polling_for_updates_on_the_client_side, I made an update to note that isOSUpdate=true is needed for FOTA, but not OTA.


(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #31)
> I've updated both pages that you cite with some information about
> isOSUpdate. Can you check it and let me know if this is sufficient? Thanks!
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(cmills)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #32)
> Thanks Chris;
> 
> 1) I think a notice that 1.8 is mentioned on
> https://wiki.mozilla.org/Software_Update:updates.xml_Format; is it ok if we
> change that to 2.5?

Do you mean you want to change the "New for MOZILLA_1_8_BRANCH" instances to "New for MOZILLA_2_5_BRANCH" or somesuchthing? It seems to me that these are notices saying that things were first introduced in that branch. Do we want to change them? FWIW, this isn't really a page under my control.

> 2) on 
> https://developer.mozilla.org/en-US/Firefox_OS/
> Building_and_installing_Firefox_OS/
> Firefox_OS_update_packages#Hosting_updates_and_polling_for_updates_on_the_cli
> ent_side, I made an update to note that isOSUpdate=true is needed for FOTA,
> but not OTA.

Cool, thanks - I've given it a small, edit, but looks great.
Flags: needinfo?(cmills) → needinfo?(nhirata.bugzilla)
(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #33)
> (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from
> comment #32)
> > Thanks Chris;
> > 
> > 1) I think a notice that 1.8 is mentioned on
> > https://wiki.mozilla.org/Software_Update:updates.xml_Format; is it ok if we
> > change that to 2.5?
> 
> Do you mean you want to change the "New for MOZILLA_1_8_BRANCH" instances to
> "New for MOZILLA_2_5_BRANCH" or somesuchthing? It seems to me that these are
> notices saying that things were first introduced in that branch. Do we want
> to change them? FWIW, this isn't really a page under my control.

Ya, I guess you have two points there.  I could just change it if it really bothers me, and it's just a note saying any new branch.  Ok, I'll just leave it as is.  Thanks for the doc changes!

> > 2) on 
> > https://developer.mozilla.org/en-US/Firefox_OS/
> > Building_and_installing_Firefox_OS/
> > Firefox_OS_update_packages#Hosting_updates_and_polling_for_updates_on_the_cli
> > ent_side, I made an update to note that isOSUpdate=true is needed for FOTA,
> > but not OTA.
> 
> Cool, thanks - I've given it a small, edit, but looks great.

Ok thanks!
Flags: needinfo?(nhirata.bugzilla)
To followup on comment 19, 
1/2) doc was changed and updated so I'm closing this bug off as a doc fix
3) fingerprint issue is being looked at in a different set of bugs.
4) the device update for flame is being looked at in a different bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Summary: Flame does not start up after FOTA (gecko/gaia) → isOSUpdate="true" needs to be added to the wiki docs for FOTA
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: