Closed Bug 1008239 Opened 11 years ago Closed 10 years ago

[dolphin] ./build.sh gecko-update-fota and gecko-update-fota-full didn't work

Categories

(Firefox OS Graveyard :: GonkIntegration, defect)

x86_64
Gonk (Firefox OS)
defect
Not set
major

Tracking

(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S4 (20june)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: seinlin, Assigned: seinlin)

References

Details

(Keywords: smoketest, Whiteboard: [Dolphin_1.4])

Attachments

(5 files, 7 obsolete files)

1.28 KB, text/plain
Details
43 bytes, text/x-github-pull-request
dhylands
: review+
Details | Review
49 bytes, text/x-github-pull-request
dhylands
: review+
Details | Review
49 bytes, text/x-github-pull-request
Details | Review
199.09 KB, patch
Details | Diff | Splinter Review
Can't build update package for dolphin and error message is: -- Install system fs image: out/target/product/scx15_sp7715ga/system.img Using yaffs2 filesystem Extracting partitions from recovery fstab Mounting /system from Mounting /data from Generating FOTA update package mkdir -p `dirname out/target/product/scx15_sp7715ga/fota/partial/update.zip` || true usage: build-flash-fota.py [options] build-flash-fota.py: error: argument --system-location: expected one argument make: *** [out/target/product/scx15_sp7715ga/fota/partial/update.zip] Error 2
Blocks: dolphin
blocking-b2g: --- → 1.4?
Attached file PR for master (obsolete) —
Dave, could you help me review this patch? Thanks!
Assignee: nobody → kli
Attachment #8420169 - Flags: review?(dhylands)
Attached file PR for v1.4 (obsolete) —
Whiteboard: [Dolphin_1.4]
blocking-b2g: 1.4? → 1.4+
Can you provide the recovery.fstab for a device using ubifs? I can't really review this properly without seeing what that file looks like.
Flags: needinfo?(kli)
And how does bug 1007570 impact this one?
Attached file fstab.scx15 (obsolete) —
Hi Dave, now only Dolphin use nand flash with ubifs. Its fstab is attached. Thanks!
Flags: needinfo?(kli)
(In reply to Dave Hylands [:dhylands] (away - back May 16) from comment #4) > And how does bug 1007570 impact this one? I think it's different to bug 1007570.
I think you will need bug 1007570 because attachment 8422147 [details] looks like a Linux fstab file.
My take on this is that bug 1007570 should solve the problem that this bug is trying to solve, but IMHO it does it in a cleaner fashion.
Dave and Gabriele, Thanks! But we still need to have ubifs for B2G_FOTA_FSTYPE. I will update the PR based on bug 1007570 and have ubifs supported.
Sam, could you review and merge this patch?
Flags: needinfo?(sam.hua)
Dave, I updated PR, after Sam merge the patch into their repo, ./build.sh gecko-update-fota and gecko-update-fota-full can work properly for ubifs.
Flags: needinfo?(dhylands)
Comment on attachment 8420169 [details] [review] PR for master I like this much better.
Attachment #8420169 - Flags: review?(dhylands) → review+
Flags: needinfo?(dhylands)
Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S2 (23may)
Depends on: 1007570
Lianxiang, Per our offline discussion, Using 'device/sprd/scx15/nand/fstab.scx15' will casue error in recovery ROM. Need to use 'device/sprd/scx15/nand/recovery.fstab' for dolphin. But the current format of recovery.fstab may cause an error in build fota update.mar. Can you help to update 'device/sprd/scx15/nand/recovery.fstab' in this format? --- /dev/block/platform/../../by-name/system /system ubifs defaults defaults ... Here is also a reference https://github.com/Seinlin/device-mako/blob/b2g-4.4.2_r1/fstab.mako
Status: RESOLVED → REOPENED
Flags: needinfo?(sam.hua) → needinfo?(lianxiang.zhou)
Resolution: FIXED → ---
Whiteboard: [Dolphin_1.4] → [Dolphin_1.4][POVB]
Comment on attachment 8423797 [details] [diff] [review] bug-1008239-set-correct-fstab.diff Obsolete this as it will cause error in recovery ROM.
Attachment #8423797 - Attachment is obsolete: true
(In reply to Kai-Zhen Li from comment #15) > Lianxiang, > > Per our offline discussion, > Using 'device/sprd/scx15/nand/fstab.scx15' will casue error in recovery ROM. > Need to use 'device/sprd/scx15/nand/recovery.fstab' for dolphin. > But the current format of recovery.fstab may cause an error in build fota > update.mar. > > Can you help to update 'device/sprd/scx15/nand/recovery.fstab' in this > format? > --- > /dev/block/platform/../../by-name/system /system ubifs defaults > defaults > ... > > Here is also a reference > https://github.com/Seinlin/device-mako/blob/b2g-4.4.2_r1/fstab.mako On our device, we use ubifs, I can not find any "../by-name/system" in /dev folder. why not change the Android.mk file to parse the 'device/sprd/scx15/nand/recovery.fstab'? diff --git a/Android.mk b/Android.mk index c169929..15a8988 100644 --- a/Android.mk +++ b/Android.mk @@ -381,8 +381,8 @@ define detect-partitions ) $(if $(filter recovery, $(FSTAB_TYPE)), - $(eval B2G_FOTA_SYSTEM_PARTITION := $(shell grep -v '^\#' $(1) | grep '^/system\s\+' | awk '{ print $$3 }')) - $(eval B2G_FOTA_DATA_PARTITION := $(shell grep -v '^\#' $(1) | grep '^/data\s\+' | awk '{ print $$3 }')) + $(eval B2G_FOTA_SYSTEM_PARTITION := $(shell grep -v '^\#' $(1) | perl -ne 'print $$1 if /^(\w+)\s+\/system\s+/ or /^\/system\s+\w+\s+(\w+)/')) + $(eval B2G_FOTA_DATA_PARTITION := $(shell grep -v '^\#' $(1) | perl -ne 'print $$1 if /^(\w+)\s+\/data\s+/ or /^\/data\s+\w+\s+(\w+)/')) ), $(if $(filter ext%, $(B2G_FOTA_FSTYPE)),
Flags: needinfo?(lianxiang.zhou)
Any progress here, can we use Lianxiang's patch?
Attached file recovery.fstab
For dolphin, it needs to use the attached recovery.fstab in order to make the recovery ROM work properly. This file looks like a linux fstab, but it can be recognized by makefile.
Attachment #8422147 - Attachment is obsolete: true
Attached patch Do more check in Makefile (obsolete) — Splinter Review
Dave, do you think it is reasonable to do one more check for the fstab in comment 19?
Attachment #8428563 - Flags: feedback?(dhylands)
(In reply to Kai-Zhen Li from comment #20) > Created attachment 8428563 [details] [diff] [review] > Do more check in Makefile > > Dave, do you think it is reasonable to do one more check for the fstab in > comment 19? Probably, I think we could also simply this check as below. $(if $(FSTAB_FILE), $(eval STARTS_WITH_DEV := $(shell grep '^/dev/' $(1) | grep '/system')) - $(if $(filter /system, $(STARTS_WITH_DEV)), + $(eval STARTS_WITH_NAME := $(shell grep -v '^\#' $(1) | grep -v '^/' | grep '/system')) + $(if $(filter /system, $(STARTS_WITH_DEV) $(STARTS_WITH_NAME)), $(eval FSTAB_TYPE := linux))
Comment on attachment 8428563 [details] [diff] [review] Do more check in Makefile Review of attachment 8428563 [details] [diff] [review]: ----------------------------------------------------------------- So why are you storing this into a variable called STARTS_WITH_DEV ? None of the lines that you're matching start with dev. I think that we really need examples in the comments of the various style of fstab that are being parsed here. We seem to have 3 variants: 1 - style that starts with /dev: /dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait 2 - android style?: /system yaffs2 system 3 - This new style: system /system ubifs defaults defaults Interestingly, all 3 styles share the attribute that the file system comes in the word after the word with /system (as a standalone word) in it.
Attachment #8428563 - Flags: feedback?(dhylands) → feedback-
Yes we need to handle 3 styles. attachment 8428563 [details] [diff] [review] is my WIP, just to verify if my idea does work. STARTS_WITH_DEV is used only one time, that's why I try to reuse it. But this is confused, so I got another solution in comment 21. Finally, I think the code could be as below where style 1 and 3 will be recognized as linux format. --- $(if $(FSTAB_FILE), $(eval STARTS_WITH_DEV := $(shell grep '^/dev/' $(1) | grep '/system')) $(eval STARTS_WITH_NAME := $(shell grep -v '^\#' $(1) | grep -v '^/' | grep '/system')) $(if $(filter /system, $(STARTS_WITH_DEV) $(STARTS_WITH_NAME)), $(eval FSTAB_TYPE := linux)) --- Dave, do you think this is reasonable?
Flags: needinfo?(dhylands)
That looks better :) I'd still like to see a comment with the 3 different styles go into Android.mk
Flags: needinfo?(dhylands)
Dave, Comment is also updated. Could you review this patch? Thanks!
Attachment #8420169 - Attachment is obsolete: true
Attachment #8420170 - Attachment is obsolete: true
Attachment #8429070 - Flags: review?(dhylands)
Attached file Pull request for v1.4 (obsolete) —
Attachment #8429070 - Flags: review?(dhylands) → review+
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
Reopen. As talked in email, we should add tools/update-tools/bin/gonk/update-binary ubifs support.
Status: RESOLVED → REOPENED
Flags: needinfo?(kli)
Resolution: FIXED → ---
Dave, Now update.mar for dolphin can be built but failed to update and the root cause is update-binary can't mount ubifs partition. I think there could be 2 possible solutions, 1. Update tools/update-tools/bin/gonk/update-binary to the one which can support ubifs. 2. Able to define the update-binary used for update.zip in build time. Such as, when a device exports a path of update-binary, tools/update-tools/update_tools.py will use if for update.zip. Do you think which solution is more reasonable?
Flags: needinfo?(kli) → needinfo?(dhylands)
Not a vendor bug. This is a gonk bug.
Whiteboard: [Dolphin_1.4][POVB] → [Dolphin_1.4]
(In reply to Kai-Zhen Li from comment #29) > Dave, > > Now update.mar for dolphin can be built but failed to update and the root > cause is update-binary can't mount ubifs partition. > > I think there could be 2 possible solutions, > > 1. Update tools/update-tools/bin/gonk/update-binary to the one which can > support ubifs. > > 2. Able to define the update-binary used for update.zip in build time. > Such as, when a device exports a path of update-binary, > tools/update-tools/update_tools.py will use if for update.zip. > > Do you think which solution is more reasonable? So where is the source for the update-binary? If the source is in a repo that we control, then I think that 1 makes sense. If the source is not in a repo that we control then I think that 2 is probably more appropriate. Although I tend to favor using command line arguments over environment variables, unless the environment variable is already part of the build.
Flags: needinfo?(dhylands)
Attachment #8435758 - Flags: review?(dhylands)
Attached file Pull request for v1.4
Attachment #8428563 - Attachment is obsolete: true
Attachment #8429070 - Attachment is obsolete: true
Attachment #8429071 - Attachment is obsolete: true
Comment on attachment 8435758 [details] [review] add an option to specify update-binary I think that the calculated path for the prebuilt update-binary is wrong. If I'm wrong, then r+, but otherwise I think that this change would break existing usage.
Attachment #8435758 - Flags: review?(dhylands) → review-
Comment on attachment 8435759 [details] [review] add a new option '--update-bin' for build-tools. I added a comment on the PR about using wildcard.
Attachment #8435759 - Flags: review?(dhylands) → review+
(In reply to Dave Hylands [:dhylands] from comment #36) > Comment on attachment 8435758 [details] [review] > add an option to specify update-binary > > I think that the calculated path for the prebuilt update-binary is wrong. > > If I'm wrong, then r+, but otherwise I think that this change would break > existing usage. I verified when --update-bin is not specified, the pre-built one will be used, 'tools/update-tools/bin/gonk/update-binary'. So this won't break existing usage.
(In reply to Dave Hylands [:dhylands] from comment #37) > Comment on attachment 8435759 [details] [review] > add a new option '--update-bin' for build-tools. > > I added a comment on the PR about using wildcard. PR is updated, I verified it does work properly with/without TARGET_UPDATE_BINARY.
Comment on attachment 8435758 [details] [review] add an option to specify update-binary I added comment in PR, could you review again? Thanks!
Attachment #8435758 - Flags: review- → review?(dhylands)
Comment on attachment 8435758 [details] [review] add an option to specify update-binary I'm happy as long as you tested it. Thanks.
Attachment #8435758 - Flags: review?(dhylands) → review+
In the future, can we please do follow-up work in new bugs? Tracking becomes a real pain when there are multiple landings over a week's time. B2G/master: https://github.com/mozilla-b2g/B2G/commit/b5a208385d0b85531e8f355267b40e7b77966ad1 gonk-misc/master: https://github.com/mozilla-b2g/gonk-misc/commit/dbb66e540194a187326cece28ae0b51cdd500184 gonk-misc/v1.4: https://github.com/mozilla-b2g/gonk-misc/commit/2522872ebf00b768e517c6f18d63a583fd5f5baf
Status: REOPENED → RESOLVED
Closed: 11 years ago10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: 2.0 S3 (6june) → 2.0 S4 (20june)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #42) > In the future, can we please do follow-up work in new bugs? Tracking becomes > a real pain when there are multiple landings over a week's time. > Ryan, Thanks! We should do as you suggested in the future.
(In reply to Kai-Zhen Li from comment #35) > Created attachment 8435767 [details] [diff] [review] > A-sample-to-specify-update-binary-for-update.zip.patch James, this is an example how device specify update-binary for update.zip. Please do not land this patch as I didn't test it. The name of the binary file is not limited to 'update-binary'. Could you help to add one for dolphin? Thanks!
Flags: needinfo?(james.zhang)
But how to build the update-binary? Can you give us the origin source code? Lianxiang said this binray which is built on my side can't work fine.
Flags: needinfo?(james.zhang)
(In reply to James Zhang from comment #45) > But how to build the update-binary? > Can you give us the origin source code? Lianxiang said this binray which is > built on my side can't work fine. The original source is https://android.googlesource.com/platform/bootable/recovery.git In dolphin, The source code is under "bootable/recovery/updater" and it can be built by. $ ./build.sh updater
Blocks: 1047350
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: