Closed Bug 1161190 Opened 9 years ago Closed 6 years ago

[FTE] After full flash, FTU may be skipped and smart collections display placeholder icons, breaks

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-master affected)

RESOLVED WONTFIX
Tracking Status
b2g-master --- affected

People

(Reporter: onelson, Unassigned, NeedInfo)

References

Details

(Whiteboard: [3.0-Daily-Testing], [systemsfe])

Attachments

(6 files)

Description:
When a tester performs a full flash (using our flash.sh script on phone-assets pulled from the pvt site), they may observe a bad flash. In this case, the FTU is not observed and user is brought directly to the homescreen. From here, the smart collections are replaced with placeholder 'Rocketship' icons, no name, and lead to an empty, un-named smart collection UI.


Repro Steps:
1) Update a Flame to 20150501010203
2) Observe homescreen.


Actual:
FTU is skipped, smart collection icons are placeholder

Expected:
FTU is reached after flash, homescreen observes standard behavior


Environmental Variables:
Device: Flame 3.0
Build ID: 20150501010203
Gaia: 759a1f935a6a81c32ad66e39a6353b334dfa4f91
Gecko: 7723b15ea695
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0



Repro frequency: 3/20
See attached: 
screenshot
logcat
flash script
Attached image 2015-05-04-12-19-07.png
Attached file flash.sh
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Summary: [FTE After full flash, FTU may be skipped and smart collections display placeholder icons, break → [FTE] After full flash, FTU may be skipped and smart collections display placeholder icons, breaks
Whiteboard: [3.0-Daily-Testing], [systemsfe]
It seems like the failure might be before the logcat starts. Can you try to get the logcat from the beginning next time you see this issue?
Flags: needinfo?(onelson)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Just saw this issue and pulled a log immediately upon noticing. Granted, the log wasn't started 'before' the issue was observed, but I'm not sure that's possible from our method of flashing. This may be the earliest we're able to find a logcat, let me know if it helps.
Flags: needinfo?(onelson) → needinfo?(anygregor)
Seems bad if we have random initial startup problems. Maybe related to 1151672?
Blocks: 1151672
Flags: needinfo?(anygregor)
Alright, final logcat. 
I encountered this issue 3x in a row attempting to flash to today's nightly [20150508010203]. I ran a logcat before flashing the phone, which had paused the log. Sometime between the 'Thundersoft' logo being on screen it began picking up again.
Flags: needinfo?(anygregor)
(In reply to Oliver Nelson [:oliverthor] from comment #6)
> Created attachment 8603368 [details]
> logcat_20150508_0819_flasherror.txt
> 
> Alright, final logcat. 
> I encountered this issue 3x in a row attempting to flash to today's nightly
> [20150508010203]. I ran a logcat before flashing the phone, which had paused
> the log. Sometime between the 'Thundersoft' logo being on screen it began
> picking up again.

Thanks! There are some bad things in there but nothing should break us in such a bad way.

Lets exclude memory related issues first.
This issue is also present on full memory devices and not only on 319mb configurations right?
Flags: needinfo?(anygregor) → needinfo?(onelson)
One of my coworkers mentioned that he observed the flash issue on the Aries device, which has considerably more memory, 2 gigs from what I've heard. This was seen yesterday I believe, no log at the moment.

I believe the last logcat I attached was conducted from a 512mb device [attachment 8603368 [details] / logcat*flasherror*]. This has definitely been observed on 319mb devices though.

Moved my memory to full on flame [adb reboot-bootloader -> fastboot oem mem 0 : mem: auto]. Attaching logcat of flash observed on this device. Took me a handful of flashes to get this to finally repro, not sure if that indicates memory could 'aid' in preventing the issue or not.
Flags: needinfo?(onelson) → needinfo?(anygregor)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: