Lines Matching refs:update
13 an update. Hence, reducing the likelihood of corrupting a device into a
19 reboot if an update was performed where the reboot duration is about 10
21 * The user does not need (although they can) to request for an update. The
22 update checks happen periodically in the background.
23 * If the update fails to apply, the user is not affected. The user will
25 apply the update again at a later time.
26 * If the update applies correctly but fails to boot, the system will rollback
28 * The user does not need to reserve enough space for the update. The system
36 In A/B update capable systems, each partition, such as the kernel or root (or
39 which copy has the higher priority at boot time) and when a new update is
44 But everything starts with generating update payloads in (Google) servers for
45 each new system image. Once the update payloads are generated, they are signed
46 with specific keys and stored in a location known to an update server (Omaha).
48 When the updater client initiates an update (either periodically or user
49 initiated), it first consults different device policies to see if the update
50 check is allowed. For example, device policies can prevent an update check
51 during certain times of a day or they require the update check time to be
54 Once policies allow for the update check, the updater client sends a request to
55 the update server (all this communication happens over HTTPS) and identifies its
57 the update server decides to serve an update payload, it will respond with all
58 the parameters needed to perform an update like the URLs to download the
60 client continues communicating with the update server after different state
62 the update, or reports that the update failed with specific error codes, etc.
66 update. The extra data contains the data blobs needed by some or all of these
68 cryptographically verifies it using the provided signatures from the update
87 payload). If the signature cannot be verified, the update is rejected.
90 and compared to a hash value passed in the metadata to make sure the update was
96 can also perform any board specific or firmware update tasks necessary. If
97 postinstall fails, the entire update is considered failed.
99 Then the updater client goes into a state that identifies the update has
103 periodic update checks so we can have statistics on the number of active devices
106 After the update proved successful, the inactive partition is marked to have a
121 for update checks to the update engine. The details of how requests are passed
122 to the update engine is system dependent, but in Chrome OS it is D-Bus. Look at
125 There are many resiliency features embedded in the update engine that makes auto
128 * If the update engine crashes, it will restart automatically.
129 * During an active update it periodically checkpoints the state of the update
130 and if it fails to continue the update or crashes in the middle, it will
139 update process after failed attempts or crashes.
141 The core update engine code base in a Chromium OS checkout is located in
148 performed. For example, an organization may want to scatter the update checks
150 business. Within the update engine daemon, [UpdateManager] has the
153 happen, while they prevent downloading the update payload. Or some policies
154 don’t allow the update check within certain time frames, etc. Anything that
155 relates to the Chrome OS update policies should be contained within the
172 by the updater client to install an even newer update. Normally a rollback is
177 normal system update, except that an older update payload is downloaded and
187 update engine and happen in the background. Interactive updates, on the other
188 hand, happen when a user specifically requests an update check (e.g. by clicking
189 on “Check For Update” button in Chrome OS’s About page). Depending on the update
191 updates (by carrying marker hints). They may decide to not provide an update if
194 the update faster.
198 non-interactive updates happen periodically, a forced-non-interactive update
199 causes a non-interactive update at the moment of the request, not at a later
200 time. We can call a forced non-interactive update with:
211 basically a peer-to-peer update system that allows the devices to download the
212 update payloads from other devices in the network. This has to be enabled
215 of update payloads, all update requests go through update servers in HTTPS.
217 Check out the [P2P update related code] for both the server and the client side.
232 `/var/log/update_engine` after a few restarts of the update engine or after the
238 The update payload generation is the process of converting a set of
250 properties file is necessary in order to do any kind of auto update in [`cros
254 Once update payloads are generated, their original images cannot be changed
255 anymore otherwise the update payloads may not be able to be applied.
258 different types of update payloads. Its code is located in
260 related to mechanics of generating an update payload. None of the files in this
263 rest of the update engine tools.
268 library in [`chromite/lib/paygen`]. Whenever calls to the update payload
273 Each update payload file has a specific structure defined in the table below:
277 |Magic Number|4|char[4]|Magic string "CrAU" identifying this is an update payload.|
290 solely from the target image (the image we want to update to) and has all the
291 data necessary to update the inactive partition. Hence, full payloads can be
293 update generated by comparing the source image (the active partitions) and the
295 differential update similar to applications like `diff` or `bsdiff`. Hence,
297 of the active partition in order to update the inactive partition (or
350 The major and minor versions specify the update payload file format and the
351 capability of the updater client to accept certain types of update payloads
354 Major version is basically the update payload file version specified in the
355 [update payload file specification] above (second field). Each updater client
393 payload generation and application. We normally test the update payloads using
410 system. Anything that needs to be done after an update and before the device is
439 restart update-engine # with a dash not underscore.
507 There are different methods to initiate an update:
510 way to configure this way of update check.
517 * Run one of many auto update autotests.
520 like the IP address of your Chromebook and where the update payloads are
521 located to the Dev Server to start an update on your device (**Warning:**
524 `update_engine_client` is a client application that can help initiate an update
526 options like initiating an interactive vs. non-interactive update, changing
527 channels, getting the current status of update process, doing a rollback,
531 identify different update parameters like the updater server (Omaha) URL, the
535 update server and allow the update_engine to schedule a periodic update from
539 don’t have those changes in the update server, or you have some specific
540 payloads that do not exist on the production update server you can use
541 [Nebraska] to help with doing an update.
545 When changing the update engine source code be extra careful about these things:
550 can correctly be applied to older devices that run older versions of the update
558 to accept an older update payload. Normally this happens using a full payload,
563 When creating a change in the update engine, think about 5 years from now:
575 in the updater client that causes it to crash right before checking for update
586 The current update engine code base is used in many projects like Android. We
588 or other systems that share the update engine code. Whenever landing a change,
615 [update payload file specification]: #update-payload-file-specification
623 [P2P update related code]: https://chromium.googlesource.com/chromiumos/platform2/+/master/p2p/