Deal with app.update.stage.enabled

RESOLVED FIXED

Status

Firefox OS
General
P1
normal
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: cjones, Assigned: marshall_law)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-kilimanjaro:+, blocking-basecamp:+)

Details

(Whiteboard: [LOE:S])

Attachments

(1 attachment)

Support for a different update path landed since the b2g updater was enabled.  I'm not 100% sure how this affected the updater protocol, but we need to figure out what to do with this new configuration option.
blocking-basecamp: --- → ?
Blocking for now - can you clarify what this means?
blocking-basecamp: ? → +
blocking-kilimanjaro: --- → +
No, it was rumored this was affecting b2g updates, but I haven't confirmed nor do I know what this setting does.
Who would know?
If you're still looking, Ehsan is your man. That pref came from bug 307181.

Comment 5

6 years ago
Ehsan, do you have some docs on this?

Comment 6

6 years ago
Not really.  I thought that b2g doesn't use the updater, same way that Android doesn't.  My patches disabled background updates for b2g IIRC.  What is exactly broken here?
Define "updater"?  We use nsUpdateService to download updates and then the related infrastructure to verify and apply them to the filesystem ...

It was unclear whether this bug affected that, but Marshall might know by now.

Comment 8

6 years ago
I'm talking about the updater application: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/updater.cpp

If that is used on b2g, then we should discuss how it needs to handle the background updates mode.
I ported that to gonk (b2g).  We use it.

Comment 10

6 years ago
(In reply to comment #9)
> I ported that to gonk (b2g).  We use it.

Oh, OK, I was not aware of that.  It would be useful for me and someone who knows how the updater works in b2g to have a quick meeting next week so that I can figure out what the b2g story looks like.

Two more questions: what is the exact failure?  And do all of the updater tests on mozilla-central pass with b2g (do we run those automatically somewhere?)?
(In reply to Ehsan Akhgari [:ehsan] from comment #10)
> (In reply to comment #9)
> > I ported that to gonk (b2g).  We use it.
> 
> Oh, OK, I was not aware of that.  It would be useful for me and someone who
> knows how the updater works in b2g to have a quick meeting next week so that
> I can figure out what the b2g story looks like.
> 

Do you mean the update checking, downloading, or applying?  All the core parts are 100% the same, but the UI hookup is different obviously.  http://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js fyi.

> Two more questions: what is the exact failure?  And do all of the updater
> tests on mozilla-central pass with b2g (do we run those automatically
> somewhere?)?

I haven't reproduced this, we heard through the grapevine that this was a problem.  No, we don't have those tests running yet.
(Assignee)

Updated

6 years ago
Assignee: nobody → marshall
(Assignee)

Comment 12

6 years ago
FYI, It does look like this is blocking the updater from working in Gonk.

(In reply to Ehsan Akhgari [:ehsan] from comment #10)
> It would be useful for me and someone who
> knows how the updater works in b2g to have a quick meeting next week

I'm available most of the week, Let's start with IRC and we can move to Skype/Vidyo if needed


> Two more questions: what is the exact failure?  And do all of the updater
> tests on mozilla-central pass with b2g (do we run those automatically
> somewhere?)?

In my local testing, since gCanStageUpdates is false, 
nsIUpdateProcessor::processUpdates is never being called. We aren't currently explicitly setting app.update.stage.enabled to true (is there anything else required?)

FWIW, we are not currently running Mochitest or xpcshell tests, so I doubt any of the automated updater tests are running. jgriffin and mdas are working on getting those running, though.

Comment 13

6 years ago
I talked to Marshall about this on IRC today.  In short, I don't think there's any big thing to fix for b2g.  We just need to make sure that /system is remounted RW before applying the update, and the stage directory lives on the same physical partition as the appdir.  Other than this I think most of the Linux code path should be usable here unmodified.
(Assignee)

Comment 14

6 years ago
It looks like the only changes required for this bug will be setting app.update.stage.enabled to true, and not writing to update.test from the gCanStageUpdates getter. 

The remount changes are already being tracked in Bug 764683
(Assignee)

Comment 15

6 years ago
Created attachment 648046 [details] [diff] [review]
enable update staging - v1

Feedback: :cjones
Attachment #648046 - Flags: review?(ehsan)
(Assignee)

Updated

6 years ago
Attachment #648046 - Flags: feedback?(jones.chris.g)
Comment on attachment 648046 [details] [diff] [review]
enable update staging - v1

Sure.
Attachment #648046 - Flags: feedback?(jones.chris.g) → feedback+

Comment 17

6 years ago
Comment on attachment 648046 [details] [diff] [review]
enable update staging - v1

Review of attachment 648046 [details] [diff] [review]:
-----------------------------------------------------------------

r=me assuming that the update process has been fully tested on b2g (with the remounting patches of course).
Attachment #648046 - Flags: review?(ehsan) → review+

Updated

6 years ago
Priority: -- → P1
(Assignee)

Updated

6 years ago
Whiteboard: [LOE:S]
https://hg.mozilla.org/mozilla-central/rev/bbc3d49c19ba
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.