Lines Matching +full:early +full:- +full:boot
6 called A/B updates, over-the-air ([OTA]) updates, seamless updates, or simply
14 non-usable state. And reducing the need for flashing devices manually or at
26 * If the update applies correctly but fails to boot, the system will rollback
39 which copy has the higher priority at boot time) and when a new update is
89 After the inactive partition is updated, the entire partition is re-read, hashed
94 reconstructs the dm-verity tree hash of the ROOT partition and writes it at the
107 higher priority (on a boot, a partition with higher priority is booted
108 first). Once the user reboots the system, it will boot into the updated
110 updater client calls into the [`chromeos-setgoodkernel`] program. The program
111 verifies the integrity of the system partitions using the dm-verity and marks
117 The `update_engine` is a single-threaded daemon process that runs all the
120 system boot. Different clients (like Chrome or other services) can send requests
122 to the update engine is system dependent, but in Chrome OS it is D-Bus. Look at
123 the [D-Bus interface] for a list of all available methods.
184 ### Interactive vs Non-Interactive vs. Forced Updates
186 Non-interactive updates are updates that are scheduled periodically by the
190 server's policies, interactive updates have higher priority than non-interactive
197 user action), but they can also be configured to act as non-interactive. Since
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:
203 update_engine_client --interactive=false --check_for_update
211 basically a peer-to-peer update system that allows the devices to download the
230 current data-time format in the log file’s name
231 (`update_engine.log-DATE-TIME`). Many log files can be seen in
276 |-----|------------|----|-----------|
319 partitions on the client’s device is bit-by-bit equal to the original partitions
323 1. Find all the zero-filled blocks on the target partition and produce `ZERO`
327 partitions by directly comparing one-to-one source and target blocks and
406 is to recreate the dm-verity tree hash at the end of the root partition. Among
418 (chroot) $ emerge-${BOARD} update_engine
423 (chroot) $ cros_workon_make --board=${BOARD} update_engine
439 restart update-engine # with a dash not underscore.
448 (chroot) $ cros_workon --host start update_engine
453 If you make any changes to the D-Bus interface make sure `system_api`,
454 `update_engine-client`, and `update_engine` packages are marked to build from
458 (chroot) $ emerge-${BOARD} system_api update_engine-client update_engine
469 (chroot) $ FEATURES=test emerge-<board> update_engine
475 (chroot) $ cros_workon_make --board=<board> --test update_engine
481 (chroot) $ cros_run_unit_tests --board ${BOARD} --packages update_engine
490 P2_TEST_FILTER="*OmahaRequestActionTest.*-*RunAsRoot*" \
491 emerge-amd64-generic update_engine
498 P2_TEST_FILTER="*OmahaRequestActionTest.MultiAppUpdateTest-*RunAsRoot*" \
499 emerge-amd64-generic update_engine
526 options like initiating an interactive vs. non-interactive update, changing
530 `update_engine` daemon reads the `/etc/lsb-release` file on the device to
533 file `/mnt/stateful_partition/etc/lsb-release` with desired customized
576 and we can't quite catch this bug early in the release process, then the
609 repo start merge-aosp
610 git merge --no-ff --strategy=recursive -X patience cros/upstream
611 repo upload --cbr --no-verify .
615 [update payload file specification]: #update-payload-file-specification
618 [`chromeos-setgoodkernel`]: https://chromium.googlesource.com/chromiumos/platform2/+/master/install…
619 [D-Bus interface]: /dbus_bindings/org.chromium.UpdateEngineInterface.dbus-xml
631 [Postinstall]: https://chromium.googlesource.com/chromiumos/platform2/+/master/installer/chromeos-p…
634 [Nebraska]: https://chromium.googlesource.com/chromiumos/platform/dev-util/+/master/nebraska/