Canary channel for Acer Chromebook 13?

[Steve ꔚ McKay]

I tried updating an Acer Chromebook 13 (nyan_big) to canary channel, but got get an error when running Update. Log follows.

Q: Do we build canary for this board? All boards? If so, how do I go about debugging the update error?

chronos@localhost / $ update_engine_client --channel canary-channel

[0127/101915:INFO:update_engine_client.cc(620)] Done.

chronos@localhost / $ update_engine_client --update

[0127/101915:INFO:update_engine_client.cc(649)] Forcing an update by setting app_version to ForcedUpdate.

[0127/101915:INFO:update_engine_client.cc(651)] Initiating update check and install. 

[0127/101916:INFO:update_engine_client.cc(677)] Waiting for update to complete. LAST_CHECKED_TIME=1422382756 PROGRESS=0.000000 CURRENT_OP=UPDATE_STATUS_IDLE NEW_VERSION=0.0.0.0 NEW_SIZE=0 

[0127/101921:ERROR:update_engine_client.cc(346)] Update failed.

--

Steve McKay |

Eng. |

smc...@google.com |

310-359-8331

[Mike Frysinger]

/var/log/update_engine.log might have more details

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Steve ꔚ McKay]

The only real looking error I see is:

  ERROR: Can't open /dev/mmcblk0rpmb: Permission denied

Any chance that's meaningful?

I see also a variety of message that I'm guessing mean the updater is using default values (and are not errors).

  [0127/101805:WARNING:evaluation_context-inl.h(31)] Error reading Variable update_disabled: "No value set for update_disabled"

  [0127/101805:WARNING:evaluation_context-inl.h(31)] Error reading Variable target_version_prefix: "No value set for target_version_prefix"

  [0127/101805:WARNING:evaluation_context-inl.h(31)] Error reading Variable release_channel_delegated: "No value set for release_channel_delegated" 

  [0127/101805:WARNING:evaluation_context-inl.h(31)] Error reading Variable au_p2p_enabled: "No value set for au_p2p_enabled"

  [0127/101805:WARNING:evaluation_context-inl.h(31)] Error reading Variable au_p2p_enabled: "No value set for au_p2p_enabled"

Note that none of the message in the log indicate that the "--channel canary-channel" is sticking. Where channel is referenced is still says "dev-channel". I'm not sure if that's just because it won't reflect a channel change until the system is updated to the new channel, or for some other reason.

E.g. If I set to canary-channel, querying channel still shows dev-channel.

  chronos@localhost / $ update_engine_client --channel canary-channel

  [0127/105055:INFO:update_engine_client.cc(716)] Done.

chronos@localhost / $ update_engine_client --show_channel

  [0127/105100:INFO:update_engine_client.cc(620)] Current Channel: dev-channel

  [0127/105100:INFO:update_engine_client.cc(624)] Target Channel (pending update): dev-channel

  [0127/105100:INFO:update_engine_client.cc(716)] Done.

Link to the full log of an "--update" run is here: https://docs.google.com/document/d/1uxTk5HltlRw3ASP2Nbpd7PzP8yXwPQmsxAK4R10pgxA/edit?usp=sharing

Thanks for helping.

--steve

[Alex Deymo]

There isn't really an error in that log message (there some warnings we should suppress =D). The omaha response says <updatecheck status="noupdate"/> because of the track="dev-channel" in your request.

What does "update_engine_client --show_channel" tell you?

[Steve ꔚ McKay]

There was something about that at the tail end of my last message....

It doesn't look like like the channel value sticks:

  chronos@localhost / $ update_engine_client --channel canary-channel

  [0127/105055:INFO:update_engine_client.cc(716)] Done.

chronos@localhost / $ update_engine_client --show_channel

  [0127/105100:INFO:update_engine_client.cc(620)] Current Channel: dev-channel

  [0127/105100:INFO:update_engine_client.cc(624)] Target Channel (pending update): dev-channel

  [0127/105100:INFO:update_engine_client.cc(716)] Done.

Am I using the right value for the channel string? I don't see a way to enumerate the legal values of "channel".

[Steve ꔚ McKay]

Chatted w/ Alex on the sidelines. Turns out the problem was caused simply by the omission of an equals sign between the flag and the flag value.

  chronos@localhost / $ update_engine_client --channel=canary-channel

Q: Is this mechanism documented anywhere publicly? I'd be happy to see that it gets updated.

Wishlist: Flag parser is a bit more gripey when it gets confusing or invalid input.

Thanks for the help everyone.

[Mike Frysinger]

the flag parsing is synced between Chromium & Chromium OS which is why it behaves this way.  Steve can comment on feasibility of having a blank option passed in throwing an error.

-mike

[Steve]

If you're asking about documentation on general flag handling in Chromium OS code, that can be found in the libchromeos dev page as well as in the source header comments.  For update_engine_client documentation, some of it can be found here.

The original PSA I sent about flag handling can be viewed here.  

Basically, the libchromeos flag library is based off the Chromium base/command_line.h parser, which only parses into boolean and string types.  It treats anything prepended with "-" or "--" as a flag and everything else as an argument.  It doesn't have any pre-knowledge of each flag's type, so thus with space-delimited flags it can't tell the difference between "--string_flag string_value" and "--boolean_flag argument".  While we could use the libchromeos flag handling knowledge of expected flag types to support space-delimited key-value pairs, doing such would require basically writing a second pre-parser within the library to support this.  While feasible and not too difficult to implement, the additional runtime hit and code complexity of double parsing wasn't worth the convenience of having space-delimited pairs, so we decided leave that feature out and just go with the convention of '='-delimited flags.

As far as handling invalid input, the libchromeos flag handling library does know about flag types, and converts the base/command_line.h parsed string flags into corresponding int, int64, uint64, and double types as necessary, and will indeed throw immediate errors with what should be obvious messages if the input format is invalid.  However it will not throw any "invalid input" errors when an expected string argument (such as the --channel flag) gets an empty string passed to it, as that is a valid use case that some other programs want when they have default values for some flags and want it to instead be an empty string.  Empty string validation would have to occur within the program itself, in this case within update_engine_client code if an empty channel string is indeed always considered an error.

[Daniel Erat]

Can the Chrome OS flags library distinguish between --channel and --channel= or --channel="" and treat the former as an error?

[Mike Frysinger]

hmm, i guess update_engine itself should be doing some validation here then ?

-mike

[Steve]

Unfortunately not.  I should slightly correct what I said earlier, base/command_line.h internally keeps track of all flags as a string-->string map, it doesn't explicitly keep track of boolean flags.  During parsing, if it encounters a boolean flag like "--channel", it inserts "channel" as the key and an empty string as the value in the map.  When it encounters a string flag like "--channel=" it inserts channel as the key and then puts the substring after the '=' delimiter as the value, in this case an empty string.  The Chromium OS flags library then only has access to this mapping, so from the library side, it still can't tell the difference between these two cases without doing additional parsing itself.

[Daniel Erat]

Ah. Agreed that update_engine ought to be catching this, in that case (probably both on account of the empty channel and the unexpected non-flag argument containing the channel name).

[Alex Deymo]

yeah, update_engine_client could do the extra validation of checking if a flag that was defined as accepting a string argument was passed without a string argument; but that sounds to me as something that the library should provide... Alright, we can't do it in the library because of decisions in base::CommandLine API and ppl pushed against re-implementing the parsing of "--foo=bar" in libchromeos with the API we needed... so now we have to deal with these problems in the code using the library.

</rant>

https://chromium-review.googlesource.com/243699