Some devices, such as the Essential PH-1, don't have an
updated bootloader and the bootloader is appending an extra
underscore.
This patch works around that issue by sanitizing the slot to be
inline with modern expectations.
Offending commit: 42b18a518b
Most of the commit above is not needed because an underscore + slot
is automatically appended when flashing to a partition. Normally, this
would result in something like boot__b instead of boot_b, where b is the
current slot.
Test: flash an image on mata without specifying slot, boots
Change-Id: Ia0b7cee603a4f9ba2e3a61ce6e369ca8c07a7caf
The pvmfw partition holds the protected VM firmware that is used by
Protected KVM to bootstrap the trust in protected VMs. Teach fastboot
about the partition so it gets flashed with flashall.
pvmfw is an AVB chained partition so is marked as BootCritical to allow
ABL's AVB verification to pass.
Test: tab complete and flashall
Bug: 171280178
Change-Id: Ie4cc478de25a945bc510488d87c2bee3aa5031f2
If the flashed boot image is smaller than the block device, the AVB
footer will not be at the end of the partition. Although images are
normally created to match the partition size the GKI boot.img must work
on all devices, and the size of the boot partition will vary.
Copy the AVB footer to the end of the partition before flashing, if it
is not there already.
Bug: 159377163
Change-Id: I5a5e25fb54dc9d6a2930fda63434968808ffa1f0
Status() is called with an empty string to handle `fastboot oem`
commands. This currently emits a set of spaces and sets
last_start_time such that the epilog can track the time spent in this
command. Emitting the spaces is problematic however, since it results
in the follow:
$ fastboot oem device-info
(bootloader) Verity mode: false
(bootloader) Device unlocked: true
(bootloader) Device critical unlocked: true
(bootloader) Charger screen enabled: true
OKAY [ 0.000s]
Finished. Total time: 0.000s
If we skip emitting the spaces, then we get the correct result:
$ fastboot oem device-info
(bootloader) Verity mode: false
(bootloader) Device unlocked: true
(bootloader) Device critical unlocked: true
(bootloader) Charger screen enabled: true
OKAY [ 0.001s]
Finished. Total time: 0.001s
There are no other uses of Status() with an empty string, so this
changes won't impact other commands.
Bug: 158310284
Test: fastboot formats this and other commands correctly.
Change-Id: I6294acefc65a8399160c0944b3fbc2f2ace919ed
The Nexus 7 bootloader just returns the empty string for unknown
variables, which confused the new snapshot code.
Bug: https://issuetracker.google.com/158232468
Test: no Nexus 7 available during covid-19 :-(
Change-Id: I35ff8889b27944e8b7426eca4f513d9fa562c6d4
It's not possible to programmatically determine which fastboot mode a
device is in, without sending a getvar:is-userspace query. Unfortunately
this is not possible asynchronously, and may interrupt other queries
being processed.
This patch changes fastbootd's USB interface name to "fastbootd". Note
that tools use the protocol number/class and not this string, so it
should be safe to extend. When using "fastboot devices", the interface
name is now listed if set. Note that currently only the Linux version of
the fastboot tool is capable of reading the interface name.
Bug: 156966319
Test: fastboot devices on Linux
Change-Id: I57ccf2bec1dda573fe3ac628a646624b76f45905
Support v3 header format when changing the command line with
fastboot boot or using flash:raw.
Bug: 151750405
Test: fastboot boot and flash:raw with updated cmdline and v3 header
Change-Id: Ibf396e2d18d8b22cad50db290f3fd4e46ff85d9b
When a snapshot is applied or is merging, requests to erase or flash
userdata, metadata, or misc must be protected. In addition, the
set_active command must be restricted when a merge is in progress.
In addition, introduce a "snapshot-update merge" command for assisting
with erase requests when a merge is in progress. As in recovery, this
will force a merge to complete.
Bug: 139154945
Test: apply update
fastboot erase userdata
fastboot erase metadata
fastboot erase misc
fastboot set_active
Change-Id: I152446464335c62c39ffb4cc6366be9de19eac30
This introduces two new commands to the fastboot protocol:
- getvar snapshot-update-status - Return "none", "snapshotted", or
"merging" depending on the current status set by the boot control
HAL.
- snapshot-update [cancel] - Cancel any pending snapshot-based updates
via the boot control HAL. After this, the HAL should return
MergeStatus::CANCELLED and "update-merge-status" should be "none".
If no argument is specified, the snapshot-update-status is returned
via an INFO response.
Bootloaders are expected to implement this in a manner consistent with
the boot control HAL.
Fastboot-based tooling should expect wipes of userdata to fail when
update-merge-status returns "merging". Thus, the force flag now cancel
any pending snapshots.
Bug: 139154945
Test: fastboot getvar snapshot-update-status
fastboot snapshot-update cancel
fastboot snapshot-update
Change-Id: Idc423fe7656b212e929e64eb0e6b85b453e0e8dc
If top-level vbmeta struct is in 'boot' partition,
the "flags" element offset of top-level vbmeta header
from the beginning of boot partition is 123 plus
top-level vbmeta offset recorded in the boot image footer.
Bug: 139639521
Test: m fastboot
Test: fastboot --disable-verification flashall
Test: fastboot --disable-verification flash boot boot.img, checks the
flag isn't changed if the device has vbmeta partition
Test: fastboot --disable-verification flash vbmeta vbmeta.img
Change-Id: Ibf73c9330639e971ee3873ac19f072cf7baed55b
load_buf_fd() attempts to find the size of the file that it is about
to load by first calling sparse_file_import_auto() then using
sparse_file_len() upon success or falling back to the file size on the
filesystem on failure.
This is problematic however as sparse_file_import_auto() creates a
sparse_file out of the normal file, but does not resparse it, so an
assertion fails during the sparse_file_len() call.
This is fixed by using sparse_file_import() instead. This will fail
in the case that the file is not sparse and the call to
sparse_file_len() will be properly skipped.
Bug: 140538105
Test: flash blueline factory image with assertions enabled in
libsparse/sparse.cpp
Change-Id: I0283be33563a3301ce5b09bde41105a20f91086c
originally if wants_wipe=true, program will erase and format partitions,
but after fb->Erase(), partition type should be raw(all 0xFFs),
then following fb_perform_format() will miss its original partition_type
Now we call fb_perform_format() with original fs type to keep the
partition consistent after wiping.
Change-Id: Ic778850588d5dd6fee23169d20c26bcbaa510627
The vendor_boot partition has been created, so add it to the list of
images which may be flashed.
Bug: 137297791
Change-Id: I27eaa16656a83dbcb8289680844bf58dd1fccf24
Update adb, fastboot and mount point
Bug: 134359158
Test: build and check if system_ext.img can be flashed
Change-Id: I6219f72242c5fe42a508008c0b1fd218d74da5b6
Usage: fastboot wipe-super [super_empty.img]
This command will read the given super_empty.img (using the default one
in ANDROID_PRODUCT_OUT if not specified), and flash by generating a
temporary super.img with no partition data. This command will even work
on retrofit devices.
This command is intended to be used either during device bringup or with
scripts that will manually flash individual dynamic partitions, in place
of using "fastboot flashall".
Bug: 136282057
Test: fastboot wipe-super on retrofit and non-retrofit device
Change-Id: Icab368a63ff36fcce9ac9304eb3966dd38bd78c4
Currently, during a 'fastboot flashall/fastboot update', the 'getvar
max-download-size' command is issued once to the device when it is in
bootloader mode and the same value is used even after the device boots
into fastbootd. If the max-download-size returned by bootloader is
greater than the max-download-size in fastbootd, this could break flash
as large images are broken down into chunks before downloading by using
the max-download-size variable. This will cause fastbootd to return
an error since it checks whether the buffer being downloaded has a size
greater than the max-download-size limit.
Test: fastboot flashall
Bug: 536870912
Change-Id: Ife7c1ec0583d80d4a31ecf01f1fc14a8365afe0d
Switch FindEntry and the ZipString constructor to std::string_view. This
lets us accept an over-long name so that we can reject it as too long.
Also fastboot changes to track the API change.
Bug: http://b/129068177
Test: treehugger
Change-Id: I7df7acd1fe2c46380b789c25f8909e0553e2d55e
This is required for read() to function correctly
in Windows since it behaves differently in text mode and
binary mode and may cause unpredictable behavior depending
on the contents of the image file.
Bug: 129281908
Test: fastboot.exe flashall
Change-Id: I64370af44a050bafea60ff1b0b2be18cc531480a
The function do_for_partitions() takes a const std::string
reference, so it's inefficient to pass a std::string::c_str().
Test: TreeHugger
Change-Id: Ia84ed9ec691ee2f524c61dd25a81b2995bb0bb33
This command erroneously reports that no GSI is installed, because
/metadata is not mounted in recovery. To address this, temporarily mount
/metadata when the gsi command is invoked.
Bug: 122556707
Test: fastboot gsi disable
fastboot gsi wipe
Change-Id: Ib21971b49b46fd580b902ff75f01cfb96192afc0
New arguments 'dtb' and 'dtb-offset' have been added to
support boot image header version 2 for the 'fastboot boot'
and 'fastboot flash:raw boot' commands.
Test: fastboot boot Image.lz4 --dtb <dtb_path> --header-version 2
Test: fastboot flash:raw boot Image.lz4 --dtb <dtb_path>
--header-version 2
Bug: 111136242
Change-Id: Idf5c2eb138609dc7e915e80c4db64677c89f24b6
Note: this only removes the bootable marker, since we're unable to
remove the userdata files within recovery.
Bug: 121210348
Test: fastboot gsi wipe
fastboot gsi disable
Change-Id: I64fe848c787d426ae9d18a1557a9d6b340bfc2cf
On non-DAP devices, fastboot flash <partition> will spam error messages
about not being able to read super_empty.img. We should check that
super_empty.img exists before trying to read it.
Bug: 120429424
Test: fastboot flash system on non-DAP device
Change-Id: I6c4eec19cb3ef8d24595a75e072e1d75baaa8cdd
On retrofit devices, if both slots contain dynamic partition builds,
then "flashall" will attempt to write secondary images to dynamic
partitions in the other slot. At worst, this can fail with an error. At
best, it will result in the "other" partition not being mounted on first
boot.
This patch therefore deletes logical partitions for secondary images, on
retrofit devices only. On a Pixel device on the "b" slot, this means
"system_a" and "vendor_a" will be deleted before flashing, and therefore
system_other and vendor_other will be flashed to physical partitions
instead.
Bug: 120034852
Test: fastboot set_active a
fastboot flashall
fastboot set_active b
fastboot flashall
Change-Id: I6affe9a6c639b0495bffc77fcf20f329b86ad159
When checking for existence of "super_empty.img" to determine if
flash image product set is meant for logical partitions, we die if
ANDROID_PRODUCT_OUT environment is unset or empty. This check
is done before we look at the flash image name to determine if it
is a candidate to look at the logical metadata.
Instead, allow this check to conservatively fail for now.
Test: export ANDROID_PRODUCT_OUT=
fastboot flash bootloader
Bug: 120041144
Change-Id: I43f124015f9d26c79a0feb9123522432fe937343
Merged-In: I43f124015f9d26c79a0feb9123522432fe937343
On retrofit devices, it is easy to accidentally overwrite
system/vendor/product by flashing system in the bootloader. The reason
is that GPT system_a is really the super partition, and the bootloader
doesn't know it.
Addressing this in bootloaders would require two separate commands: one
that rejects flashing system/vendor/product, and another for
expert/factory use that would allow direct flashing.
This patch introduces protection into the host fastboot tool instead.
It's not mutually exclusive with bootloader changes; having protection
in the host tool affords us better and consistent UI. However it does
rely on users having newer builds.
With this change, the following will not work in the bootloader:
fastboot flash system # or vendor, product, etc
The message is the same whether or not the device is a retrofit. To
continue anyway, you can do:
fastboot flash --force system
If we decide on bootloader protection as well, the --force flag can be
re-used.
Bug: 119689480
Test: fastboot flash system # disallowed in bootloader, allowed in fastbootd
fastboot flash --force system # allowed in bootloader
Change-Id: I0861e3f28a15be925886d5c30c7ebd4b20c477cf
This patch adds a new variable, "super-partition-name", to query the
name of the super partition (with a slot suffix if it has one). The
fastboot flashing tool has been updated to query this variable.
Since the super partition name can no longer be determined without
fastbootd, the presence of super_empty.img is used to test for
dynamic partition support rather than the presence of a super partition.
Bug: 116802789
Test: fastboot flashall on retrofit device
Change-Id: If830768eba6de7f31ac3183c64167fae973c77a4
When updating the super partition, attempt to preserve partitions from
the other slot. If any partition can't be preserved, fail and require a
wipe (-w) to proceed. This allows two bootable builds to be flashed to
both slots.
The preserve operation can fail if the metadata is not compatible with
the old partition layout. For example, if the partition references a
group that no longer exists, or a group changed its capacity, or the
metadata's block device list or list contents changed.
Bug: N/A
Test: liblp_test gtest
fastboot flashall --skip-secondary
Change-Id: I53fdd29bc1f0ef132005a93d3cf1cdcd7f2fc05f
The libziparchive public headers that refer to `off64_t` also need the
Mac workaround.
In fastboot, there's a stray `lseek64` but since it's only for offset 0,
any kind of seek is fine.
Bug: N/A
Test: builds
Change-Id: I68b4f95202623ebf07ffe6c3e0e21437e7922c5b
If an image size changes slightly in between "flashall" and some change
in the build, it's inconvenient to have to reflash the whole device again.
This patch resizes partitions when using a normal flash command, to
improve the developer workflow.
Bug: N/A
Test: fastboot flash system
Change-Id: I349364a4742a0c15748f545fcfda946107720d45
After rebooting to userspace fastboot, the first command issued is
"update-super". If we wound up in the bootloader by accident (as
happened to a few users with a busted vbmeta_system), the resulting
error message will be very misleading ("update-super" will be an
unrecognized command).
Instead, this patch explicitly errors if we did not successfully boot
into fastbootd.
Bug: N/A
Test: fastboot flashall
Change-Id: I7d5bd64db540978bd0bae884f40ce8c3df48f856
