Closed Bug 801972 Opened 12 years ago Closed 12 years ago

[OTA update] The same update version is notified and applied after updating

Categories

(Firefox OS Graveyard :: General, defect, P1)

Product:
Firefox OS Graveyard
Component:
General
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

Status:
VERIFIED FIXED
Project Flags:
blocking-basecamp +
Tracking Flags:
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: tchung, Assigned: jgriffin)

Details

(Keywords: unagi, Whiteboard: [ota update][dogfooding-blocker]) 

OTA updates are stuck in a loop, offering me the same update after restarting.   It's not recognizing that i already installed the update already, and offering another update.

Dogfood blocker.

Logcat: 
10-15 18:12:15.439: E/GeckoConsole(1868): AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml?force=1
10-15 18:12:15.439: I/Gecko(1868): *** AUS:SVC Checker:onLoad - number of updates available: 1
10-15 18:12:15.439: E/GeckoConsole(1868): AUS:SVC Checker:onLoad - number of updates available: 1


Repro:
1. load the 10-15-2012 daily Unagi 3 build 
** Gaia: 589c7f8f7df88766f7a5fa944f6bb05eef04b8c3
** gecko: ff73903bf8215b4e06c120ca85210a6b66d42f83
2. Either wait, or do a Settings > Device > Force update check
3. An update is found, apply and restart with the new update
4. After reboot, verify the update notification is present again after applying.  If you apply and restart that update, it will be the same update.

Expected:
- update applied, but if there's no new update, dont notify me.

Actual:
- update keeps getting notified after applying it.  it's the same update.
Summary: [OTA update] Tapping Update now, does not restart and update → [OTA update] The same update version is notified and applied after updating
This usually happens when the update.xml manifest and the gecko versions get out of sync.
The application.ini for this build was:

[App]
Vendor=Mozilla
Name=B2G
Version=18.0a1
BuildID=20121015162538
ID={3c2e2abc-06d4-11e1-ac3b-374f68613e61}

[Gecko]
MinVersion=18.0a2
MaxVersion=18.0a2

[XRE]
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={3c2e2abc-06d4-11e1-ac3b-374f68613e61}&version=18.0a1&buildid=20121015162538

I'm not sure why the app and gecko versions differ.

The update.xml contains version 18.0a2:  http://update.boot2gecko.org/nightly/update.xml.  Should it contain 18.0a1?
I'm not sure which of those settings AUS uses for update polling, but if it's using the

[App]
...
Version=18.0a1

one, then that would explain the update loop.
blocking-basecamp: ? → +
First the app versions are compared, and then the build IDs. See the implementation logic here:

http://dxr.mozilla.org/mozilla-central/toolkit/mozapps/update/nsUpdateService.js#l1865.

If for some reason, the application.ini isn't being updated in the CI builds, that would probably explain this issue..
application.ini isn't failing to get updated (we wipe the entire obj dir prior to each build); it's just getting the wrong app version.

Should we investigate this, or should I just switch update.xml to specify 18.0a1?
The app version in application.ini seems to be hardcoded (see http://hg.mozilla.org/releases/mozilla-aurora/rev/8b18a47000f8/; thanks to :bc for finding).

I've updated update.xml to use 18.0a1.
retested with the new update.xml and its still looping.   After applying, and restarting, logcat returns the aus ping upon startup:

10-15 19:50:32.209: E/GeckoConsole(1918): AUS:SVC Checker:getUpdateURL - update URL: http://update.boot2gecko.org/nightly/update.xml?force=1
10-15 19:50:32.219: I/Gecko(1918): *** AUS:SVC Checker:onLoad - number of updates available: 1
10-15 19:50:32.219: E/GeckoConsole(1918): AUS:SVC Checker:onLoad - number of updates available: 1
10-15 19:50:32.229: I/Gecko(1918): *** AUS:SVC UpdateService:_selectAndInstallUpdate - prompting because silent install is disabled
10-15 19:50:32.229: E/GeckoConsole(1918): AUS:SVC UpdateService:_selectAndInstallUpdate - prompting because silent install is disabled
[8:13pm] jgriffin: tchung: marshall_law: ok, update.xml tweaked again:  http://update.boot2gecko.org/nightly/update.xml
[8:13pm] tchung: want me to try nwo?
[8:13pm] tchung: now
[8:13pm] jgriffin: sure
[8:26pm] tchung: jgriffin: no luck. same
[8:26pm] jgriffin: tchung: ok, I think marshall_law needs to debug from here
[8:27pm] tchung: jgriffin, marshall_law: here's the log activity.  https://gist.github.com/a7ded820e7b7e3aa3afb
[8:27pm] tchung: you can see it finds it, applies, restarts, then finds the update again.
[8:30pm] marshall_law: ergh

[8:32pm] marshall_law: oh, great.
[8:32pm] marshall_law: tchung: can you double check BuildID in application.ini again?
[8:32pm] marshall_law: is it still 20121015162538 ?
[8:32pm] cyee joined the chat room.
[8:32pm] tchung: App]
[8:32pm] tchung: Vendor=Mozilla
[8:32pm] tchung: Name=B2G
[8:32pm] tchung: Version=18.0a1
[8:32pm] tchung: BuildID=20121015162538
[8:32pm] tchung: ID={3c2e2abc-06d4-11e1-ac3b-374f68613e61}
[8:33pm] marshall_law: oh noes
[8:33pm] timdream left the chat room. (Ping timeout)
[8:33pm] marshall_law: ok, that wasn't too bad
[8:33pm] marshall_law:
[8:33pm] marshall_law: tchung: so.. the build ID is still more in the update.xml that is really bad
[8:33pm] jgilbert left the chat room. (Ping timeout)
[8:33pm] marshall_law: that either means the update isn't being applied, or somehow the build ID in gecko is wrong
Sorry Marshall, I know you're slammed but this is indeed a dogfooding blocker and someone needs to be the assignee.  If you can get someone else to take it, please re-assign, otherwise I'm hoping you'll get into this first thing tomorrow as we continue to drive down the updater issues that are blocking. Thanks.
Assignee: nobody → marshall
Just for reference, the buildID listed in the update is 20121015170411, which looks different than Tony's application.ini.

