1136638 - Support flashing partitions in FOTA updates

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Thomas Zimmermann [:tzimmermann] [:tdz]]

FOTA updates are currently limited to /system AFAICT. Anything else requires flashing new images.

We should support arbitrary files and partitions in FOTA updates so that we can update devices more easily.

Comment 1

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I'll investigate this a bit to see what is actually possible ATM and how to possibly improve it.

Comment 2

[Thomas Zimmermann [:tzimmermann] [:tdz]]

FYI: There is some related discussion in bug 1130288 comment 59 and below.

Comment 3

[Thomas Zimmermann [:tzimmermann] [:tdz]]

I made some tests with flame-kk, but I could not override files in the root directory. It looks like the boot/root partition is mounted RO.

Comment 4

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #3)
> I made some tests with flame-kk, but I could not override files in the root
> directory. It looks like the boot/root partition is mounted RO.

root folder is part of ramdisk.img and mounted RO mode.

Comment 5

[:gerard-majax]

So, current FOTA building passes explicitely system and data partitions fstype and location. This is extracted from the recovery fstab by some nice make/shell code.

AOSP does handle this by reading the recovery fstab: https://android.googlesource.com/platform/build/+/kitkat-mr2.2-release/tools/releasetools/common.py, LoadRecoveryFSTab

Comment 6

[:gerard-majax]

Attachment: B2G PR

Comment 7

[:gerard-majax]

Attachment: Gonk-misc PR

Comment 8

[:gerard-majax]

> B2G_FOTA_PARTS="/boot:boot.img /recovery:recovery.img" ./build.sh gecko-update-fota

This will generate a partial FOTA update of /system and flash boot and reovery partitions.

Comment 9

[:gerard-majax]

Pushed some new commits on the PR to make the formatting/flashing more controllable, and also, AVOID formatting userdata partition except if explicitely asked for.

Chris, this may need documentation once it lands.

Comment 10

[:gerard-majax]

So that's working, execpt for system and cache partition: both cannot be mounted as ext4 after doing this:

> unmount("/system");
> format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", 0, "/system");
> package_extract_file("system.img", "/dev/block/platform/msm_sdcc.1/by-name/system");

This is working fine for boot and recovery partition. The only differences is that in recovery.fstab, /system and /cache have 'ext4' as file system while /recovery and boot have 'emmc'.

Comment 11

[Dave Hylands [:dhylands]]

I think that the problem is that system.img is NOT an ext4 image. It's an ext4 image that's wrapped up in something else.

If I do:
> 2207 >adb pull /dev/block/mmcblk0p23
> 7949 KB/s (2671771648 bytes in 328.206s)
> 2208 >file mmcblk0p23 
> mmcblk0p23: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b (extents) (large files)

But if I run:
> 2209 >file out/target/product/aries/system.img 
> out/target/product/aries/system.img: data

And instructions for ext4 loop mounting system.img require running sim2img to produce the ext4 image.

So I don't think that you can write system.img as raw data to the partition. You need to essentially do what simg2img does first.

Comment 12

[:gerard-majax]

You're right. And checking in build/tools/releasetools/ota_from_target_files I see they do WriteRawImage() for boot and recovery partitions only.

Comment 13

[:gerard-majax]

So indeed, flash_image did not worked too. But using |simg2img| before packing the files saves us. And there is no impact on the resulting zip or mar file :)

Comment 14

[Chris Mills [:cmills]]

