Use introduced FileLock and network-connected devices storage entities
to introduce fastboot connect / disconnect commands
Test: everything works like discussed here go/fastboot-connect-disconnect on windows/linux
Bug: 267507450
Bug: 267506875
Change-Id: I2d6495ad567a3ddadd471a89b82d78c8c36a3d52
Signed-off-by: Dmitrii Merkurev <dimorinny@google.com>
Reboots to fastbootd (userspace fastboot) take a long time, particularly
due to the orange AVB screen and the likelihood of devices having uart
enabled. For "flashall", there is rarely a need to actually go into
userspace, because all of super is getting thrown away. We can just
flash super in the bootloader.
In the past we didn't do this because computing super.img is expensive -
both in terms of time (due to reading dependent images) and in terms of
space (it's easily over 5GB).
But we don't actually need to fully compute super.img. We can build a
sparse_file containing the metadata/headers, with additional references
to each image file containing partition data. Liblp provides the API to
do that, and here, we simply need to translate the layout to libsparse.
On Pixel, this reduces flashall time by around 35-50 seconds, or around
20% of total time, depending on whether uart is in use.
There are some caveats, in which case we'll fall back to normal
fastbootd. This does not work on non-A/B devices, on retrofit dynamic
partition devices (Pixel 3), and in some other edge-casey scenarios. If
it fails, -v will add logging information about why.
Bue: 266982466
Test: fastboot flashall on Pixel 5+
Change-Id: Ie040da597d739faa7f834202184cec8f8e412076
The die() and verbose() macros are not really standard for AOSP. To
allow a gradual transition off them, call InitLogging on startup. This
will also allow seeing liblp logs when -v is passed.
Bug: 266982466
Test: builds
Change-Id: I74278bb5f698edb0dc81477a575b130b0bd11cdf
Copy the AVB footer of the recovery.img to the end of the recovery
partition, so that it can be found when loading a recovery image
from a partition that is larger than the image.
Bug: 261673286
Test: m and flashing recovery image and bootloader can now detect
AVB footer.
Change-Id: Ib93da33c72f3a96eb8d9bcedaab5ef0c3a4d418d
Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
fastboot uses the internal functions generate_ext4_image and
generate_f2fs_image when called via the `format` subcommand. An option
for populating the newly created fs with an initial directory exists,
but it is not exposed to the command line interface (initial_dir is
always ""). Remove the unused codepaths for this preloading.
Test: atest --host fastboot_test
Bug: 237960487
Change-Id: I7acfe6352cf26b5cbe0e5553b288c3798e96a893
The vbmeta partition might have additional prefix
(e.g., guest_vbmeta_a) on some virtual machine
environment. Allowing rewriting the disable-verity/
disable-verification bits in the vbmeta image upon
flash under such use case.
Bug: https://partnerissuetracker.corp.google.com/u/1/issues/181791553
Test: manual tests with different names of vbmeta partition
Change-Id: Iacadaf587fce1e1e7fef946f56bbfc7f4e8233d8
The funciton is now used for init_boot and boot partitions, so the name
and the error messages should be more generic.
Bug: 203698939
Test: m
Change-Id: I168fdcb08accb11b2c9cfc402168744274f59665
Similar to GKI boot.img, init_boot.img is released as a specific size
and should be able to be flashed into partitions that have different
sizes. So the AVB footer is moved from the end of the init_boot.img to
the end of the partition in the case that the partition is larger than
the image.
Bug: 203698939
Test: m
Change-Id: Ib5a63a7bf1b4be4eba4941972750f12e3edb3a17
There is an unclear error message if we run
`fastboot --disable-verification flash boot boot.img` on a
AVB-disabled device without a /vbmeta partition.
Error message:
terminating with uncaught exception of type std::out_of_range: basic_string
Aborted
This is because the buf->fd of the loaded boot.img is not reset,
before returning from function copy_boot_avb_footer().
Also reset some changes in copy_boot_avb_footer() from commit
If83f785e235569ee8ef0de2b37f11dbd2a9a71f4, to prevent the
unnecessary read of the boot vbmeta if no need to copy the
boot image avb footer.
Bug: 191903922
Test: `fastboot --disable-verification flash boot boot.img` on a device
without /vbmeta and without setting BOARD_AVB_ENABLE to true.
Change-Id: If84f08f1b2e12c4c6ded5cafda2bd1d30e75c662
As per the bug, this option has been obsolete for years
and only causes confusion.
Bug: 167694738
Test: fastboot can still wipe
Change-Id: I24a21cb6110d61dec4af800a1fab0bcedc0a3d5c
Add the OUT_FILE parameter to the documentation of fetch which fails if
used as currently (erroneously) documented:
$ fastboot fetch boot
fastboot: usage: expected argument
Test: fastboot help
Change-Id: Ia06d40c2f754e1a55a2052cb84e81f96e71b4573
Allow using --force to bypass flashing requirements
from android-info.txt.
We often provide builds to deviceholders who don't have
an exact matching bootloader or radio image and it is
unimportant. Having the option to override is useful.
This shouldn't affect bootloader.img so should never
prevent a device from returning to fastboot in case of
gross error.
Test: Downloaded a build w/ different radio.
Got the following output:
...
Checking 'version-baseband' FAILED
Device version-baseband is 'xyz'.
Update requires 'abc' or '123'.
requirements not met! but proceeding due to --force
Setting current slot to 'a' OKAY [ 0.065s]
Bug: 184661990
Change-Id: I8680b8275b854304026cff3b2e663b7ef2594383
Change mkbootimg() to return void, as we already have a |out| parameter.
Bug: 183455415
Test: Presubmit
Change-Id: I51439e273752ab9e21f8d7138e900ea55bdfdfc0
Do not use the implicit cast from unique_fd to int so
that it is clearer to the reader what the ownership model
is.
Test: pass
Change-Id: Iaf40a6eed3fcfd001651980c865ed5efb85ac0eb
load_sparse_files assumes that the client maintains
the lifetime of the input fd is longer than
the output sparse_file handle.
Bug: 183409401
Bug: 183223098
Test: flash super image
Change-Id: I295b912c665577b5767a133f3148e58a22733998
When a user issues `fastboot flash vendor_boot:foo ramdisk.img`, the fastboot driver
fetches the vendor_boot image from the device,
determines if `foo` is a valid vendor ramdisk fragment,
repacks a new vendor boot image, then
flash the vendor boot image back.
This requires vendor boot header V4.
As a convinent alias, `fastboot flash vendor_boot:default ramdisk.img`
flashes the whole vendor ramdisk image. This works on vendor boot header
V3 & 4.
Fixes: 173654501
Test: pass
Change-Id: I42b2483a736ea8aa9fd9372b960502a642934cdc
If fastboot flash vendor_boot:default, only
call has-slot on the first token, and append slot
to the first token only.
Test: fastboot flash vendor_boot:default
Bug: 173654501
Change-Id: I8ff7b3a0bafb964792ab8a788d64d14bc47ae83d
The `fastboot fetch` command is a wrapper around
the fetch protocol. It:
- getvar max-fetch-size
- get the size of the partition
- read the data by chunks, chunk size = max-fetch-size.
The name of the partition is passed directly to the device
(with the usual has-slot magic for flashing etc.) If we support
fetching partitions other than vendor_boot in the future, no change
in the driver is needed.
Bug: 173654501
Test: manual
Change-Id: Ie576eea668234df236b096a372e65c5e91c1e48c
fastboot_buffer owns the fd. Make ImageSource::Open()
returns a unique_fd and pass ownership all the way
down to the fastboot_buffer to avoid leaking fds.
Test: none
Change-Id: I9e7e176fc1da74c532a86d0fdba0113bdc81a166
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