Right now, the only possibilities I see are:
- The update wasn't actually applied -- Tony were you able to confirm that anything changed after you updated?
- The application.ini wasn't updated for some reason
(In reply to Marshall Culpepper [:marshall_law] from comment #10)
> Just for reference, the buildID listed in the update is 20121015170411,
> which looks different than Tony's application.ini.
> 
> Right now, the only possibilities I see are:
> - The update wasn't actually applied -- Tony were you able to confirm that
> anything changed after you updated?
> - The application.ini wasn't updated for some reason

how do i tell?  the application.ini from unagi3 build matches exactly the unagi4 build.  but then again, both of these builds were only built 1 hour apart, so its very possible that nothing landed within that hour in gecko and gaia branches.
10-15 unagi 3
  <project name="gaia" path="gaia" remote="b2g" revision="589c7f8f7df88766f7a5fa944f6bb05eef04b8c3"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="ff73903bf8215b4e06c120ca85210a6b66d42f83"/>

10-15 unagi 4
  <project name="gaia" path="gaia" remote="b2g" revision="589c7f8f7df88766f7a5fa944f6bb05eef04b8c3"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="ff73903bf8215b4e06c120ca85210a6b66d42f83"/>


Unagi 3:
[App]
Vendor=Mozilla
Name=B2G
Version=18.0a1
BuildID=20121015153547
ID={3c2e2abc-06d4-11e1-ac3b-374f68613e61}

[Gecko]
MinVersion=18.0a2
MaxVersion=18.0a2

[XRE]
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={3c2e2abc-06d4-11e1-ac3b-374f68613e61}&version=18.0a1&buildid=20121015153547

Unagi 4: 
[App]
Vendor=Mozilla
Name=B2G
Version=18.0a1
BuildID=20121015153547
ID={3c2e2abc-06d4-11e1-ac3b-374f68613e61}

[Gecko]
MinVersion=18.0a2
MaxVersion=18.0a2

[XRE]
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={3c2e2abc-06d4-11e1-ac3b-374f68613e61}&version=18.0a1&buildid=20121015153547
This gets more and more interesting.

I was able to reproduce this by running the unagi 3 build, and updating to the latest update. It looks like the BuildID in application.ini differs is 40 minutes less than the the BuildID in the update.xml.

From the latest update.xml:

buildID="20121016075227"

And from /system/b2g/application.ini after I've applied the update:

BuildID=20121016071214

Since the update.xml is 40 minutes ahead of the application.ini, the updater logic will always prompt the user to apply..

@jgriffin I guess we will need to make sure the buildID in the update.xml matches the application.ini BuildID..
Assigning to jgriffin, this looks to be something weird in the update.xml generation..
Assignee: marshall → jgriffin
So the problem is we need to match the buildid in update.xml with the buildid generated in application.ini.
Fixed with https://github.com/jonallengriffin/b2gautomation/commit/cb3152ea8f3683c9e18e71e6f8f8b920880a8d29.  The buildid in update.xml now comes from application.ini.

QA should be able to verify this by using this build - https://releases.mozilla.com/b2g/2012-10-15/unagi4_2012-10-15.zip - to pick up today's update.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Verified fix going from 10/15 unagi 3 -> 10/16.

(see the BuildID change)

10-15 unagi 3
root@android:/system/b2g # cat application.ini                                 
[App]
Vendor=Mozilla
Name=B2G
Version=18.0a1
BuildID=20121015153547
ID={3c2e2abc-06d4-11e1-ac3b-374f68613e61}

[Gecko]
MinVersion=18.0a2
MaxVersion=18.0a2

[XRE]
EnableExtensionManager=1

[Crash Reporter]
Enabled=1
ServerURL=https://crash-reports.mozilla.com/submit?id={3c2e2abc-06d4-11e1-ac3b-374f68613e61}&version=18.0a1&buildid=20121015153547

Unagi 10-16
[App]
Vendor=Mozilla
Name=B2G
Version=18.0a1
BuildID=20121016071214
ID={3c2e2abc-06d4-11e1-ac3b-374f68613e61}

[Gecko]
MinVersion=18.0a2
MaxVersion=18.0a2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.