(In reply to Alexandre LISSY :gerard-majax from comment #9)
> Pushed some new commits on the PR to make the formatting/flashing more
> controllable, and also, AVOID formatting userdata partition except if
> explicitely asked for.
> 
> Chris, this may need documentation once it lands.

Our canonical article for this content is

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

When this is ready, sure, let's chat again and add a section (or whatever else is needed) to cover it.

Comment 15

[:gerard-majax]

We may need to add ZIP64 extensions:
> Generating fullimg FOTA update package
> mkdir -p `dirname out/target/product/aries/fota/fullimg/update.zip` || true
> Traceback (most recent call last):
>   File "tools/update-tools/build-flash-fota.py", line 131, in <module>
>     main()
>   File "tools/update-tools/build-flash-fota.py", line 125, in main
>     build_flash_fota(parser.parse_args())
>   File "tools/update-tools/build-flash-fota.py", line 57, in build_flash_fota
>     output_zip, update_bin)
>   File "/home/alex/codaz/Mozilla/b2g/devices/XperiaZ3c/B2G/tools/update-tools/update_tools.py", line 1155, in build_flash_fota
>     flash_zip.write(target_image, file)
>   File "/usr/lib/python2.7/zipfile.py", line 1146, in write
>     self._writecheck(zinfo)
>   File "/usr/lib/python2.7/zipfile.py", line 1114, in _writecheck
>     " would require ZIP64 extensions")
> zipfile.LargeZipFile: Filesize would require ZIP64 extensions
> make: *** [out/target/product/aries/fota/fullimg/update.zip] Erreur 1

Comment 16

[Dave Hylands [:dhylands]]

Comment on attachment 8583072 [details] [review]
B2G PR

So I took a look through this and I'm certainly fine with it conceptually.

I added some comments to the PR (can't remember if it was this one or the gonk-misc one) indicating that I'd like to see comments added which includes samples of the 2 formats of recovery.fstab. I didn't read that code in detail because I don't know what the differences are between version 1 and version 2 formats are off the top of my head.

We need to make sure that we don't break older platforms. So we should test that this works on whatever the oldest phone we have that supports FOTA for whichever branch this gets checked in on.

Comment 17

[Dave Hylands [:dhylands]]

Comment on attachment 8583073 [details] [review]
Gonk-misc PR

See my comments on the other PR.

Comment 18

[:gerard-majax]

(In reply to Dave Hylands [:dhylands] from comment #16)
> Comment on attachment 8583072 [details] [review]
> B2G PR
> 
> So I took a look through this and I'm certainly fine with it conceptually.
> 
> I added some comments to the PR (can't remember if it was this one or the
> gonk-misc one) indicating that I'd like to see comments added which includes
> samples of the 2 formats of recovery.fstab. I didn't read that code in
> detail because I don't know what the differences are between version 1 and
> version 2 formats are off the top of my head.

Yep, I saw your comment and I agree. Basically, fstab_version in this code is exactly the same problem as 'FSTAB_TYPE' in the Makefile code: linux/android fstab format.

> 
> We need to make sure that we don't break older platforms. So we should test
> that this works on whatever the oldest phone we have that supports FOTA for
> whichever branch this gets checked in on.

Yep, this is something we talked about with Gabriele yesterday evening. How far should we check, though?

Comment 19

[:gerard-majax]

Comment on attachment 8583073 [details] [review]
Gonk-misc PR

Andreas, I'd also like your feedback checking if we are breaking anything on your side.

Comment 20

[:gerard-majax]

Comment on attachment 8583072 [details] [review]
B2G PR

Andreas, I'd also like your feedback checking if we are breaking anything on your side.

Comment 21

[Andreas Pehrson [:pehrsons]]

We've only done incremental updates so far so in that sense we're not affected by this. I'll take it for a spin though to see that nothing is broken. Couldn't find anything obvious in the PRs at least :)

Comment 22

[Andreas Pehrson [:pehrsons]]

Comment on attachment 8583072 [details] [review]
B2G PR

ubifs seems broken with this patch. For a dolphin on master, gecko-update-fota-full worked without the patch. gecko-update-fota-fullimg generates this error:

> Generating fullimg FOTA update package
> mkdir -p `dirname out/target/product/scx15_sp7715ga/fota/fullimg/update.zip` || true
> Traceback (most recent call last):
>   File "tools/update-tools/build-flash-fota.py", line 131, in <module>
>     main()
>   File "tools/update-tools/build-flash-fota.py", line 125, in main
>     build_flash_fota(parser.parse_args())
>   File "tools/update-tools/build-flash-fota.py", line 57, in build_flash_fota
>     output_zip, update_bin)
>   File "/home/pehrsons/B2G/tools/update-tools/update_tools.py", line 1177, in build_flash_fota
>     flash_zip.write_updater_script(self.build_flash_script())
>   File "/home/pehrsons/B2G/tools/update-tools/update_tools.py", line 1293, in build_flash_script
>     self.FlashPartition(part, file)
>   File "/home/pehrsons/B2G/tools/update-tools/update_tools.py", line 1141, in FlashPartition
>     self.generator.WriteRawImage(mount_point, file)
>   File "/home/pehrsons/B2G/build/tools/releasetools/edify_generator.py", line 219, in WriteRawImage
>     partition_type = common.PARTITION_TYPES[p.fs_type]
> KeyError: 'ubi'
> make: *** [out/target/product/scx15_sp7715ga/fota/fullimg/update.zip] Error 1

