Lines Matching refs:updater

48 When the updater client initiates an update (either periodically or user
54 Once policies allow for the update check, the updater client sends a request to
59 payloads, the metadata signatures, the payload size and hash, etc. The updater
67 operations. The updater client first downloads the metadata and
72 Next, the updater client marks the inactive partition as unbootable (because it
76 Then, the updater client performs the operations defined in the metadata (in the
80 payload before applying it. During this process the updater client periodically
85 During the download, the updater client hashes the downloaded bytes and when the
99 Then the updater client goes into a state that identifies the update has
101 reboots (or signs out), the updater client will not do any more system updates
110 updater client calls into the [`chromeos-setgoodkernel`] program. The program
136 The updater clients writes its active preferences in
138 during the lifetime of the updater client and allows properly continuing the
166 A normal rollback, which has existed for as long as Chrome OS had auto updater,
172 by the updater client to install an even newer update. Normally a rollback is
221 The updater client has the capability to download the payloads using Ethernet,
239 partitions/files into a format that is both understandable by the updater client
251 flash`], AU autotests, etc. Similarly the updater server uses this file to
252 dispatch the payload properties to the updater clients.
351 capability of the updater client to accept certain types of update payloads
352 respectively. These numbers are [hard coded] in the updater client.
355 [update payload file specification] above (second field). Each updater client
364 Minor version defines the capability of the updater client to accept certain
365 operations or perform certain actions. Each updater client supports a range of
366 minor versions. For example, the updater client with minor version 4 (or less)
368 payload for an image which has an updater client with minor version 4 (or less)
379 able to be applied for very old clients. The reason is that the updater clients
404 [Postinstall] is a process called after the updater client writes the new image
525 or get more information about the status of the updater client. It has several
531 identify different update parameters like the updater server (Omaha) URL, the
557 Especially regarding enterprise rollback, a newer updater client should be able
573 client updater. Because the client updater can be fragile at points and small
575 in the updater client that causes it to crash right before checking for update
580 changes to the client updater)? Or can the feature be moved to another service
581 with minimal interface to the updater client. Answering these questions will pay