The device was offered 58:
[0721/025510:INFO:omaha_request_action.cc(914)] Omaha request response: <?xml version="1.0" encoding="UTF-8"?><response protocol="3.0" server="prod"><daystart elapsed_days="3854" elapsed_seconds="10510"/><app appid="{23F5C60F-7655-4BF4-90FB-BFDE16408308}" cohort="1:5:" cohortname="x86-zgb-he_dev" status="ok"><updatecheck _eol="eol" status="ok"><urls><url codebase="<URL: 14>"/><url codebase="<URL: 15>"/></urls><manifest version="9334.18.0"><actions><action event="update" run="chromeos_9334.18.0_x86-zgb-he_dev-channel_full_zgb-mp-v3.bin-7c7bcd3c83db5022ff3edf749ad83e37.signed"/><action ChromeOSVersion="9334.18.0" ChromeVersion="58.0.3029.31" IsDelta="true" IsDeltaPayload="false" MaxDaysToScatter="14" MetadataSignatureRsa="q9HWdTYbPolRvqdUbj8Xpm+02GoA1RCyvNpbua3KgTI0oouZBtWlCDeXJxE1CmsBENvbi4EAhgyVC0aNtPTokA3nd2JtwRINryWDL7p4H0Nd7l66IFTKDMkQi/nyuJol29jd6mWf1h9rK0Fc9MBH6Y1NEEZYP+8caRqUaiBMy+4Ll2auDzUROWwuwJthNba8JslcW+BR/Jx4WXEHUSz9ZHB5kI9Y5HwVYVks+NY+v3QZGZKWmrx7vQ5PEhD5ipgFsnvsi9m9vB0r2Ds1vbBUoHOdBMKh3BZ7nSGTmIvwgEXhAZlCrJcyGkpbSIzgLsJgMwdc7uM9gQnt06Ld+9p6Iw==" MetadataSize="35665" event="postinstall" sha256="W8j/mecGMEY6zpeDqBVuvx/M9xGdwwh8EXrHmGWkG6U="/></actions><packages><package fp="1.5bc8ff99e70630463ace9783a8156ebf1fccf7119dc3087c117ac79865a41ba5" hash="Vi1Yhfz/KT1lOtOTUjU+C2JweCw=" hash_sha256="5bc8ff99e70630463ace9783a8156ebf1fccf7119dc3087c117ac79865a41ba5" name="chromeos_9334.18.0_x86-zgb-he_dev-channel_full_zgb-mp-v3.bin-7c7bcd3c83db5022ff3edf749ad83e37.signed" required="true" size="525643404"/></packages></manifest></updatecheck><event status="ok"/></app></response>

but chose to ignore it until OOBE completed:

[0721/025510:INFO:omaha_request_action.cc(1046)] Ignoring non-critical Omaha updates until OOBE is done.

can you complete OOBE and try again?

(OOBE is considered completed once the device is either:

a) enterprise enrolled (owned by domain)
b) logged in by a regular user who then become device owner

Jay, thanks for your comments! I don't think the problem is related to OOBE not being finished, since according to [1] .oobe_completed is also triggered by guest login. (I've tested and confirmed that on a separate device.)

Also, I tried logging in with a real user and I still get the same result. I've filed feedback again [2].

[1] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/startup_utils.h?type=cs&q=.oobe_completed&sq=package:chromium&l=44

  // Returns device registration completion status, i.e. second part of OOBE.
  // It is triggered by enrolling the device, but also by logging in as a
  // consumer owner or by logging in as guest.  This state change is announced
  // to the system by writing the .oobe_completed flag file.
  static bool IsDeviceRegistered();

[2] https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=ZGB&lReport=76061477771

After the device has been sitting for a while, it now started to update by itself. Thus it seems like a UI problem: Even while on M-53 the device detects that it is EOL'd and does the relevant UI changes (warn users, disable the "check for updates" button).

Afaics, the correct behaviour would be to trigger EOL UI only when the device has reached its final milestone.

Thanks Thiemo, looks like you're right, guest login completes OOBE but the device is not owned until a or b in my #3.

