Enable FOTA to update necessary bluetooth daemon files for v2.2

RESOLVED FIXED in 2.2 S6 (20feb)

Status

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: shawnjohnjr, Assigned: tzimmermann)

Tracking

({verifyme})

unspecified
2.2 S6 (20feb)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.2+, b2g-v2.2 fixed, b2g-master fixed)

Details

Attachments

(6 attachments)

Because we moved to bluetooth daemon architecture, Gecko bluetooth module now depends on bluetoothd. If there is any IPC protocol (currently we used BlueZ Protocol) or bluetoothd fix, OTA users cannot get updated. OTA users need to update system partition to get update. This might lead incompatible update since gecko/bluetoothd are mismatched.

I think current OTA mechanism just simply pack /system/b2g folder and replace b2g folder during OTA updating, so it will be easier to pack necessary files into /system/b2g for bluetooth daemon.
To achieve this, a few things we need to do:
1. Change Android.mk for bluedroid to put bluetoothd to /system/b2g (maybe it's necessary to move libfdio.so from /system/lib to /system/b2g?)
2. Change init.bluetooth.rc to replace /system/bin/bluetoothd to /system/b2g/bluetoothd

Thomas, do you have any concern or suggestion?
Flags: needinfo?(tzimmermann)
ni :kli
Since he had some experience about OTA solution.
It will be good if you can raise any concern if we put bluetoothd under /system/b2g.
Flags: needinfo?(kli)
> To achieve this, a few things we need to do:
> 1. Change Android.mk for bluedroid to put bluetoothd to /system/b2g (maybe
> it's necessary to move libfdio.so from /system/lib to /system/b2g?)
> 2. Change init.bluetooth.rc to replace /system/bin/bluetoothd to
> /system/b2g/bluetoothd
> 
> Thomas, do you have any concern or suggestion?

Not in general, but I'm curious how others handle this problem. Other system daemons reside in '/system/bin' AFAIK.

@kli: Is is possible to add things outside of /system/b2g to OTA updates? AFAIK the mechanism can update any file. So it seems rather a policy thing to only update /system/b2g.(In reply to Shawn Huang [:shawnjohnjr] from comment #1)
Flags: needinfo?(tzimmermann)
Bug 1130293 looks like nfcd doesn't get OTA updates as well.

We also need to move libfdio.so to /system/b2g. This might lead to problems with the dynamic linker if the directory is not in the linker's search path.
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #3)
> > To achieve this, a few things we need to do:
> > 1. Change Android.mk for bluedroid to put bluetoothd to /system/b2g (maybe
> > it's necessary to move libfdio.so from /system/lib to /system/b2g?)
> > 2. Change init.bluetooth.rc to replace /system/bin/bluetoothd to
> > /system/b2g/bluetoothd
> > 
> > Thomas, do you have any concern or suggestion?
> 
> Not in general, but I'm curious how others handle this problem. Other system
> daemons reside in '/system/bin' AFAIK.
> 
> @kli: Is is possible to add things outside of /system/b2g to OTA updates?
> AFAIK the mechanism can update any file. So it seems rather a policy thing
> to only update /system/b2g.(In reply to Shawn Huang [:shawnjohnjr] from
> comment #1)
I would say if OTA update script can update /system/bin/bluetoothd, /system/lib/libfdio.so, it will be the best solution, so we don't need to change any code.
I'd prefer this as well.
Now, OTA can only update /system/b2g/*. To update files outside /system/b2g with OTA, I think we need to enhance the current OTA design. But we can use FOTA to update any file under /system/* easily, as FOTA will reboot into recovery ROM and can update files to /boot /data and /system partitions.

There are some options to have bluetoothd/nfcd(bug 1130293) and related library files get updated:

1. move these daemon and library into /system/b2g dir. 
  (This could be a little bit tricky, but less effort)

2. when these daemon and library files need to be updated, we pack and update them in FOTA format.

3. enhance the current OTA design, allow it update files outside /system/b2g/ dir.


One more thing come in my mind about the update of bluetoothd. It is init.bluetooth.rc which is in ramdisk of boot.img and I think it can be updated via FOTA only. I am not sure if there is demand to update this file. If we need to consider it, method 2 could be the most suitable one.
Flags: needinfo?(kli)
Alexandre and Gabriele, per the above discussion, do you have any other idea on How to have files outside /system/b2g dir get updated?
Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(gsvelto)
Fabrice, do you have any other suggestion?
Flags: needinfo?(fabrice)
A couple of things:
 - we can do whatever we want when in FOTA, but we currently do not support everything
 - current FOTA package installation allows to not only touch /system/b2g but anything, this is used on some builds to update fonts (that are living in /system/fonts) ; the directories used are controlled by the B2G_FOTA_DIRS environment variable (gonk-misc/Android.mk)
 - we could flash new partitions (needed for boot.img changes) but this is not supported for now

So, what you can do right now is:
 - make sure your package install target puts your binary and libs into /system/b2g/ ; then those will be picked up by default in OTA and FOTA
 - augment the current edify script applied during FOTA installation to remove the stale binaries you know about (/system/bin/bluetoothd for instance)

What you cannot do:
 - flash new boot.img

As far as I know, the current Flame updates that are distributed are only OTA ones ; this can probably be easily switched server-side.
Flags: needinfo?(lissyx+mozillians)
(In reply to Kai-Zhen Li [:seinlin] from comment #7)
> One more thing come in my mind about the update of bluetoothd. It is
> init.bluetooth.rc which is in ramdisk of boot.img and I think it can be
> updated via FOTA only. I am not sure if there is demand to update this file.
> If we need to consider it, method 2 could be the most suitable one.
Honestly FOTA can fix the our problems, there are so many people are complaining bluetooth is dead after having OTA update, and we're trying to announce this information cross mailing lists to ask people full flash images but the results are not good :(
(In reply to Alexandre LISSY :gerard-majax from comment #10)
> A couple of things:
>  - we can do whatever we want when in FOTA, but we currently do not support
> everything
>  - current FOTA package installation allows to not only touch /system/b2g
> but anything, this is used on some builds to update fonts (that are living
> in /system/fonts) ; the directories used are controlled by the B2G_FOTA_DIRS
> environment variable (gonk-misc/Android.mk)
>  - we could flash new partitions (needed for boot.img changes) but this is
> not supported for now
> 
> So, what you can do right now is:
>  - make sure your package install target puts your binary and libs into
> /system/b2g/ ; then those will be picked up by default in OTA and FOTA
>  - augment the current edify script applied during FOTA installation to
> remove the stale binaries you know about (/system/bin/bluetoothd for
> instance)
> 
> What you cannot do:
>  - flash new boot.img

But we need to do that if we want to move the daemons to /system/b2g to update the init.rc files, right?
Flags: needinfo?(fabrice)
That's my understanding also. Being able to flash partition should not be a big issue:
 - we need to embed the partition image in the update zip
 - we need the binary to write the partition (I don't remember the name)
 - we need the target partition device name
We'll need at least one FOTA update anyway, and if only to update init.b2g.rc.

I'd expect to have more daemons in the future and we probably don't want them to all reside in /system/b2g. So how much work is it to add support for non-b2g directories/files to the OTA script?
Clearing my NI as Alexandre already replied in comment 10.
Flags: needinfo?(gsvelto)
Hi Chris,
Do you know how much work if OTA (or FOTA) can push binary files (boot.img and /system/bin/bluetoothd, /system/lib/libfdio.so)? There are many people complaining bluetooth is not working after OTA update, would you please answer questions in Comment 14? AFAIK, OTA controlled by Release Engineering team.
Flags: needinfo?(catlee)
Summary: Move bluetoothd from /system/bin to /system/b2g for OTA update package → Enable FOTA to update necessary bluetooth daemon files for v2.2
(In reply to Alexandre LISSY :gerard-majax from comment #13)
> That's my understanding also. Being able to flash partition should not be a
> big issue:
>  - we need to embed the partition image in the update zip
>  - we need the binary to write the partition (I don't remember the name)
>  - we need the target partition device name

The update.zip sign key should be the same one in recovery partition, others will fail.
For stable release (e.g. 18D, using T2M own key) with shallow flash to nightly build, I think FOTA will still fail.
See Also: → 1132388
(In reply to Eric Tsai from comment #17)
> (In reply to Alexandre LISSY :gerard-majax from comment #13)
> > That's my understanding also. Being able to flash partition should not be a
> > big issue:
> >  - we need to embed the partition image in the update zip
> >  - we need the binary to write the partition (I don't remember the name)
> >  - we need the target partition device name
> 
> The update.zip sign key should be the same one in recovery partition, others
> will fail.
> For stable release (e.g. 18D, using T2M own key) with shallow flash to
> nightly build, I think FOTA will still fail.
How can we achieve FOTA update without sign key? It looks like it's impossible to do FOTA update now with this sign key. :(
Flags: needinfo?(etsai)
(In reply to Shawn Huang [:shawnjohnjr] from comment #18)
> (In reply to Eric Tsai from comment #17)
> > (In reply to Alexandre LISSY :gerard-majax from comment #13)
> > > That's my understanding also. Being able to flash partition should not be a
> > > big issue:
> > >  - we need to embed the partition image in the update zip
> > >  - we need the binary to write the partition (I don't remember the name)
> > >  - we need the target partition device name
> > 
> > The update.zip sign key should be the same one in recovery partition, others
> > will fail.
> > For stable release (e.g. 18D, using T2M own key) with shallow flash to
> > nightly build, I think FOTA will still fail.
> How can we achieve FOTA update without sign key? It looks like it's
> impossible to do FOTA update now with this sign key. :(

typo: s/with/without
It's just a matter of who issues/signs the package. If T2M does and then it's getting distributed, there should be no reason.

If people flashed a rebuilt recovery, it should be fine.
(In reply to Shawn Huang [:shawnjohnjr] from comment #19)
> > How can we achieve FOTA update without sign key? It looks like it's
> > impossible to do FOTA update now with this sign key. :(
> 
> typo: s/with/without

(In reply to Alexandre LISSY :gerard-majax from comment #20)
> It's just a matter of who issues/signs the package. If T2M does and then
> it's getting distributed, there should be no reason.
> 
> If people flashed a rebuilt recovery, it should be fine.

Agree with Alexandre, who provides recovery partition is able to verify the update package.

IMO, we may 1) replace the key in recovery partition by full flash, 2) get manufacturer's key (I don't know if there is any use test key) or 3) let manufacturer sign the package for us. All above need TAM's support by each device, no silver bullet.
Flags: needinfo?(etsai)
Thanks Alexandre and Eric. And I also talked with Wesley today who is working on V18D_nightly package.
So my understanding now:
1. V18D package from MDN is with manufacturer's key (but for release v2.0)
2. V18D_nightly package from MDN is with test sign key that Mozilla can use it for (F)OTA
3. Naoki is going to pack another version for V18D_nightly, this package contains V18D from T2M + new gecko/gaia + necessary bluetoothd files
4. If user flash V18D_nightly, user will have chance to update via (F)OTA in the future.
Assignee: nobody → tzimmermann
Status: NEW → ASSIGNED
Attachment #8564120 - Flags: review?(gsvelto)
Attachment #8564124 - Flags: review?(gsvelto)
Comment on attachment 8564120 [details]
Github pull request for platform_build on KK

I guess this is located separately from the rest of the update scripts because it might be platform specific. I'll send out pull request for the remaining branches after this one got its OK.
Using this patch set, I'm able to update the individual files of the Bluetooth daemon.
Comment on attachment 8564120 [details]
Github pull request for platform_build on KK

Looks good to me, I've just noted a nit in the PR.
Attachment #8564120 - Flags: review?(gsvelto) → review+
Comment on attachment 8564125 [details]
Github pull request for gonk-misc

This is also looking good.
Attachment #8564125 - Flags: review?(gsvelto) → review+
Comment on attachment 8564124 [details]
Github pull request for B2G

I'm a bit unsure about the optimization you removed: from your comment, and from glancing over the code it seems to be removing directories that shouldn't be part of the update.zip file. I wonder if removing it would cause us to leave unneeded stuff in the zip.
(In reply to Gabriele Svelto [:gsvelto] from comment #30)
> Comment on attachment 8564124 [details]
> Github pull request for B2G
> 
> I'm a bit unsure about the optimization you removed: from your comment, and
> from glancing over the code it seems to be removing directories that
> shouldn't be part of the update.zip file. I wonder if removing it would
> cause us to leave unneeded stuff in the zip.

Is it a requirement to have minimal scripts and zip files? Because of the changes, the updated files are now processed individually; before the scripts handled complete directories IIRC.
(In reply to Gabriele Svelto [:gsvelto] from comment #30)
> Comment on attachment 8564124 [details]
> Github pull request for B2G
> 
> I'm a bit unsure about the optimization you removed: from your comment, and
> from glancing over the code it seems to be removing directories that
> shouldn't be part of the update.zip file. I wonder if removing it would
> cause us to leave unneeded stuff in the zip.

Regarding this optimization: this seems to be related to not traversing directories if they don't contain updated files (i.e., if they are part of the updated-files list).

This optimization breaks when updating single files, because the base path of single files is not part of the file list; only the file path itself.
Ken, Wesley,

we will need new base images for the Flame (master + v2.2) before enabling bluetoothd. Can you help with that?
Flags: needinfo?(whuang)
Flags: needinfo?(kchang)
I believe that you want to ni? Wesly Huang.
Flags: needinfo?(whuang) → needinfo?(wehuang)
Comment on attachment 8564124 [details]
Github pull request for B2G

As per our IRC discussion this is only going to affect the script where we'll have a few more chmod's. That's not something worth bothering about.
Attachment #8564124 - Flags: review?(gsvelto) → review+
Oh! 'Wesly' and 'Wesley' Huang are not the same person!
Same code as for KK
Attachment #8565893 - Flags: review?(gsvelto)
Comment on attachment 8565893 [details]
Github pull request for platform_build on L

Rubber stamping since it's the same change :)
Attachment #8565893 - Flags: review?(gsvelto) → review+
Changes to KK:

  - no support for SE labels and capabilities, so references to |self.selabel| and |se.capabilities| have been removed
Attachment #8565896 - Flags: review?(gsvelto)
Same code as on JB
Attachment #8565901 - Flags: review?(gsvelto)
Comment on attachment 8565896 [details]
Github pull request for platform_build on JB

Looking good.
Attachment #8565896 - Flags: review?(gsvelto) → review+
Comment on attachment 8565901 [details]
Github pull request for platform_build on ICS

Likewise.
Attachment #8565901 - Flags: review?(gsvelto) → review+
Comment on attachment 8564120 [details]
Github pull request for platform_build on KK

Updated github pull request

  - removed an empty line
Attachment #8564120 - Attachment mime type: text/plain → text/html
Comment on attachment 8565893 [details]
Github pull request for platform_build on L

Updated Github pull request

  - removed an empty line
Comment on attachment 8565896 [details]
Github pull request for platform_build on JB

Updated Github pull request

  - removed an empty line
Comment on attachment 8565901 [details]
Github pull request for platform_build on ICS

Updated Github pull request

  - removed an empty line
This patch set will be required in v2.2 to update the system programs, such as bluetoothd.
blocking-b2g: --- → 2.2?

Comment 49

4 years ago
Triage is blocking, as Bluetooth won't work without this, and this needs to be uplifted from master to 2.2.
blocking-b2g: 2.2? → 2.2+
Comment on attachment 8564120 [details]
Github pull request for platform_build on KK

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 #): 

  General short-coming of current update infrastructure; exposed by bug 1005934

User impact if declined: 

  Users won't be able to update system daemons, such as bluetoothd, on
  v2.2. Those programs are an integrate piece of Gecko's functionality.

Testing completed: 

  Locally generated and installed an update

Risk to taking this patch (and alternatives if risky): 

  Could be interfere with generation of update packages; some QA is advised

String or UUID changes made by this patch:

  None
Attachment #8564120 - Flags: approval-mozilla-b2g37?
Comment on attachment 8564124 [details]
Github pull request for B2G

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

[Approval Request Comment]

  Please see comment #50
Attachment #8564124 - Flags: approval-mozilla-b2g37?
Comment on attachment 8564125 [details]
Github pull request for gonk-misc

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

[Approval Request Comment]

  Please see comment #50
Attachment #8564125 - Flags: approval-mozilla-b2g37?
Comment on attachment 8565893 [details]
Github pull request for platform_build on L

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

[Approval Request Comment]

  Please see comment #50
Attachment #8565893 - Flags: approval-mozilla-b2g37?
Comment on attachment 8565896 [details]
Github pull request for platform_build on JB

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

[Approval Request Comment]

  Please see comment #50
Attachment #8565896 - Flags: approval-mozilla-b2g37?
Comment on attachment 8565901 [details]
Github pull request for platform_build on ICS

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

[Approval Request Comment]

  Please see comment #50
Attachment #8565901 - Flags: approval-mozilla-b2g37?
Ni, Nhirata, to help test this patch on 3.0 before uplifting to branch.
Flags: needinfo?(nhirata.bugzilla)
Keywords: verifyme
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #33)
> Ken, Wesley,
> 
> we will need new base images for the Flame (master + v2.2) before enabling
> bluetoothd. Can you help with that?

Hi Thomas:

sorry for late, our additional Flame contract with T2M only covers OS upgrade to 2.0 (while the original one covers 1.3 for shipping), and the v18D is so far the last SW planned for this contract. And now the next SOW with them is for L BSP porting so still not covering 2.2, thus I'm afraid we need to find other way forward.
Flags: needinfo?(wehuang)
Too bad. How do we get out of that...?
Gabriele,

AFAICS the FOTA scripts only support content under /system, right? Would it be possible to extend them to cover other directories and partitions as well; especially the root directory?
Flags: needinfo?(gsvelto)
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(kchang)
Flags: needinfo?(catlee)
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #59)
> AFAICS the FOTA scripts only support content under /system, right? Would it
> be possible to extend them to cover other directories and partitions as
> well; especially the root directory?

By default we mount /system and /data and we generally unpack stuff only under /system. To unpack stuff directly into / we'd probably need some changes.
Flags: needinfo?(gsvelto)
(In reply to Gabriele Svelto [:gsvelto] from comment #60)
> (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #59)
> > AFAICS the FOTA scripts only support content under /system, right? Would it
> > be possible to extend them to cover other directories and partitions as
> > well; especially the root directory?
> 
> By default we mount /system and /data and we generally unpack stuff only
> under /system. To unpack stuff directly into / we'd probably need some
> changes.

To complement, and as explained in comment 10, we can add partitions flashing this to the recovery package, but as Gabriele replied, this needs some work.

I'm not really sure we would want to modify the boot partition like this, by mounting it in recovery mode.
See Also: → 1136638
Moving the discussion to bug 1136638
(In reply to Wesly Huang from comment #57)
> (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #33)
> > Ken, Wesley,
> > 
> > we will need new base images for the Flame (master + v2.2) before enabling
> > bluetoothd. Can you help with that?
> 
> Hi Thomas:
> 
> sorry for late, our additional Flame contract with T2M only covers OS
> upgrade to 2.0 (while the original one covers 1.3 for shipping), and the
> v18D is so far the last SW planned for this contract. And now the next SOW
> with them is for L BSP porting so still not covering 2.2, thus I'm afraid we
> need to find other way forward.
Wesly,
I think Thomas is talking about 'V18D_nightly' images, which can allow us to do OTA.
Flags: needinfo?(wehuang)
Yes, let me clarify.

AFAICT we'd need a new base image to distribute some changes in the init scripts. I can even build that locally. The question is probably more about legally distributing such a base image to the general public (i.e., dogfooders).
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #64)
> Yes, let me clarify.
> 
> AFAICT we'd need a new base image to distribute some changes in the init
> scripts. I can even build that locally. The question is probably more about
> legally distributing such a base image to the general public (i.e.,
> dogfooders).

AFAICT, v18D is for v2.0 and update via official T2M FOTA server to end-users.
V18D-nightly (naming is confused) is for dogfooders who wants to update catch up the latest software.
Wesly, can you share the link so we can test with the latest V18D-nightly packages?
(In reply to Shawn Huang [:shawnjohnjr] from comment #63)
> (In reply to Wesly Huang from comment #57)
> > (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #33)
> > > Ken, Wesley,
> > > 
> > > we will need new base images for the Flame (master + v2.2) before enabling
> > > bluetoothd. Can you help with that?
> > 
> > Hi Thomas:
> > 
> > sorry for late, our additional Flame contract with T2M only covers OS
> > upgrade to 2.0 (while the original one covers 1.3 for shipping), and the
> > v18D is so far the last SW planned for this contract. And now the next SOW
> > with them is for L BSP porting so still not covering 2.2, thus I'm afraid we
> > need to find other way forward.
> Wesly,
> I think Thomas is talking about 'V18D_nightly' images, which can allow us to
> do OTA.

I see, thanks Shawn. Like just talked, there is a new v18D_nighty under testing by QA Mike now, my understanding is BT should work in that build, will share it to Thomas and you offline to double check if BT works as expected, too.(In reply to Shawn Huang [:shawnjohnjr] from comment #65)
> (In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #64)
> > Yes, let me clarify.
> > 
> > AFAICT we'd need a new base image to distribute some changes in the init
> > scripts. I can even build that locally. The question is probably more about
> > legally distributing such a base image to the general public (i.e.,
> > dogfooders).
> 
> AFAICT, v18D is for v2.0 and update via official T2M FOTA server to
> end-users.
> V18D-nightly (naming is confused) is for dogfooders who wants to update
> catch up the latest software.
> Wesly, can you share the link so we can test with the latest V18D-nightly
> packages?

Thanks Shawn and yes, like we just talked the new v18D_nighty under testing by QA Mike now, I will share it to Thomas and you offline to double check if BT works as expected, too.
Flags: needinfo?(wehuang)
sorry for some dup. msg in comment#66 due to my browser misbehavior, anyway the message is the same.
Flags: needinfo?(nhirata.bugzilla)
nhirata, can you confirm this is good to uplift or not ?
naoki is verifying this but does not see anything blocking us from uplift yet, so I am approving this and 1134821 to not lose on more branch testing.
Attachment #8564120 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Attachment #8564124 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Attachment #8564125 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Attachment #8565893 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Attachment #8565896 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
Attachment #8565901 - Flags: approval-mozilla-b2g37? → approval-mozilla-b2g37+
I made my best stab at all the relevant uplifts for v2.2. Please correct me if I messed any of it up.

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #48)
> Master:
> https://github.com/mozilla-b2g/B2G/commit/
> 42dbad3bf1a2c7f8247f7e20094d7b144a31a2e6

Doesn't need uplift (all versions use the same code).

> Master:
> https://github.com/mozilla-b2g/gonk-misc/commit/
> 3905180d9e2dbe03d7ce3b3a6debe4d4adc938d1

v2.2: https://github.com/mozilla-b2g/gonk-misc/commit/6c6daa88dc3fc30df7b70837c536d868ba87673e

> Master:
> https://github.com/mozilla-b2g/platform_build/commit/
> 173b3104bfcbd23fc9dccd4b0035fc49aae3d444

v2.2: https://github.com/mozilla-b2g/platform_build/commit/05bfa210e684e07b3c884a3e6784100656eeb87f

> b2g-4.3_r2.1:
> https://github.com/mozilla-b2g/platform_build/commit/
> 4efd19d199ae52656604f794c5a77518400220fd

v2.2 is pinned to this branch where needed.

> b2g-4.4.2_r1:
> https://github.com/mozilla-b2g/platform_build/commit/
> ef937d1aca7c4cf89ecb5cc43ae8c21c2000a9db

v2.2 is pinned to this branch where needed.

> b2g-5.0.0_r6:
> https://github.com/mozilla-b2g/platform_build/commit/
> 0ca5e1456dfd417c3e4e72bb8eae02069136b99b

v2.2 is pinned to this branch where needed.
Flags: needinfo?(tzimmermann)
The patches look good to me.
Flags: needinfo?(tzimmermann)
Eric, could you or someone on your team take a look at this please?  I noticed that you were handling Bug 1139331 which blocked me from fully testing this.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(echang)
FWD to Gerry
Flags: needinfo?(echang)
Flags: needinfo?(gchang)
After trying V18D_nightly to perform FOTA, got the same problem as bug 1155035.
Flags: needinfo?(gchang)
See Also: → 1155035
You need to log in before you can comment on or make changes to this bug.