Closed Bug 1084041 Opened 10 years ago Closed 10 years ago

Delete files from sdcard after successful FOTA

Categories

(Firefox OS Graveyard :: General, defect, P1)

x86
macOS
defect

Tracking

(tracking-b2g:backlog)

RESOLVED FIXED
tracking-b2g backlog

People

(Reporter: djf, Assigned: gerard-majax)

References

Details

(Whiteboard: [systemsfe])

Attachments

(2 files, 1 obsolete file)

49 bytes, text/x-github-pull-request
gsvelto
: review+
Details | Review
43 bytes, text/x-github-pull-request
gsvelto
: review+
Details | Review
One of our partners points out: "I find that in firefox os, after fota update finished, the update package is not deleted after reboot. As the package is download to internal sdcard, so it would occupy memory, does not look good to the consumer." Dave Hylands confirms: "I don' think that we have any code to do anything with the update.zip, nor the update.mar after a successful fota. So yeah - I think its worth filing a bug"
Alexandre, Dave suggests that you might be a good person to take this bug. I'm setting needinfo to let you know about it.
Flags: needinfo?(lissyx+mozillians)
Whiteboard: [Tako_Blocker]
I think that it makes sense, I'll take this but I'm not sure I can focus on it very soon because we still have some Settings API strange issues to address :(. So, if it's an urgent matter, someone could still steal it. Given that it's not yet marked as blocking 2.1 or 2.2, I get that we have some spare time for it.
Assignee: nobody → lissyx+mozillians
Flags: needinfo?(lissyx+mozillians)
Whiteboard: [Tako_Blocker] → [Tako_Blocker][systemsfe]
[Blocking Requested - why for this release]: partner does have concern on this issue, raise it for 2.1? for triage purpose.
blocking-b2g: --- → 2.1?
Too late to block on this. We will fix on master and uplift based on risk.
blocking-b2g: 2.1? → backlog
Priority: -- → P1
Blocks: 1015367
Flame Kitkat recovery is not working properly, the one from v188 images just spits errors because it cannot find /sdcard.
So we have those files that are staying: > /storage/sdcard0/updates/: > drwxrwxr-x root sdcard_rw 2014-06-06 21:41 0 > drwxrwxr-x root sdcard_rw 2014-10-28 13:30 fota > > /storage/sdcard0/updates//0: > > /storage/sdcard0/updates//fota: > -rwxrwxr-x root sdcard_rw 0 2014-10-28 13:30 precomplete > -rwxrwxr-x root sdcard_rw 62612319 2014-10-28 13:30 update.zip
And we also have: > /data/local/b2g-updates: > -rw-rw-rw- root root 62520942 2014-10-28 14:28 fota-flame-update.mar
Depends on: 1067005
hi Wesly, would you please check this issue mentioned in comment5?
Flags: needinfo?(wehuang)
looks current fixing progress is blocked by 1067055 (on Viral now) and I will discuss w/ him about it.
Flags: needinfo?(wehuang)
Attached file B2G PR (obsolete) —
That's a first try, but until recovery is fixed on KK for Flame, I cannot make sure anything will work as expected. Meanwhile, there's a couple of points to address: - the MAR files includes the name of the device. Maybe we can just trash /data/local/b2g-updates/ ? - I need to make sure we have a reliable way to find the sdcard mount point
hi Wesly, any update for recovery mode?
Flags: needinfo?(wehuang)
Seems this is not for Viral now and I would like to have T2M to look into if can repro. in v188 base image. Hi Alexandre: Would you help put more about your comment#5 above? Did you based on v188 "base image" (no shallow flash Gaia/Gecko) to perform phone reset then get such error? Or other STR?
Flags: needinfo?(wehuang) → needinfo?(lissyx+mozillians)
(In reply to Wesly Huang from comment #12) > Seems this is not for Viral now and I would like to have T2M to look into if > can repro. in v188 base image. > > Hi Alexandre: > > Would you help put more about your comment#5 above? Did you based on v188 > "base image" (no shallow flash Gaia/Gecko) to perform phone reset then get > such error? Or other STR? That's unrelated to Gecko/Gaia flashing: the recovery partition provided with v188 base image spits all those errors on boot of the recovery system. Given the kind of patch we are talking about, I just cannot rely on unreliable recovery.
Flags: needinfo?(lissyx+mozillians)
Depends on: 1095380
Whiteboard: [Tako_Blocker][systemsfe] → [systemsfe]
Hi Alexandre: As the offline discussion before we believe recovery mode should still work & SDcard can be mounted even you flashed own built boot/userdata/system images (as long as recovery image is unchanged). But per vendor's feedback this might not be true, and recommended to get recovery.fstab from v188 base image to your device. Is it work?
See Also: → 1095380
(In reply to Wesly Huang from comment #14) > Hi Alexandre: > > As the offline discussion before we believe recovery mode should still work > & SDcard can be mounted even you flashed own built boot/userdata/system > images (as long as recovery image is unchanged). But per vendor's feedback > this might not be true, and recommended to get recovery.fstab from v188 base > image to your device. Is it work? I don't know. The real issue here is that we cannot build and flash a working recovery ouselves. Please consider this the real priority, everything else is noise and workaround.
Flags: needinfo?(wehuang)
I think Viral and vendor had just clarified yesterday about the issue (dialer crash) which blocks pvt build w/ latest v188 code, so should be soon can have our own build work to proceed, right?
Flags: needinfo?(wehuang)
(In reply to Wesly Huang from comment #16) > I think Viral and vendor had just clarified yesterday about the issue > (dialer crash) which blocks pvt build w/ latest v188 code, so should be soon > can have our own build work to proceed, right? Is it just me or this is just totally unrelated ? I'm asking that we (me) can build and flash our own recovery partition, from our source tree. We can do this currently but the resulting recovery DOES NOT work. That's documented in bug 1067005: everything is blue.
Flags: needinfo?(wehuang)
I mean previously we know there is some code not up to date and will cause problem for pvt build (ex: dialer crash issue), and now get clarified and sync latest code in our side. If recovery issue is also related to old code issue (which is of course my guess) then there could be a chance to proceed now. Anyway I will talk w/ Viral on Monday about 1067005.
Flags: needinfo?(wehuang)
Ok so we now have a recovery that works, I'll be able soon to resume work on this.
So, it looks like the error I experienced on bug 1067005 comment 18 was because of bug 1051191
Depends on: 1051191
Attached file PR for gonk-misc
Attached file B2G PR
Attachment #8515048 - Attachment is obsolete: true
Attachment #8540746 - Flags: review?(mwu)
Attachment #8540746 - Flags: review?(gsvelto)
Attachment #8540749 - Flags: review?(gsvelto)
Comment on attachment 8540746 [details] [review] PR for gonk-misc LGTM.
Attachment #8540746 - Flags: review?(gsvelto) → review+
Comment on attachment 8540749 [details] [review] B2G PR I've left a small nit in the PR but it's looking good anyway.
Attachment #8540749 - Flags: review?(gsvelto) → review+
Comment on attachment 8540746 [details] [review] PR for gonk-misc Gabriele's review on this is sufficient.
Attachment #8540746 - Flags: review?(mwu)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: