FOTA update to earlier build

RESOLVED WONTFIX

Status

Firefox OS
General
RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: u495161, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

20.48 KB, application/x-bzip
Details
(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140830210550

Steps to reproduce:

1. Build B2G and flash to device
2. Update using FOTA


Actual results:

My build was commit from 2014-09-06 00:57:20
After update I had commit from 2014-09-05 oO


Expected results:

I think FOTA should check if actual build is newer than update.
It's not critical bug, but probably something could go wrong with downgrade
Ben, is it something that is expected to happen ?
Flags: needinfo?(bhearsum)
I believe that can happen if you push a custom build and then apply an OTA that will give you the previous day's nightly (which is still the latest one!)
(Reporter)

Comment 3

4 years ago
Fabrice, yeah, but question is, can this behavior break something in system?
If that possibility exists, I think, it will be better to do some kind of commit verification or something like that.

If you are 100% sure, that this can't break anything, it is ok to leave this as it is
I'm sure that downgrading from an indexedDB version n to version n-1 will not lead to happiness. So I guess that yes, we could check the build ids from gecko to prevent that.
If we perform a downgrade for iDB databases we can't even open them. For the settings DB for example we bump the version number for every release so we read the new default settings.
Going back to an older version will throw an error and we can't even open the DB. I don't think the phone will boot without a working settingsDB.
(In reply to Gregor Wagner [:gwagner] from comment #5)
> If we perform a downgrade for iDB databases we can't even open them. For the
> settings DB for example we bump the version number for every release so we
> read the new default settings.
> Going back to an older version will throw an error and we can't even open
> the DB. I don't think the phone will boot without a working settingsDB.

Right. And that's an issue itself we should fix to improve robustness, like restarting from scratch using the settings.json instead.
The update server has guards to protect against this sort of thing...I'm very surprised to hear this. It would be extremely helpful to have an update URL from a log to investigate this further. You should be able to get line that contains "https://aus4.mozilla.org" from adb logcat while checking for an update.
Flags: needinfo?(bhearsum)
(Reporter)

Comment 8

4 years ago
Actual URL from logcat:
https://aus4.mozilla.org/update/3/B2G/35.0a1/20140908040204/hamachi/en-US/nightly/Boot2Gecko%202.2.0.0-prerelease/default/default/update.xml?force=1

But I had another FOTA and now I have build from 08 september
(In reply to Kamil from comment #8)
> Actual URL from logcat:
> https://aus4.mozilla.org/update/3/B2G/35.0a1/20140908040204/hamachi/en-US/
> nightly/Boot2Gecko%202.2.0.0-prerelease/default/default/update.xml?force=1
> 
> But I had another FOTA and now I have build from 08 september

Unfortunately, this is a post-update URL, and not quite as useful. If I manually adjust it to look like an older build (ie: https://aus4.mozilla.org/update/3/B2G/35.0a1/20140906040204/hamachi/en-US/nightly/Boot2Gecko%202.2.0.0-prerelease/default/default/update.xml?force=1), it gets a build from the 8th - which sounds right to me.

I'm not seeing anything wrong here...it would help if someone could flash back to an affected build, run logcat, and do the update again.
(Reporter)

Comment 10

4 years ago
i dont have this image anymore :/

mac, could you flash this build again and check?
Flags: needinfo?(zrzut01)

Comment 11

4 years ago
Created attachment 8490568 [details]
logcat from update session

Before FOTA I had:

B2G version: 2.2.0.0-prerelease master
Platform version: 35.0a1
Build Identifier: 20140916142307 
Git commit info: 2014-09-16 09:11:51 c4510528

After FOTA I have:

B2G version: 2.2.0.0-prerelease master
Platform version: 35.0a1
Build Identifier: 20140916160204
Git commit info: 2014-09-15 17:39:43
Flags: needinfo?(zrzut01)
(In reply to mac from comment #11)
> Created attachment 8490568 [details]
> logcat from update session
> 
> Before FOTA I had:
> 
> B2G version: 2.2.0.0-prerelease master
> Platform version: 35.0a1
> Build Identifier: 20140916142307 
> Git commit info: 2014-09-16 09:11:51 c4510528

I can't find any record of a build that we've done with this buildid. If this is a build that was done on your own or a developer's machine and then put on the "nightly" channel, this is an unsupported scenario.

> After FOTA I have:
> 
> B2G version: 2.2.0.0-prerelease master
> Platform version: 35.0a1
> Build Identifier: 20140916160204
> Git commit info: 2014-09-15 17:39:43

This is a Mozilla-produced nightly. The reason the commit date is older than the build identifier is becasue we only build once a day, and we use a known-good commit to produce nightlies.

I just realized that comment #0 here talks about building b2g and flashing. Given that, this bug is WONTFIX. I recommend against doing your own builds with B2G_UPDATE_CHANNEL set -- no promises can be made about what sorts of update results you get.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
I should say - this is WONTFIX from a RelEng perspective. If there's stuff that engineering wants to do to protect against this, that's not my call. Buildid and version are the only information we serve as part of the update response though - so I'm not sure how the client could make a decision to be smarter here.
You need to log in before you can comment on or make changes to this bug.