Closed Bug 999366 Opened 10 years ago Closed 10 years ago

check for updates: daily doesn't check

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

RESOLVED INVALID
2.0 S3 (6june)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- affected

People

(Reporter: nwinter, Assigned: gerard-majax)

References

()

Details

(Whiteboard: [systemsfe], OpenCrun1.4-3, [2.0-flame-test-run-1])

Attachments

(2 files, 1 obsolete file)

I have Check for updates in Device information set to 'daily'

I am not being offered updates at all. I have no notifications that a new update is available. I only get a notification if I manually tap 'check now'. or when device is restarted, I get a notification for update.

Expected: I should get a notification on any day when an update is available

Alcatel One Touch Fire 
Buri 1.4 pre-release
BI : 20140411000202
Git commit info : 2014-04_11 03:40:46 6c50349f
blocking-b2g: --- → 1.4?
Can someone else confirm this?
Keywords: qawanted
Looking to see if this is reproducible.
blocking-b2g: 1.4? → 1.4+
Alex, have you seen this before?
Flags: needinfo?(lissyx+mozillians)
Nope, it's Natalia who told me about this: she noticed not getting any update notification until rebooting the device.
Flags: needinfo?(lissyx+mozillians) → needinfo?(nwinter)
I'm currently unable to update my device at all (when I click "download" for system update, the screen goes back to the notification screen). So I still have an "old" notification (which only appeared because I checked manually).
Flags: needinfo?(nwinter)
Alex will take a look.
Assignee: nobody → lissyx+mozillians
Whiteboard: [systemsfe]
Target Milestone: --- → 2.0 S1 (9may)
I tried "check now" and I received the notification but in the settings menu, the text got blocked to "Checking for updates...". See attachment. (and update did not work )
This issue also occurs on the Open_C v1.4 MOZ ril.

Environmental Variables:
Device: Open_C v1.4 MOZ ril
BuildID: 20140502000201
Gaia: 7b2b82d72cbdd1c7e0f4542cb3390802e65f473e
Gecko: 50be03cea340
Version: 30.0
Firmware Version: v1.2-device.cfg

No new update notification in seen, even after factory reset or reboot.
Whiteboard: [systemsfe] → [systemsfe], OpenCrun1.4-3
Natalia, can you remind me what version you have ?

