This test has always been flaky, and is not testing something super
valuable: we know that image creation succeeds throughout the rest of
the suite, so it's not very interesting to know that it can succeed in a
low-space scenario.
The inverse test is much more valuable, since we want the correct status
code when creation fails due to low space.
Bug: 240391002
Test: vts_libsnapshot_test
Merged-In: I6235d11033d2f30efe530077b877863ba2574810
Change-Id: I6235d11033d2f30efe530077b877863ba2574810
(cherry picked from commit 97e8a2f0e9)
Diagnosing DM_DEV_REMOVE failures in the test harness is quite
difficult, and it's not clear if failures are spurious or not. Instead
use SnapshotManager's helper function, which can retry on failure, and
will self-diagnose issues on legitimate failures.
Bug: N/A
Test: vts_libsnapshot_test
Change-Id: Ibcaa8406e8b1e8758b99a8e9b58c58d68ed57685
Merged-In: Ibcaa8406e8b1e8758b99a8e9b58c58d68ed57685
(cherry picked from commit e02ef9e9ce)
Due to how CF is built and tested, VABC is enabled even when not
supported by the kernel. To work around this add some logic in
libsnapshot and the test harness to recognize this situation and
silently flip off the VABC flag.
This also fixes the -force_mode option to vts_libsnapshot_test, so that
it will skip tests that aren't supported by the device.
Bug: 264279496
Test: vts_libsnapshot_test on android13-gsi with 11-5.4 kernel
Change-Id: I9279d8d400cac5cd504a7ae91f254aae57fa856d
Due to how CF is built and tested, VABC is enabled even when not
supported by the kernel. To work around this add some logic in
libsnapshot and the test harness to recognize this situation and
silently flip off the VABC flag.
This also fixes the -force_mode option to vts_libsnapshot_test, so that
it will skip tests that aren't supported by the device.
Bug: 264279496
Test: vts_libsnapshot_test on android12-gsi with 11-5.4 kernel
Change-Id: I9279d8d400cac5cd504a7ae91f254aae57fa856d
These tests don't work because 32-bit dependencies are not normally
packaged on a 64-bit system.
Bug: 263062262
Test: builds
Change-Id: I68859a9e9c029a528ee12c02569a3693261c7251
(cherry picked from commit 32fa3e96f4)
This test has always been flaky, and is not testing something super
valuable: we know that image creation succeeds throughout the rest of
the suite, so it's not very interesting to know that it can succeed in a
low-space scenario.
The inverse test is much more valuable, since we want the correct status
code when creation fails due to low space.
Bug: 240391002
Test: vts_libsnapshot_test
Change-Id: I6235d11033d2f30efe530077b877863ba2574810
(cherry picked from commit 97e8a2f0e9)
EROFS is not mandatory for android T and below,
so skip the test for those.
Bug: 237765186
Test: vts_fs_test fs#ErofsSupported
Change-Id: Iceea46f8f2d443636de504962b718a2461605591
Ignore-AOSP-First: already present in aosp/master
Skip checking for userspace snapshots enabled property
for API level < T as this feature is not applicable for
GRF targets.
Bug: 236450435
Test: vts_ota_config_test
Change-Id: Ib5083f6237cdf4962aae06f166811d67cf6c385e
Ignore-AOSP-First: already present in aosp/master
If the vendor partition is on S and system partition is on T,
certain tests in vts_libsnapshot_test used to fail. This is primarily
because of inconsistent check between daemon and vts test.
vts test checks the userspace.snapshots.enabled property which is true on T
but never checks if the underlying vendor partition is on S. Hence,
vts test will enable userspace snapshots. However, daemon checks
the vendor partition and disables userspace snapshots thereby
leading to inconsistency.
This is only a problem on vts tests. The underlying OTA on devices
works fine as we have the vendor partition check.
Bug: 236311008
Test: vts_libsnapshot_test on S vendor and T system
vts_libsnapshot_test on T vendor and T system
Ignore-AOSP-First: cherry-pick from aosp
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Iad4f299bd2e07c9c01f5fbee6a20e2f01bf1778a
These were backported to android13-5.10 and should be present in
T-launch kernels.
Bug: 233926292
Test: vts_fs_test
Change-Id: Ifb5ff6a200b081fe8696d5803d4a128740eb8e21
Merged-In: Ifb5ff6a200b081fe8696d5803d4a128740eb8e21
Ignore-AOSP-First: cherry-pick
merge_op_start_ is used to set the iterator for merge operations.
Uninitialized value can potentially lead to setting up
of bad iterator.
Bug: 233246309
Test: Full OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I3cc48a66b532cfe8b2d87c8724d77ab3169a2ddb
Merged-In: I3cc48a66b532cfe8b2d87c8724d77ab3169a2ddb
This should be using unreserved free space, not total free space.
Bug: 223701928
Test: vts_libsnapshot_test
Change-Id: Ic0a657fe094b57734c93958d7e5da56fbfbada7f
(cherry picked from commit 15433b93ff)
If there are snapshot metadata persisting in /metadata/ota/snapshots,
remove them before applying a new update. Make sure that
the snapshots are indeed invalid before removing them.
On a sidenote, add a comment in init.cpp related to
b/223076262.
Bug: 228250473
Test: 1: Apply OTA in recovery through adb sideload
2: Reboot
3: Apply OTA OTA again through update_device.py
4: Re-run Full OTA updates just from update_device.py
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I116bbafae09042b9c391ccd58c102704571c214e
In Android S, snapuserd binary was on vendor partition.
When there is an OTA update from S -> T, it is possible
that vendor partitions are not updated. In that case,
successive OTA updates T1 -> T2 will continue to have
snapuserd from Android S as vendor partition wasn't updated
to T. All this means, we should disable user-space snapshots.
When installing OTA during runtime, check for property
ro.vendor.build.version.release_or_codename; if the property
is set to "12", then skip userspace-snapshots.
Bug: 227614163
Test: Simulate OTA test on Pixel 6 from T1 -> T2 by forcefully
setting the property to 12 and verify OTA is applied
successfully by falling back to dm-snapshot.
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I95f29145e5cd9ffb8d03d28ae414f0037b88be90
Fix SnapshotUpdateTest.QueryStatusError which
was failing on targets where userspace-snapshots are not
yet enabled.
Bug: 224586316
Test: vts_libsnapshot_test -force_config dmsnap --gtest_filter=SnapshotUpdateTest.QueryStatusError
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Ibaacff9b03eafe0bfa537d0f9cab98b7caceb37e
This should be using unreserved free space, not total free space.
Bug: 223701928
Test: vts_libsnapshot_test
Change-Id: Ic0a657fe094b57734c93958d7e5da56fbfbada7f
There have been two bugs where people use !metadata_encryption.empty()
to check whether metadata encryption is enabled. It should actually be
!metadata_key_dir.empty(), since 'metadata_encryption' is the encryption
options, which can be empty if the defaults are sufficient.
Rename the field in FstabEntry appropriately.
To avoid breaking fstab files, don't rename the flag in the fstab file
itself. So, now the fstab flags map to FstabEntry fields as follows:
keydirectory => metadata_key_dir
metadata_encryption => metadata_encryption_options
Change-Id: I5bf673047c99e077bd6e1ac006d80e7e16bc814b
This reverts commit 471643a909.
Reason for revert: Given https://r.android.com/1960063, it is safe to revert this diagnostics patch
Change-Id: Ib3600c1982ee10a0204ac0fdbc3e160c2833ed07
async merge.
If there are any I/O errors during async merge, we will
retry the I/O in synchronous I/O path. For this to happen,
we have to reset the iterator so that we replay the blocks
which were partially completed during async merge. Furthermore,
we will disable the async merge and continue to do the I/O
in synchronous path.
Additionally, cut down the queue depth to 8 so that
it will decerease the number of the async offload. We don't
want to have a big queue depth with async offload.
Bug: 220991038
Test: Instrument the code to fail the Async I/O's
randomly and make sure merge is completed. Instrumentation
was done both on readahead and merge code path.
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I0db6d0f46054ca5b8423201a598c726b2c3d21ac
This piece of comment was misleading because it only applies to
BOARD_USES_RECOVERY_AS_BOOT devices. Update the text to give a more
accurate description.
If BOARD_USES_RECOVERY_AS_BOOT is true,
* Recovery ramdisk IS boot ramdisk.
* init_first_stage is actually a symbolic link to
init_second_stage.recovery, which links libfs_mgr.recovery.
If BOARD_USES_RECOVERY_AS_BOOT is not true,
* init_first_stage is a real binary in the generic ramdisk.
* init_first_stage links libfs_mgr.ramdisk.
* During recovery boot, the '/init' binary could be the
init_first_stage from the generic ramdisk (A/B), or
init_second_stage.recovery from the recovery ramdisk (non-A/B;
standalone recovery partition).
Bug: 219811240
Test: None
Change-Id: Ib395a796f61869c13f1a5f1735ef17c224c26c8c
