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
54 and stored in a location known to an update server (GOTA).
56 operators an choose to make this OTA update available only to a specific
60 When the device's updater client initiates an update (either periodically or user
61 initiated), it first consults different device policies to see if the update
62 check is allowed. For example, device policies can prevent an update check
63 during certain times of a day or they require the update check time to be
66 Once policies allow for the update check, the updater client sends a request to
67 the update server (all this communication happens over HTTPS) and identifies its
75 But if the update server decides to serve an update payload, it will respond
76 with all the parameters needed to perform an update like the URLs to download the
78 client continues communicating with the update server after different state
80 the update, or reports that the update failed with specific error codes, etc.
82 The device will then proceed to actually installing the OTA update. This consists
87 update. The extra data contains the data blobs needed by some or all of these
89 cryptographically verifies it using the provided signatures from the update
108 payload). If the signature cannot be verified, the update is rejected.
118 passed in the metadata to make sure the update was successfully written into
131 Then the updater client goes into a state that identifies the update has
135 periodic update checks so we can have statistics on the number of active devices
138 After the update proved successful, the inactive partition is marked to have a
144 then mark the update as successful.
156 for update checks to the update engine. The details of how requests are passed
157 to the update engine is system dependent, but in Chrome OS it is D-Bus. Look at
160 There are many resiliency features embedded in the update engine that makes auto
163 * If the update engine crashes, it will restart automatically.
164 * During an active update it periodically checkpoints the state of the update
165 and if it fails to continue the update or crashes in the middle, it will
174 update process after failed attempts or crashes.
181 update engine and happen in the background. Interactive updates, on the other
182 hand, happen when a user specifically requests an update check (e.g. by clicking
183 on “Check For Update” button in Chrome OS’s About page). Depending on the update
185 updates (by carrying marker hints). They may decide to not provide an update if
188 the update faster.
192 non-interactive updates happen periodically, a forced-non-interactive update
193 causes a non-interactive update at the moment of the request, not at a later
194 time. We can call a forced non-interactive update with:
213 `/var/log/update_engine` after a few restarts of the update engine or after the
221 The update payload generation is the process of converting a set of
229 different types of update payloads. Its code is located in
231 related to mechanics of generating an update payload. None of the files in this
234 rest of the update engine tools.
242 Each update payload file has a specific structure defined in the table below:
246 … | Magic string "CrAU" identifying this is an update payload. …
259 solely from the target image (the image we want to update to) and has all the
260 data necessary to update the inactive partition. Hence, full payloads can be
262 update generated by comparing the source image (the active partitions) and the
264 differential update similar to applications like `diff` or `bsdiff`. Hence,
266 of the active partition in order to update the inactive partition (or
319 The major and minor versions specify the update payload file format and the
320 capability of the updater client to accept certain types of update payloads
323 Major version is basically the update payload file version specified in the
324 [update payload file specification] above (second field). Each updater client
362 payload generation and application. We normally test the update payloads using
379 system. Anything that needs to be done after an update and before the device is
410 There are different methods to initiate an update:
413 way to configure this way of update check.
420 When changing the update engine source code be extra careful about these things:
425 can correctly be applied to older devices that run older versions of the update
433 to accept an older update payload. Normally this happens using a full payload,
438 When creating a change in the update engine, think about 5 years from now:
450 in the updater client that causes it to crash right before checking for update
461 ~~The current update engine code base is used in many projects like Android.~~~
466 or other systems that share the update engine code. Whenever landing a change,
493 [update payload file specification]: #update-payload-file-specification
501 [P2P update related code]: https://chromium.googlesource.com/chromiumos/platform2/+/master/p2p/