Logs from the device.
https://drive.google.com/a/google.com/folderview?id=0Bx12NVyIouI0LXVReVpzY2FSV0k&usp=sharing


[0313/153231:INFO:omaha_request_action.cc(841)] Received omaha response to update to version 7647.84.0
[0313/153231:INFO:connection_manager.cc(135)] Current connection is confirmed tethered, using Cellular setting.
[0313/153231:INFO:connection_manager.cc(111)] Disabling updates over cellular connection as there's no device policy setting nor user preference present.
[0313/153231:INFO:omaha_request_action.cc(1468)] We are connected via wifi, Updates allowed: No
[0313/153231:INFO:omaha_request_action.cc(1443)] Update is not allowed over current connection.

Cyrus: interestingly the device just got the 48 update. 
Not sure what triggered it.

perhaps device got connected via wifi (e.g. working as expected) 

Lets check with cyrus if it was ever connected over a tethered network. 

The first update check is after 44 days of no checks:
[0313/153104:INFO:metrics.cc(156)] Sending 44d4h36m39.257142s for metric UpdateEngine.Check.TimeSinceLastCheckMinutes

...and then there are 4 other interactive checks every ~20 seconds. It looks like the network we were connected to was being detected as tethering, maybe the shill logs have more details about why.

I definitely was not on a tethered network of any kind.  And yes, it had been many days of no checks.  I pulled this device off my shelf and wanted to update it - clicked check for updates at least 5 times, even restarted, tried again, and nothing.  This doesn't seem to good.  Do we have other reports of this happening in the field?  Shouldn't the 'check for available updates' button be fully reliable?  I've seen this on previous version of CrOS for many years, i.e. that button not only isn't fully reliable (clicking it first 5 times will do nothing but 6th time will do something) but we don't even give the user any feedback about what's going on. :(

Also, whether or not device is tethered, why would we change how updating works.  Why would we not want to update on tether?  Some users *only* use tethering now that tethering / hotspots is becoming so common (unlimited data plans make this a very realistic mode of operation) so I think we should remove any such logic that blocks updates that way.

This was a specific FR at the time to not update on cellular networks (including tethered), and why we built tethering detection logic in the first place.  Since an update can be 400MB+ in the case of a full update, the right answer here involves some UI that lets the user inform on which networks should be used for updates.

Flaky "check for updates" should be investigated - it is supposed to skip all policy checks.  If it *is* skipping policy checks, then it may be a UI/backend integration race condition.

Closing this as WontFix.  

The "interactive" update check (user-initiated) skips the policies that introduce a delay (that is, it won't wait 45 minutes to check for an update, it won't wait for several days to spread the download if enterprise enforced that; it won't do that many reconnect attempts). However, it will honor the cellular network checking settings.

There's a recent bug and a UI proposal to add a message on that page saying why it didn't update; and there's another stale bug about enable/disable the download over cellular UI setting.

Re #7, there could be a bug in the way we detect this wifi as a hotspot; you should check with shill people on whether that's the case.