Document FOTA partitions changes from bug 1136638

RESOLVED FIXED

Status

Firefox OS
General
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: gerard, Assigned: cmills)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
In bug 1136638 we landed changes to be able to dump partitions during FOTA. We should update the docs accordingly.
Flags: needinfo?(cmills)
(Reporter)

Comment 2

3 years ago
(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #1)
> Ok, so the doc is here:
> 
> https://developer.mozilla.org/en-US/Firefox_OS/
> Building_and_installing_Firefox_OS/Firefox_OS_update_packages
> 
> What needs to be changed in light of this update?

So we (should) have kept compatibility with the make targets previously implemented:
 - gecko-update-fota
 - gecko-update-fota-full

But we added a new one:
 - gecko-update-fota-fullimg

This is used to produce a recovery package that will dump a set of partitions images. The default set is controlled by the variable B2G_FOTA_FULLIMG_PARTS, in gonk-misc/Android.mk. It's a space-separated string of mountpoint:image to do. We default to "/boot:boot.img /system:system.img /recovery:recovery.img /cache:cache.img"

We also introduce some new environment variables to control the production of the two previous make targets: gecko-update-fota and gecko-update-fota-full. The goal is to keep the same kind of update package but get the possibility to arbitrary dump one or more partition image: updating boot partition, modem firmware, etc. The variable is B2G_FOTA_PARTS and it follows the same pattern as B2G_FOTA_FULLIMG_PARTS.

We introduced a way to describe a set of partitions that we want to be formatted during the installation of the recovery package using the variable B2G_FOTA_PARTS_FORMAT. It's a space-separated list of mount point that we will make use of.

Finally, we make use of this new feature through two new variables that allows us to wipe cache and/or data:
 - B2G_FOTA_WIPE_DATA
 - B2G_FOTA_WIPE_CACHE

All those changes heavily relies on having a proper recovery.fstab file provided for the device.
Flags: needinfo?(cmills)
(Reporter)

Updated

3 years ago
Flags: needinfo?(cmills)
Thanks for the information; I have had a go at putting this in a section of its own:

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

Can you give this a review to see if I've understood it correctly?

Particular concerns:

1. Is it positioned in a good place in the doc?
2. Do the bullet points make sense? Are those variables also defined in gonk-misc/Android.mk ?
3. Does the note at the bottom of the section make sense? Is there somewhere we should link to, to provide more information about recovery.fstab files?
Flags: needinfo?(cmills) → needinfo?(lissyx+mozillians)
(Reporter)

Comment 4

3 years ago
(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #3)
> Thanks for the information; I have had a go at putting this in a section of
> its own:
> 
> https://developer.mozilla.org/en-US/Firefox_OS/
> Building_and_installing_Firefox_OS/
> Firefox_OS_update_packages#Generating_a_FOTA_update_MAR_plus_recovery_package
> 
> Can you give this a review to see if I've understood it correctly?
> 
> Particular concerns:
> 
> 1. Is it positioned in a good place in the doc?

It looks like.

> 2. Do the bullet points make sense? Are those variables also defined in
> gonk-misc/Android.mk ?

Yes, except the ones for wiping of course, they are all defined with "good default values" (at least we expect them to be good default values for most of the usecases).

> 3. Does the note at the bottom of the section make sense? Is there somewhere
> we should link to, to provide more information about recovery.fstab files?

I'm not sure. It's mostly a note for when things goes bad.
Flags: needinfo?(lissyx+mozillians)
Ok, I think that'll do then.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.