Comment 23

[:gerard-majax]

Andreas, according to what I'm reading in build/tools/releasetools/common.py, there is no 'ubi' in the PARTITION_TYPES list, but there is 'ubifs'. Are those two the same ?

Comment 24

[Andreas Pehrson [:pehrsons]]

(In reply to Alexandre LISSY :gerard-majax from comment #23)
> Andreas, according to what I'm reading in
> build/tools/releasetools/common.py, there is no 'ubi' in the PARTITION_TYPES
> list, but there is 'ubifs'. Are those two the same ?

Those would be the same yes. Where's the 'ubi' coming from?

Comment 25

[Andreas Pehrson [:pehrsons]]

Comment on attachment 8583073 [details] [review]
Gonk-misc PR

This is actually the patch that kills the ubifs support.

See bug 1008239 for where it was added.

Comment 26

[:gerard-majax]

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #24)
> (In reply to Alexandre LISSY :gerard-majax from comment #23)
> > Andreas, according to what I'm reading in
> > build/tools/releasetools/common.py, there is no 'ubi' in the PARTITION_TYPES
> > list, but there is 'ubifs'. Are those two the same ?
> 
> Those would be the same yes. Where's the 'ubi' coming from?

It probably comes from your recovery.fstab.

Comment 27

[:gerard-majax]

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #25)
> Comment on attachment 8583073 [details] [review]
> Gonk-misc PR
> 
> This is actually the patch that kills the ubifs support.
> 
> See bug 1008239 for where it was added.

For now, given the error, it's consistent with the mismatch between PARTITION_TYPES and your recovery. You need to check if your update binary is able to use "ubi" and "ubifs" as filesystem in the FormatFn function implementation. That's in |bootable/recovery/updater/install.c| for my Flame tree.

Comment 28

[Andreas Pehrson [:pehrsons]]

(In reply to Alexandre LISSY :gerard-majax from comment #27)
> For now, given the error, it's consistent with the mismatch between
> PARTITION_TYPES and your recovery. You need to check if your update binary
> is able to use "ubi" and "ubifs" as filesystem in the FormatFn function
> implementation. That's in |bootable/recovery/updater/install.c| for my Flame
> tree.

It looks like this:
> 285     } else if (strcmp(partition_type, "UBI") == 0) {
> 286         if (strcmp(fs_type, "ubifs") == 0) {
> 287             int status = ubi_update(location, 0, mount_point);
> 288             if (status != 0) {
> 289                 printf("%s: ubi_update failed (%d) on %s",
> 290                        name, status, location);
> 291                 result = strdup("");
> 292                 goto done;
> 293             }
> 294             result = location;
> 295         }

I take it it won't like getting 'ubi' as input.


(In reply to Alexandre LISSY :gerard-majax from comment #26)
> It probably comes from your recovery.fstab.

'ubi' comes from the recovery.fstab indeed. Here's an excerpt:
> /dev/block/platform/sprd-sdhci.0/mmcblk0p1				/sdcard			vfat	defaults	defaults
> system			/system			ubifs	defaults	defaults
> userdata		/data			ubifs	defaults	defaults
> cache			/cache			ubifs	defaults	defaults
> misc			/misc			ubi		defaults	defaults
> boot			/boot			ubi		defaults	defaults
> recovery		/recovery		ubi		defaults	defaults
> tdmodem			/tdmodem		ubi		defaults	defaults
> (...)


James, could you help out here? For scx15/nand, there's a mismatch between recovery.fstab and what filesystem types are supported in recovery's updater. Recovery seems to only support 'ubifs' but recovery.fstab mentions 'ubi' multiple times. Is it possible to solve this on your end in recovery.fstab without breaking other things?

Comment 29

[Andreas Pehrson [:pehrsons]]

Perhaps we could solve it for now by having the script issue a big red warning when it hits an fstype it doesn't recognize - but ignoring that partition and proceeding anyway.

Comment 30

[:gerard-majax]

Might be something that works. Can you check what happens when you produce a non full-img but try to format ? For example:
> B2G_FOTA_PARTS_FORMAT="/recovery /system" B2G_FOTA_PARTS="/cache:cache.img" ./build.sh gecko-update-fota-full

This should produce a package that:
 - formats /recovery and /system
 - dumps cache.img to /cache
 - extracts a whole new /system directory onto this fresh partition.

We don't need to run it live for now, but before hacking like suggested in comment 29 I'd like to make sure we do not need to update other parts of the code for supporting ubi/ubifs

Comment 31

[Andreas Pehrson [:pehrsons]]

(In reply to Alexandre LISSY :gerard-majax from comment #30)
> Might be something that works. Can you check what happens when you produce a
> non full-img but try to format ? For example:
> > B2G_FOTA_PARTS_FORMAT="/recovery /system" B2G_FOTA_PARTS="/cache:cache.img" ./build.sh gecko-update-fota-full

That worked fine (to build, didn't try handing it to recovery). I only seem to have issues with gecko-update-fota-fullimg.

Comment 32

[:gerard-majax]

Attachment: Warning generated

Andreas, I've pushed a change that adds those warning. Would you mind having a look at this? This was on a Flame tree where I changed all partition to be 'ubi'.

Once we have something that properly generates partitions, it would be cool if we could assert that it does work live on your Dolphin device :). Don't forget to cross check the generated updater-script before testing on device.

Comment 33

[Andreas Pehrson [:pehrsons]]

Sweet! I will probably not be able to give it a go until after easter (April 7th), though.

Comment 34

[:gerard-majax]

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #33)
> Sweet! I will probably not be able to give it a go until after easter (April
> 7th), though.

Ok, if you don't mind I'll proceed with r? for now, and when it's ready we will wait for your feedback to make sure :)

Comment 35

[Andreas Pehrson [:pehrsons]]

Sure, go ahead.

Comment 36

[Dave Hylands [:dhylands]]

Comment on attachment 8583072 [details] [review]
B2G PR

I made a bunch of comments on github, most of which are fairly minor.

My biggest concern is that because the command line options have changed that this may wind up breaking production scripts used by the Buri to create FOTA up[dates.

Maybe this isn't a problem because we've never actually served a FOTA update?
Perhaps our vendors use these scripts?

Anyways, that's the only concern I have.

r=me with github comments addressed.

Comment 37

[:gerard-majax]

(In reply to Dave Hylands [:dhylands] from comment #36)
> Comment on attachment 8583072 [details] [review]
> B2G PR
> 
> I made a bunch of comments on github, most of which are fairly minor.

Addressed

> 
> My biggest concern is that because the command line options have changed
> that this may wind up breaking production scripts used by the Buri to create
> FOTA up[dates.

Builds we are producing should be done via the Make targets. Compatibility at this level is kept, except if I added bugs :)

> 
> Maybe this isn't a problem because we've never actually served a FOTA update?
> Perhaps our vendors use these scripts?

That's why I've asked Andreas to cross-check on his side.

> 
> Anyways, that's the only concern I have.
> 
> r=me with github comments addressed.

Thanks!

Comment 38

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8583073 [details] [review]
Gonk-misc PR

As mentioned on IRC I'm really glad to see all the makefile code go away, this will make this part of the code a lot more maintainable.

Comment 39

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8583072 [details] [review]
B2G PR

Looks good to me. Please file a follow up for documenting this on MDN. After our meeting in Portland with Kai-Zen and the others I'm positive none of our partners are using this infrastructure (yet) and the best way to ensure they do is to make it well documented.

Comment 40

[Andreas Pehrson [:pehrsons]]

Comment on attachment 8586012 [details]
Warning generated

Looks good. This is the output I'm getting for dolphin:
> Couldn't find /boot's partition type ubi in PARTITION_TYPES
> WARNING: Unknown FS type: 'ubi' for /boot will continue without flashing this partition
> Couldn't find /recovery's partition type ubi in PARTITION_TYPES
> WARNING: Unknown FS type: 'ubi' for /recovery will continue without flashing this partition


And this is the updater-script:
>  1 ui_print("Starting B2G FOTA: fullimg");
>  2 show_progress(1.0, 0);
>  3 set_progress(0.25);
>  4 ui_print("Checking device");
>  5 assert(getprop("ro.build.product") == "scx15_sp7715ga" || getprop("ro.product.device") == "scx15_sp7715ga" || getprop("ro.product.model") == "scx15_sp7715ga");
>  6 ui_print("Device is compatible");
>  7 ui_print("Flashing partition /boot");
>  8 ui_print("Flashing partition /system");
>  9 write_raw_image(package_extract_file("system.img"), "system");
> 10 ui_print("Flashing partition /recovery");
> 11 ui_print("Flashing partition /cache");
> 12 write_raw_image(package_extract_file("cache.img"), "cache");
> 13 set_progress(1.0);

My only remark is that we should perhaps not print anything for partitions we couldn't make use of. Or print a warning about it.

But if it's tricky to fix, don't bother.

Comment 41

[:gerard-majax]

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #40)
> Comment on attachment 8586012 [details]
> Warning generated
> 
> Looks good. This is the output I'm getting for dolphin:
> > Couldn't find /boot's partition type ubi in PARTITION_TYPES
> > WARNING: Unknown FS type: 'ubi' for /boot will continue without flashing this partition
> > Couldn't find /recovery's partition type ubi in PARTITION_TYPES
> > WARNING: Unknown FS type: 'ubi' for /recovery will continue without flashing this partition
> 
> 
> And this is the updater-script:
> >  1 ui_print("Starting B2G FOTA: fullimg");
> >  2 show_progress(1.0, 0);
> >  3 set_progress(0.25);
> >  4 ui_print("Checking device");
> >  5 assert(getprop("ro.build.product") == "scx15_sp7715ga" || getprop("ro.product.device") == "scx15_sp7715ga" || getprop("ro.product.model") == "scx15_sp7715ga");
> >  6 ui_print("Device is compatible");
> >  7 ui_print("Flashing partition /boot");
> >  8 ui_print("Flashing partition /system");
> >  9 write_raw_image(package_extract_file("system.img"), "system");
> > 10 ui_print("Flashing partition /recovery");
> > 11 ui_print("Flashing partition /cache");
> > 12 write_raw_image(package_extract_file("cache.img"), "cache");
> > 13 set_progress(1.0);
> 
> My only remark is that we should perhaps not print anything for partitions
> we couldn't make use of. Or print a warning about it.
> 
> But if it's tricky to fix, don't bother.

I agree it's suboptimal. I've pushed a change and it's locally ok for me, no more useless print.

Comment 42

[Andreas Pehrson [:pehrsons]]

That looks good now. Another thing I noticed (missed it before) is that the non-compatible images are still included in the zip - and the mar, taking up precious space.

Comment 43

[:gerard-majax]

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #42)
> That looks good now. Another thing I noticed (missed it before) is that the
> non-compatible images are still included in the zip - and the mar, taking up
> precious space.

Yep, but this situation is not expected to be something we want. Producing an update with the WARNING should already make people investigating this and making sure they are doing this properly :). Fixing this in the code may require quite some changes, hence I don't think it's really useful to bother, for now.

Comment 44

[:gerard-majax]

https://github.com/mozilla-b2g/gonk-misc/commit/d36455f7defa176797ef5aaf894fe99307081542
https://github.com/mozilla-b2g/B2G/commit/d89dce58d783f5d5fa24a895e534cafd5d3a007c

Comment 45

[Eric Tsai (no more review request accepted)]

I have problem with the patches when building flame-kk 2.2. When I configure with 
  BRANCH=v2.2 ./config.sh flame-kk
gonk-misc is in v2.2 branch without the patch. But b2g is in master branch. When I build with
  ./build.sh gecko-update-fota
There is an error message:
  build-flash-fota.py: error: argument --system-fstab is required
After I switch gonk-misc to master, I can make update.zip. Is it necessary to adapt this patch to gonk-misc v2.2 branch?

Comment 46

[:gerard-majax]

:( I forgot about B2G/ being master only ...

Gabriele, except uplifting, do you see a simple way out ?

Comment 47

[Gabriele Svelto [:gsvelto]]

(In reply to Alexandre LISSY :gerard-majax from comment #46)
> Gabriele, except uplifting, do you see a simple way out ?

Nothing I can think of. We have a dependency between the Android.mk file in gonk-misc and the scripts under B2G/tools/update-tools. It's just unfortunate that they sit in different repositories.

Comment 48

[:gerard-majax]

Attachment: Gonk-misc PR for branch v2.2

Comment 49

[:gerard-majax]

Eric, can you try this branch ? It looks to be okay for me. I've cherry-picked the patch and fixed a couple of things.

Comment 50

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8593988 [details] [review]
Gonk-misc PR for branch v2.2

LGTM, this makes the 2.2 branch practically identical to master with regards to FOTA updates which is a Good Thing™.

Comment 51

[Eric Tsai (no more review request accepted)]

Comment on attachment 8593988 [details] [review]
Gonk-misc PR for branch v2.2

Yes, the patch works for branch v2.2.

Comment 52

[:gerard-majax]

Comment on attachment 8593988 [details] [review]
Gonk-misc PR for branch v2.2

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): this bug
User impact if declined: developper are unable to produce recovery update packages for branches < master
Testing completed: local, generating and applying the recovery update successfully
Risk to taking this patch (and alternatives if risky): easy to backout
String or UUID changes made by this patch: none

Comment 53

[:gerard-majax]

Attachment: Gonk-misc PR for branch v2.1

Comment 54

[:gerard-majax]

Attachment: Gonk-misc PR for branch v2.0

Comment 55

[:gerard-majax]

It would be very nice if QA could cross check the gonk-misc PR for branches v2.0, v2.1 and v2.2. The steps should be:
 - Flash a v18D with v2.0 base system
 - Flash a Mozilla recovery pratition
 - build your system from vX branch (BRANCH=vX ./config.sh flame-kk && ./build.sh) with X being 2.0, 2.1 and 2.2
 - produce partial FOTA recovery package (./build.sh gecko-update-fota)
 - Boot device in recovery mode and select "Apply update from adb"
 - adb sideload <update.zip> with the update.zip generated in out/target/product/flame/fota/partial/update.zip

Comment 56

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8595159 [details] [review]
Gonk-misc PR for branch v2.1

Looking good

Comment 57

[Gabriele Svelto [:gsvelto]]

Comment on attachment 8595160 [details] [review]
Gonk-misc PR for branch v2.0

Likewise

Comment 58

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I think we need testing on this on the nexus-5-l since that's the thing that's being shipped.  Eric, since you already are handling what would block this bug ( Bug 1139331 ), could you take a look please?

Comment 59

[Dave Hylands [:dhylands]]

Comment on attachment 8595160 [details] [review]
Gonk-misc PR for branch v2.0

I think you'll need to request approvals for 2.0 and 2.1 as well.

Comment 60

[Eric Chang [:ericcc] [:echang]]

FWD to Gerry

Comment 61

[:gerard-majax]

Comment on attachment 8595159 [details] [review]
Gonk-misc PR for branch v2.1

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): this bug
User impact if declined: developper are unable to produce recovery update packages for branches < master
Testing completed: local, generating and applying the recovery update successfully
Risk to taking this patch (and alternatives if risky): easy to backout
String or UUID changes made by this patch: none

Comment 62

[:gerard-majax]

Comment on attachment 8595160 [details] [review]
Gonk-misc PR for branch v2.0

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.


[Approval Request Comment]
Bug caused by (feature/regressing bug #): this bug
User impact if declined: developper are unable to produce recovery update packages for branches < master
Testing completed: local, generating and applying the recovery update successfully
Risk to taking this patch (and alternatives if risky): easy to backout
String or UUID changes made by this patch: none

Comment 63

[bhavana bajaj [:bajaj]]

Comment on attachment 8593988 [details] [review]
Gonk-misc PR for branch v2.2

I'll want to land this on 2.2 and get it verified before considering older branch uplifts.

Comment 64

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gonk-misc/commit/7129207c321e7ac6e59bfa440693669403110e8c

Comment 65

[:gerard-majax]

(In reply to bhavana bajaj [:bajaj] from comment #63)
> Comment on attachment 8593988 [details] [review]
> Gonk-misc PR for branch v2.2
> 
> I'll want to land this on 2.2 and get it verified before considering older
> branch uplifts.

I would even wait for comment 55 to be addressed.

Comment 66

[Gerry Chang [:gchang]]

By following steps in comment #55, device can upgrade from 2.0/2.1/2.2 to 2.2 via "adb sideload <update.zip>" successfully. 
The update package is built by myself and put in my local environment. 

2.0 information:
Build ID               20141215191148
Gaia Revision          79f6218c4f30c2739575c3ab800078c2cda135cb
Gaia Date              2014-12-15 08:12:45
Gecko Revision         d9d4000dd43a3637345a41d716dc97fdd700d715
Gecko Version          32.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  65
Firmware Date          Mon Dec 15 18:51:29 CST 2014
Bootloader             L1TC000118D0

2.1 information:
Build ID               20150423161203
Gaia Revision          bbe983b4e8bebfec26b3726b79568a22d667223c
Gaia Date              2015-04-09 13:52:48
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/6a68a038146a
Gecko Version          34.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150423.194629
Firmware Date          Thu Apr 23 19:46:41 EDT 2015
Bootloader             L1TC000118D0

2.2 information:
Build ID               20150423162502
Gaia Revision          b838d0e7c163e66660dcb6e387d8339944a7a30e
Gaia Date              2015-04-23 02:32:46
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5fe76b26e55f
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150423.195827
Firmware Date          Thu Apr 23 19:58:39 EDT 2015
Bootloader             L1TC000118D0

All can upgrade to my local 2.2 build.
Build ID               20150415171332
Gaia Revision          bbe983b4e8bebfec26b3726b79568a22d667223c
Gaia Date              2015-04-09 13:52:48
Gecko Revision         n/a
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.gerry.20150414.174028
Firmware Date          Tue Apr 14 18:28:39 CST 2015
Bootloader             L1TC000118D0

Also, there is no bluetoothd in /system/bin in 2.0 and after upgrading to 2.2, bluetoothd shows up in /system/bin.

Comment 67

[Josh Cheng [:josh]]

Hi Gerry, 
Can we also verify this on Nexus 5-L per comment 58?
Thanks!

Comment 68

[Gerry Chang [:gchang]]

Attachment: log

Nexus 5 can't be upgraded via FOTA. My test steps are
1. Full flash pvt build.
2. Replace the recovery image with my local recovery image.
3. Change OTA url to my local server.
4. Perform FOTA

After above, nexus will boot to recovery mode, but it can't perform upgrade.
We need to use adb sideload "filename" and got below errors.

E:Error in /sideload/package.zip
(Status 6)

sideload_host finished
Restarting adbd...
Installation aborted.

Then, device can't reboot. Device stuck in "Google" screen.

Comment 69

[Gerry Chang [:gchang]]

Per comment #68, please also see bug 1163956.

Comment 70

[Josh Cheng [:josh]]

Comment on attachment 8595159 [details] [review]
Gonk-misc PR for branch v2.1

Approving given QA has verified on Flame per comment 66. However Nexus 5 is blocked by bug 1163956 which we should revisit when bug 1163956 fixed for N5.

Comment 71

[Josh Cheng [:josh]]

Comment on attachment 8595160 [details] [review]
Gonk-misc PR for branch v2.0

Approving given QA has verified on Flame per comment 66. However Nexus 5 is blocked by bug 1163956 which we should revisit when bug 1163956 fixed for N5.

Comment 72

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gonk-misc/commit/a3920f79cf34086d72567c1bf851ce8675ef3a4d
v2.0: https://github.com/mozilla-b2g/gonk-misc/commit/7524f355322b1075103a3cfce56070bf3f75cd60