I'm pretty sure update engine will wait for the device to be owned (may refer to it as OOBE in it's logs). We don't want to do a full update to latest stable if device is about to be enterprise enrolled in a domain that is pinning to an older Chrome OS release so we wait until TPM is owned.

I also see:

clear_tpm_owner_request = 1                              # Clear TPM owner on next boot
clear_tpm_owner_done   = 0                              # Clear TPM owner done

in your logs so suspect somethings up with the TPM. 

Josafat, how long will we host the final milestone for a EoL device for? We're still hosting 56 for mario but will we remove it at some point?

I disagree about displaying EOL messages. The *device* is EOL no matter what version of Chrome OS it's running. We should be doing our best to get EOL devices up on the last release they had but the version they are running doesn't change the fact that the device is EOL.

The last supported version is not intended to be removed hence will be served as long as device is provisioned in Omaha 

Re the UI message, I agree that the message has to displayed regardless of what version you are running. That said, there may be improvement to the message to be more clear that the "latest" updates are the ones not supported 

I have updated the title of this bug with it 

agree that the strings could use some refinement. Last I looked it was ambigious as to what is EOL and user should upgrade (software vs. hardware). We should be explicit that the hardware is EoL.

Josafat, could you help to suggest an new message?

Here is the recommended one:
"This device will no longer receive the latest software updates"

Re comment #9:

> I disagree about displaying EOL messages. The *device* is EOL no matter what version of Chrome OS it's running. We should be doing our best to get EOL devices up on the last release they had but the version they are running doesn't change the fact that the device is EOL.

I guess we can do that, but that means that EOL UI needs to distinguish two states:
* EOL but there are still updates
* EOL and no updates anymore

The current UI is not doing that properly.

(My thought was: Users that haven't even upgraded to the latest available version clearly don't care about their device being discontinued, thus there is no need to tell them. They are likely not ready to receive that message yet and it would be better to notify them "in context", i.e. once they have progressed to the latest version.)

Re comment #11:

Updating the string is only part of addressing this issue. Currently we disable the "check for updates" button on device EOL, but it should only be disabled when the final OS version has been reached.

I agree with #12 regarding when to show the EOL message. I think it should be within the context of users already running the last supported milestone to avoid confusing them with EOL messages too far in advance. 

I'm a little confused here:
Does EOL == AUE?
If the device is already EOL and not AUE yet, do we have a separate notification for AUE when the device reached the its last supported version? 

Yes EOL and AUE are the same and we should only use AUE going forward

Re#15: Thanks! Just want to confirm that Omaha is sending the same signal to UI as before(SUPPORTED or EOL) and we use that to decide whether to show the message or not.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4ad394b04ba7f87d2c39b0cfcaa25637b121ca46

commit 4ad394b04ba7f87d2c39b0cfcaa25637b121ca46
Author: Sarah Hu <xiaoyinh@chromium.org>
Date: Mon Nov 27 19:03:00 2017

Update EOL message and show EOL notification to guest users.

Bug:  717259 , 747360 
Change-Id: I408764b66d70dbc1061ef1c6aa974d3ce297376a
Reviewed-on: https://chromium-review.googlesource.com/786435
Commit-Queue: Xiaoyin Hu <xiaoyinh@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#519356}
[modify] https://crrev.com/4ad394b04ba7f87d2c39b0cfcaa25637b121ca46/chrome/app/chromeos_strings.grdp
[modify] https://crrev.com/4ad394b04ba7f87d2c39b0cfcaa25637b121ca46/chrome/browser/chromeos/eol_notification.cc
[modify] https://crrev.com/4ad394b04ba7f87d2c39b0cfcaa25637b121ca46/chrome/browser/chromeos/eol_notification.h
[modify] https://crrev.com/4ad394b04ba7f87d2c39b0cfcaa25637b121ca46/chrome/browser/chromeos/login/session/chrome_session_manager.cc
[modify] https://crrev.com/4ad394b04ba7f87d2c39b0cfcaa25637b121ca46/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/4ad394b04ba7f87d2c39b0cfcaa25637b121ca46/chrome/browser/chromeos/login/session/user_session_manager.h

Updated the message per comment 11.