fs_mgr_overlayfs needs access to /metadata to tell whether or not the
scratch partition exists on /data.
Bug: 134949511
Test: adb remount, fastboot flash system
Change-Id: I3a09aae495d691e9c1a1e25a8fb3514e355ecd05
Retrofit devices will have two super partitions, spanning the A and B
slots separately. By design an OTA will never cause "A" or "B"
partitions to be assigned to the wrong super. However, the same is not
true of fastbootd, where it is possible to flash the inactive slot. We
do not want, for example, logical "system_a" flashing to super_b.
When interacting with partitions, fastbootd now extracts the slot suffix
from a GetSuperSlotSuffix() helper. On retrofit devices, if the partition
name has a slot, that slot will override FastbootDevice::GetCurrentSlot.
This forces partitions in the inactive slot to be assigned to the correct
super.
There are two consequences of this. First, partitions with no slot
suffix will default to the current slot. That means it is possible to
wind up with two "scratch" partitions, if "adb remount" is used on both
the "A" and "B" slots. However, only the active slot's "scratch" will be
visible to the user (either through adb or fastboot).
Second, if one slot does not have dynamic partitions, flashing will
default to fixed partitions. For example, if the A slot is logical and B
is not, flashing "system_a" will be logical and "system_b" will be
fixed. This works no matter which slot is active. We do not try to
upgrade the inactive slot to dynamic partitions.
Bug: 116802789
Test: fastboot set_active a
fastboot flashall # dynamic partitions
fastboot getvar is-logical:system_a # true
fastboot getvar is-logical:system_b # false
fastboot set_active b
fastboot flashall --skip-secondary
fastboot getvar is-logical:system_a # true
fastboot getvar is-logical:system_b # true
Booting both slots works.
Change-Id: Ib3c91944aaee1a96b2f5ad69c90e215bd6c5a2e8
This implements getvar all by invoking each callback and writing an INFO
status for each result. For commands that take arguments, the variable
handler can specify a function that returns all possible arguments.
Currently this only applies to partition variables.
Bug: 78793464
Test: fastboot getvar all works
Change-Id: I1cf84e06bf67614b6f56171c0ee6ca5d7ac383c9
When flashing logical partitions, we read the "super" partition metadata
corresponding to the current slot. We then temporarily create a
device-mapper device for that partition, and immediately destroy the
device after all operations are complete. We do not mount partitions
ahead of time, or keep them mounted, because a fastboot operation may
change the layout of the logical partition table (or change which slot
is current).
Bug: 78793464
Test: fastboot flash a logical partition under "super"
Change-Id: Id2a61d3592decabeebfd283c4fd6e6cbe576a18c
