999366 - check for updates: daily doesn't check

Status: RESOLVED INVALID

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

Description

[Natalia Martinez-Winter]

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

Comment 1

[Jason Smith [:jsmith]]

Can someone else confirm this?

Comment 2

[Preeti Raghunath(:Preeti)]

Looking to see if this is reproducible.

Comment 3

[Gregor Wagner [:gwagner]]

Alex, have you seen this before?

Comment 4

[:gerard-majax]

Nope, it's Natalia who told me about this: she noticed not getting any update notification until rebooting the device.

Comment 5

[Natalia Martinez-Winter]

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).

Comment 6

[Gregor Wagner [:gwagner]]

Alex will take a look.

Comment 7

[Natalia Martinez-Winter]

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 )

Comment 8

[Natalia Martinez-Winter]

Attachment: checking_for_updates_status_bug

Comment 9

[Rachel Pribble [:rpribble]]

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 10

[:gerard-majax]

Natalia, can you remind me what version you have ?

I think I'm going to try some hack with the update interval ....

Comment 11

[Natalia Martinez-Winter]

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

Comment 12

[:gerard-majax]

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.

Comment 13

[:gerard-majax]

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.

Comment 14

[:gerard-majax]

Forget what I said, after forcing the setting on Gaia side, I see updates checks.

Comment 15

[:gerard-majax]

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'.

Comment 16

[:gerard-majax]

Natalia, I'd like to make sure of one thing: is your device sleeping a lot ?

Comment 17

[:gerard-majax]

On my Flame, when the device is sleeping, no update check is performed.

Comment 18

[:gerard-majax]

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).

Comment 19

[William Hsu [:whsu]]

(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".

Comment 20

[Natalia Martinez-Winter]

yes, my device is almost all the time in sleep mode except : when I receive sms, calls and sync emails.

Comment 21

[:gerard-majax]

Natalia, do you have news ? Did the issue finally reproduced ?

Comment 22

[Natalia Martinez-Winter]

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...

Comment 23

[:gerard-majax]

Okay, get me some files by issuing:
 - adb pull /cache/recovery/last_log
 - adb pull /mnt/sdcard/logcat.log

Comment 24

[:gerard-majax]

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.

Comment 25

[:gerard-majax]

Jason, can you have a look at comment 15 ? I really need feedback to assess whether this is a legitimate case or not ...

Comment 26

[Jason Smith [:jsmith]]

QA Wanted to address comment 15. Also, does this happen on Flame right now?

Comment 27

[Joshua Mitchell (Inactive)]

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

Comment 28

[:gerard-majax]

(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?

Comment 29

[Joshua Mitchell (Inactive)]

Attachment: Logcat with grepping on 'AUS:SVC

Comment 30

[:gerard-majax]

Okay, sorry, firing too fast.

Comment 31

[:gerard-majax]

(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.

Comment 32

[Joshua Mitchell (Inactive)]

(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

Comment 33

[Jason Smith [:jsmith]]

(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.

Comment 34

[Joshua Mitchell (Inactive)]

(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.

Comment 35

[Jason Smith [:jsmith]]

Dave - When is the periodic check for system updates supposed to fire initially? It's right after you complete the FTE, right?

Comment 36

[:gerard-majax]

(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).

Comment 37

[Jason Smith [:jsmith]]

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?

Comment 38

[Joshua Mitchell (Inactive)]

(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

Comment 39

[:gerard-majax]

(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.

Comment 40

[Jason Smith [:jsmith]]

(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.

Comment 41

[Joshua Mitchell (Inactive)]

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

Comment 42

[Joshua Mitchell (Inactive)]

Attachment: Logcat with grepping on 'AUS:SVC

Comment 43

[:gerard-majax]

(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.

Comment 44

[:gerard-majax]

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

Comment 45

[:gerard-majax]

(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 ...

Comment 46

[:gerard-majax]

(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.

Comment 47

[Jan Keromnes [:janx]]

(url problem was not caused by bug #995206)

Comment 48

[:gerard-majax]

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

Comment 49

[John Thomas [:Johnt]]

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.

Comment 50

[KTucker [:KTucker][Inactive 3/4/2016]]

There is a test case in moztrap to cover automatic updates:

https://moztrap.mozilla.org/manage/case/14376/