I think I'm going to try some hack with the update interval ....
Flags: needinfo?(nwinter)
this is my last version (since it's not checking...and I did not click on "check now") :
my current 1.4 build :
build id : 20140428000206
git commit info : 2014-04-26 20:43:18
d23e479e
Flags: needinfo?(nwinter)
Custom gecko master on Flame, with app.update.interval forced to 60.

Then, 

> $ adb logcat -b threadtime | egrep 'AUS:SVC'

This shows update check at boot, when network if offline, then another check once network is online (HSDPA). Update URL is http://update.boot2gecko.org/nightly-flame/update.xml which does not exists, hence we get a 404.

After a couple of minutes, without any sleep for sure (USB connected), no more check have been performed.
05-09 15:44:49.685  1998  1998 E GeckoConsole: UTM:SVC TimerManager:registerTimer - id: user-agent-updates-timer :: 604800

While I have hardcoded app.update.interval to 60 and the setting displayed in the Settings app is switched on Daily.
Forget what I said, after forcing the setting on Gaia side, I see updates checks.
Rachel, can you check on master for Open C ?

Also, could you make sure that your device has network, that update url and channel are correct, and that it can perform network requests ?

We are interested in logcat output that would be filtered by grepping on 'AUS:SVC'.
Flags: needinfo?(rpribble)
Natalia, I'd like to make sure of one thing: is your device sleeping a lot ?
Flags: needinfo?(nwinter)
On my Flame, when the device is sleeping, no update check is performed.
Natalia, I will need that you perform some logging. First, make sure your sdcard is big enough (I see something like 500k logs produced in 5 minutes), so if we consider 1M log per minute, over two days, it makes ~3GB.

Then, shut down WiFi and data, reboot your device. Make sure you have root access on the device: |adb shell| should show you "root@android:/#". If you dont have root, issue |adb root| and then get a shell again.

Once you have adb shell as root, please issue:
> daemonize -f /mnt/sdcard/logcat.log logcat -v threadtime -b main

This should start a daemonized process probbing all your logcat to /mnt/sdcard/logcat.log. Let it run for more than one day, make sure you use your device as always (wifi, data).
(In reply to Rachel Pribble from comment #9)
> This issue also occurs on the Open_C v1.4 MOZ ril.
> 
> Environmental Variables:
> Device: Open_C v1.4 MOZ ril
> BuildID: 20140502000201
> Gaia: 7b2b82d72cbdd1c7e0f4542cb3390802e65f473e
> Gecko: 50be03cea340
> Version: 30.0
> Firmware Version: v1.2-device.cfg
> 
> No new update notification in seen, even after factory reset or reboot.

Comment 9 made the confirmation.
Remove the "qawanted".
Keywords: qawanted
yes, my device is almost all the time in sleep mode except : when I receive sms, calls and sync emails.
Flags: needinfo?(nwinter)
Target Milestone: 2.0 S1 (9may) → 2.0 S2 (23may)
Natalia, do you have news ? Did the issue finally reproduced ?
Flags: needinfo?(nwinter)
so : daily still doesn't check.
I tried today to "check now". an update has been found, the file has been downloaded, processed, the device rebooted. But then I had the orange screen (with ! red warning) then when the device booted the update did not apply. got the notification that an update is avaialble... 
I'm still on build from 29th of April...
Flags: needinfo?(nwinter)
Okay, get me some files by issuing:
 - adb pull /cache/recovery/last_log
 - adb pull /mnt/sdcard/logcat.log
Flags: needinfo?(nwinter)
Okay so far the logs were not really conclusive at all. This device has a very spurious behavior. I will try some other checking on other device, but this will probably result in a RESOLVED:INVALID.
Flags: needinfo?(nwinter)
Jason, can you have a look at comment 15 ? I really need feedback to assess whether this is a legitimate case or not ...
Flags: needinfo?(jsmith)
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
Flags: needinfo?(rpribble)
QA Wanted to address comment 15. Also, does this happen on Flame right now?
Flags: needinfo?(jsmith)
Keywords: qawanted
QA Contact: jmitchell
This issue DOES occur on the Flame device; The device is not offered an update and when selecting "check now" I receive a message "There was an error when checking for updates".

Environmental Variables:
Device: Flame 2.0
BuildID: 20140520133107
Gaia: c462d9183d294a2d8ecc472f593ea8cfa15bc9de
Gecko: 9d8d16695f6a
Version: 32.0a1
Firmware Version: V10G-2
(In reply to Joshua Mitchell from comment #27)
> This issue DOES occur on the Flame device; The device is not offered an
> update and when selecting "check now" I receive a message "There was an
> error when checking for updates".
> 
> Environmental Variables:
> Device: Flame 2.0
> BuildID: 20140520133107
> Gaia: c462d9183d294a2d8ecc472f593ea8cfa15bc9de
> Gecko: 9d8d16695f6a
> Version: 32.0a1
> Firmware Version: V10G-2

How many times do I have to ask for the output of logcat to know what happens?
Flags: needinfo?(jsmith)
Flags: needinfo?(jmitchell)
Okay, sorry, firing too fast.
Flags: needinfo?(jsmith)
Flags: needinfo?(jmitchell)
(In reply to Joshua Mitchell from comment #29)
> Created attachment 8429496 [details]
> Logcat with grepping on 'AUS:SVC

It does not expose an issue at all: update is checked and the update URL is not valid.
(In reply to Alexandre LISSY :gerard-majax from comment #15)
> Rachel, can you check on master for Open C ?
> 
> Also, could you make sure that your device has network, that update url and
> channel are correct, and that it can perform network requests ?
> 
> We are interested in logcat output that would be filtered by grepping on
> 'AUS:SVC'.


This issue DOES reproduce on a recent master Open-C build
Environmental Variables:
Device: Open_C 2.0
BuildID: 20140524043004
Gaia: f3b5d74dd3428c89cab06db734c62f3c9dbb8c4d
Gecko: e86a0d92d174
Version: 32.0a1
Firmware Version: P821A10V1.0.0B06_LOG_DL

The Devices are successfully connected to wi-fi, and the following information is the default for BOTH Open-C and Flame - 

Update channel: flame/2.0.0/default
Update URL: http://update.boot2gecko.org/%CHANNEL%/update.xml
Keywords: qawanted
(In reply to Joshua Mitchell from comment #27)
> This issue DOES occur on the Flame device; The device is not offered an
> update and when selecting "check now" I receive a message "There was an
> error when checking for updates".
> 
> Environmental Variables:
> Device: Flame 2.0
> BuildID: 20140520133107
> Gaia: c462d9183d294a2d8ecc472f593ea8cfa15bc9de
> Gecko: 9d8d16695f6a
> Version: 32.0a1
> Firmware Version: V10G-2

That isn't what the bug is talking about. This bug is talking about the fact that periodic checks for system updates aren't working.
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #33)
> (In reply to Joshua Mitchell from comment #27)
> > This issue DOES occur on the Flame device; The device is not offered an
> > update and when selecting "check now" I receive a message "There was an
> > error when checking for updates".
> > 

> That isn't what the bug is talking about. This bug is talking about the fact
> that periodic checks for system updates aren't working.

Sorry, I should not have mentioned the "check now" info as that appears to have caused some confusion.
 My tests and results were from not receiving a notification for updates (after resetting the device and also waiting 10-15 minutes of it being connected) as initially stated by the reporter.
Keywords: qawanted
Dave - When is the periodic check for system updates supposed to fire initially? It's right after you complete the FTE, right?
Flags: needinfo?(dhylands)
(In reply to Jason Smith [:jsmith] from comment #35)
> Dave - When is the periodic check for system updates supposed to fire
> initially? It's right after you complete the FTE, right?

I think that you need to have completed FTU and then of course have data connectivity (3G or WiFi).
I'm really confused on the testing here then. Can we do the following:

1. Flash an old Flame build (yesterday)
2. In FTE, enable wifi
3. Complete the FTE
4. Wait a few minutes

Do you get a notification for a system update?
Flags: needinfo?(dhylands)
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #37)

> 1. Flash an old Flame build (yesterday)
> 2. In FTE, enable wifi
> 3. Complete the FTE
> 4. Wait a few minutes
> 
> Do you get a notification for a system update?

No, I do NOT get a notification for a system update.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140528013006
Gaia: bc6f07c149770c6e6dfbea941ac65138dc364a15
Gecko: d6407e1bc732
Version: 32.0a1
Firmware Version: V10G-2
Keywords: qawanted
(In reply to Joshua Mitchell from comment #38)
> (In reply to Jason Smith [:jsmith] from comment #37)
> 
> > 1. Flash an old Flame build (yesterday)
> > 2. In FTE, enable wifi
> > 3. Complete the FTE
> > 4. Wait a few minutes
> > 
> > Do you get a notification for a system update?
> 
> No, I do NOT get a notification for a system update.
> 
> Environmental Variables:
> Device: Flame 2.0
> BuildID: 20140528013006
> Gaia: bc6f07c149770c6e6dfbea941ac65138dc364a15
> Gecko: d6407e1bc732
> Version: 32.0a1
> Firmware Version: V10G-2

Unless proved otherwise with the output of logcat, this is totally inconclusive. Comment 32 alreday reported this behavior with a WRONG update URL. It's totally expected that there is no update notification when the URL is wrong.
Flags: needinfo?(jsmith)
Flags: needinfo?(jmitchell)
(In reply to Alexandre LISSY :gerard-majax from comment #39)
> (In reply to Joshua Mitchell from comment #38)
> > (In reply to Jason Smith [:jsmith] from comment #37)
> > 
> > > 1. Flash an old Flame build (yesterday)
> > > 2. In FTE, enable wifi
> > > 3. Complete the FTE
> > > 4. Wait a few minutes
> > > 
> > > Do you get a notification for a system update?
> > 
> > No, I do NOT get a notification for a system update.
> > 
> > Environmental Variables:
> > Device: Flame 2.0
> > BuildID: 20140528013006
> > Gaia: bc6f07c149770c6e6dfbea941ac65138dc364a15
> > Gecko: d6407e1bc732
> > Version: 32.0a1
> > Firmware Version: V10G-2
> 
> Unless proved otherwise with the output of logcat, this is totally
> inconclusive. Comment 32 alreday reported this behavior with a WRONG update
> URL. It's totally expected that there is no update notification when the URL
> is wrong.

I don't see how that could be correct. We know OTA updates are working right now with Flame on trunk right now, so this shouldn't be a general update problem. We can get an updated logcat here though.
Flags: needinfo?(jsmith)
Keywords: qawanted
Attaching an update logcat, gripped to AUS:SVC, of a repro of this bug.

Update Channel: nightly
Update URL: aus4.mozilla.org/update/3/%Product%/%version%/%build_id%/%Product_Device%/%Locale%/%Channel%/%OS_Version%/%Distribution%/%Distribution_Version%/Update.xml

(this is the default information; if this is incorrect and there is a specific channel or URL you are wanting to see here, please provide it and I will gladly plug it in and get another logcat asap)

Environmental Variables:
Device: Flame 2.0
BuildID: 20140530073009
Gaia: d904b0a8b6992c0041dcc9480a116d291fe8d3b2
Gecko: 2208a2ed9745
Version: 32.0a1
Firmware Version: v10G-2
Flags: needinfo?(jmitchell)
Attachment #8429496 - Attachment is obsolete: true
Keywords: qawanted
(In reply to Joshua Mitchell from comment #41)
> Attaching an update logcat, gripped to AUS:SVC, of a repro of this bug.
> 
> Update Channel: nightly
> Update URL:
> aus4.mozilla.org/update/3/%Product%/%version%/%build_id%/%Product_Device%/
> %Locale%/%Channel%/%OS_Version%/%Distribution%/%Distribution_Version%/Update.
> xml
> 
> (this is the default information; if this is incorrect and there is a
> specific channel or URL you are wanting to see here, please provide it and I
> will gladly plug it in and get another logcat asap)
> 
> Environmental Variables:
> Device: Flame 2.0
> BuildID: 20140530073009
> Gaia: d904b0a8b6992c0041dcc9480a116d291fe8d3b2
> Gecko: 2208a2ed9745
> Version: 32.0a1
> Firmware Version: v10G-2

The URL you give in the comment and the one I see in the log do not match. Moreover, the one in the log is still false.
Flags: needinfo?(jmitchell)
Flags: needinfo?(janx)
Setting needinfo? on Natalia since she now have a 2.0 hamachi and claim she may still be reproducing. Natalia, let's see on Wednesday how it goes :)
Flags: needinfo?(nwinter)
(In reply to Alexandre LISSY :gerard-majax from comment #43)
> (In reply to Joshua Mitchell from comment #41)
> > Attaching an update logcat, gripped to AUS:SVC, of a repro of this bug.
> > 
> > Update Channel: nightly
> > Update URL:
> > aus4.mozilla.org/update/3/%Product%/%version%/%build_id%/%Product_Device%/
> > %Locale%/%Channel%/%OS_Version%/%Distribution%/%Distribution_Version%/Update.
> > xml
> > 
> > (this is the default information; if this is incorrect and there is a
> > specific channel or URL you are wanting to see here, please provide it and I
> > will gladly plug it in and get another logcat asap)
> > 
> > Environmental Variables:
> > Device: Flame 2.0
> > BuildID: 20140530073009
> > Gaia: d904b0a8b6992c0041dcc9480a116d291fe8d3b2
> > Gecko: 2208a2ed9745
> > Version: 32.0a1
> > Firmware Version: v10G-2
> 
> The URL you give in the comment and the one I see in the log do not match.
> Moreover, the one in the log is still false.

I was not looking at the correct log.

This URL is now correct:
> 06-04 06:58:11.653: E/GeckoConsole(325): AUS:SVC Checker:checkForUpdates - sending request to: https://aus4.mozilla.org/update/3/B2G/32.0a1/20140530073009/msm8610/en-US/nightly/Boot2Gecko%202.0.0.0-prerelease/default/default/update.xml?force=1

But there is just no update available.
> 06-04 06:58:13.593: I/Gecko(325): *** AUS:SVC Checker:onLoad - number of updates available: 0

So it makes totally sense we have no update notification ...
(In reply to Alexandre LISSY :gerard-majax from comment #45)
> (In reply to Alexandre LISSY :gerard-majax from comment #43)
> > (In reply to Joshua Mitchell from comment #41)
> > > Attaching an update logcat, gripped to AUS:SVC, of a repro of this bug.
> > > 
> > > Update Channel: nightly
> > > Update URL:
> > > aus4.mozilla.org/update/3/%Product%/%version%/%build_id%/%Product_Device%/
> > > %Locale%/%Channel%/%OS_Version%/%Distribution%/%Distribution_Version%/Update.
> > > xml
> > > 
> > > (this is the default information; if this is incorrect and there is a
> > > specific channel or URL you are wanting to see here, please provide it and I
> > > will gladly plug it in and get another logcat asap)
> > > 
> > > Environmental Variables:
> > > Device: Flame 2.0
> > > BuildID: 20140530073009
> > > Gaia: d904b0a8b6992c0041dcc9480a116d291fe8d3b2
> > > Gecko: 2208a2ed9745
> > > Version: 32.0a1
> > > Firmware Version: v10G-2
> > 
> > The URL you give in the comment and the one I see in the log do not match.
> > Moreover, the one in the log is still false.
> 
> I was not looking at the correct log.
> 
> This URL is now correct:
> > 06-04 06:58:11.653: E/GeckoConsole(325): AUS:SVC Checker:checkForUpdates - sending request to: https://aus4.mozilla.org/update/3/B2G/32.0a1/20140530073009/msm8610/en-US/nightly/Boot2Gecko%202.0.0.0-prerelease/default/default/update.xml?force=1
> 
> But there is just no update available.
> > 06-04 06:58:13.593: I/Gecko(325): *** AUS:SVC Checker:onLoad - number of updates available: 0
> 
> So it makes totally sense we have no update notification ...

And actually, this URL is wrong but it's not your fault: it contains a PRODUCT_DEVICE value of msm8610 which is not working, as documented in bug 1018276. The proper URL for the Flame being https://aus4.mozilla.org/update/3/B2G/32.0a1/20140530073009/flame/en-US/nightly/Boot2Gecko%202.0.0.0-prerelease/default/default/update.xml?force=1 and this one does have an update available.
Depends on: 1018276
(url problem was not caused by bug #995206)
Flags: needinfo?(janx)
Flags: needinfo?(jmitchell)
Whiteboard: [systemsfe], OpenCrun1.4-3 → [systemsfe], OpenCrun1.4-3, [2.0-flame-test-run-1]
After checking multiple times with Natalia, we are unable to get a consistent answer on this. There is too much things not working properly on this device to consider it may be okay.

I'm closing as INVALID. If anyone can reproduce this consistently, then reopen :)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Flags: needinfo?(nwinter)
This test case appears to be invalid as a wrong url was being applied which resulted in no updates or notifications occurring on the devices.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(jthomas)
There is a test case in moztrap to cover automatic updates:

https://moztrap.mozilla.org/manage/case/14376/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(jthomas)
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: