New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 759855 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Last visit > 30 days ago
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 0
Type: Bug



Sign in to add a comment

ChromeOS issue: Panther stuck in old ChromeOS version

Project Member Reported by kotah@chromium.org, Aug 28 2017

Issue description

ChromeOS version: 48.0.2564.116 (7647.84.0)
ChromeOS device model: Panther
Case# 13522074

Description:
Panther doesn't update to the latest stable version ChromeOS M59, and is stuck with M48. Snippet of update_engine.log:

[0828/094001:INFO:omaha_request_action.cc(641)] Request: <?xml version="1.0" encoding="UTF-8"?>
<request protocol="3.0" version="ChromeOSUpdateEngine-0.1.0.0" updaterversion="ChromeOSUpdateEngine-0.1.0.0" installsource="ondemandupdate" ismachine="1">
    <os version="Indy" platform="Chrome OS" sp="7647.84.0_x86_64"></os>
    <app appid="{C0E4276B-35C7-023D-BB4A-42D642B91E65}" cohort="1:4/1a:" cohortname="panther_stable_canaryrelease_9592.85.0" version="7647.84.0" track="stable-channel" lang="en-US" board="panther-signed-mpkeys" hardware_class="PANTHER F5Z-D3A-A2E" delta_okay="true" fw_version="" ec_version="" installdate="3892" >
        <updatecheck targetversionprefix=""></updatecheck>
    </app>
</request>

...

[0828/094001:INFO:libcurl_http_fetcher.cc(294)] HTTP response code: 200
[0828/094001:INFO:libcurl_http_fetcher.cc(370)] Transfer completed (200), 314 bytes downloaded
[0828/094001:INFO:omaha_request_action.cc(897)] Omaha request response: <?xml version="1.0" encoding="UTF-8"?><response protocol="3.0" server="prod"><daystart elapsed_days="3892" elapsed_seconds="34801"/><app appid="{C0E4276B-35C7-023D-BB4A-42D642B91E65}" cohort="1:4/1a:" cohortname="panther_stable_canaryrelease_9592.85.0" status="ok"><updatecheck status="noupdate"/></app></response>
[0828/094001:INFO:omaha_request_action.cc(1369)] Storing new setting omaha-cohort as 1:4/1a:
[0828/094001:INFO:omaha_request_action.cc(1369)] Storing new setting omaha-cohort-name as panther_stable_canaryrelease_9592.85.0
[0828/094001:INFO:omaha_request_action.cc(770)] No update.

We have similar reports from other customers. I will add more logs if we hear from other customers too.

Drive link to logs: https://drive.google.com/open?id=0B3B7SKCSXU4SblZNckwyNWhwNzg
 

Comment 1 by roy...@google.com, Aug 28 2017

Labels: -Pri-1 Pri-0

Comment 2 by roy...@google.com, Aug 28 2017

Labels: Proj-Hotrod
Cc: moisesos...@chromium.org
Labels: M-60
Status: Started (was: Assigned)
Seems like the client is pinging the internal fraction cohort -> cohortname="panther_stable_canaryrelease_9592.85.0" 

Moises, we have an internal push for CfM and it seems like clients are pinging that when they should not (e.g. it is set as internal). They should be pinging the M59 rules 




Cc: abutzier@chromium.org
So the problem is all rules are internal only but the cohort is not, so users ping and enter the cohort but don't get updates. I filed an internal bug (http://b/65127353) for this and made it a P0 as it seems to affect several devices.
I can evaluate removing the internal rules in the meantime to fix this case... 
Status: Fixed (was: Started)
Internal rules are now off
AU should work now 

Let's track omaha internal cohort support in b/ bug 

Comment 8 by roy...@google.com, Aug 29 2017

The short term impact should be resolved. 
- If there are more incidents please report here
- The work on the buganizer bug will continue to fix the root cause.

Comment 9 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment