Regression from commit 808763e825
("fs_mgr: overlayfs: noatime"). Test fails on some targets
that do not follow our advise to mount noatime for all partitions.
blueline mounts the system partitions relatime. In the grand
scheme this is not a problem because we never remount these
partitions read-write because of the overlayfs integration.
Filter out read-only mounts from those enumerated for noatime,
those failures do not concern us in the context of this test.
This test expected to fail if CtsOsTestCases EnvironmentTest fails.
Test: adb-remount-test.sh
Bug: 140253722
Bug: 140014856
Change-Id: I778e7f539ac3f3d6495867e264767f2af25e11c7
Should not have used relatime for overlayfs and backing storage
mounts, noatime reduces the wear and tear on the flash device.
This should prevent triggering a falure in the CtsOsTestCases that
tries to spot mounts attached to block storage from updating atime
and resulting in churn. This statement does not mean we support
performing Cts tests with devices that have deployed
'adb disable-verity' or 'adb remount'.
Post-mortem: relatime was not a 'problem' for overlayfs, copy and
paste for those flags resulted in the use of relatime
for scratch backing storage.
Test: adb-remount-test.sh
Bug: 140014856
Change-Id: Ic97b98ceacaa265094364487ea70cc99b6aee92f
Beside using the 1% threshold for determining that a filesystem
should be an overlayfs candidate, do so also if the free space
is below 8MB. This will cover nearly empty filesystems that can
not be right-sized below the smallest ext4 filesystem size.
Adjust the test to cover the new cases.
Should test all system partitions, including new /system_ext and
any others that get added in the future.
Fix instance of dir that were supposed to be die. Using || die
does not work as expected within a function, so use if ! <cond>.
Test: adb-remount-test.sh
Bug: 139471424
Change-Id: If3e4cac5dce7bee998727052130eaf362e9e2fb5
For devices that do not have verity, or start the test with
verity disabled, but are using overlayfs, use a 'secret' surgical
technique to revert the device back to original state.
adb enable-verity will carry risk in that if the device did not
arrive with verity enabled, we can not guarantee it will boot
if we turn on verity.
Test: atest adb-remount-sh
Bug: 138649540
Change-Id: If6d55c57fb9daca9305c42a4df2c18c7f8c5eefa
In 4.19+ kernels not yet patched, /system/priv-app/<file> can
cause EPERM on fstat of the directory, resulting in failure to
access content.
Test: adb-remount-test.sh
Bug: 138649540
Change-Id: I96d1acb3cdb80824c9d2ebce415ea6e1253f9c5b
If the device screen drivers or frameworks are compromised, permit
remount testing without waiting for full boot complete to occur with
the --no-wait-screen option. In the same vein to support development,
add --wait-adb and --wait-fastboot options to adjust the timeout.
For TreeHugger testing where other (previous) tests demonstrate
framework or screen regressions, it _may_ be advised to switch to the
--no-wait-screen option so that we do not register a false signal.
It should be noted that some of the past issues with overlayfs and
adb remount could introduce boot up, framework or screen regressions,
so it is advised to not use the option if that interlocking logic can
not be set up.
Test: adb-remount-test.sh
Bug: 138649540
Change-Id: Idf8f4a0eb6d7c9139bd4f2c600d14a70dc71902f
After flashing empty image to scratch device, the device did not
return after 3 minutes. It also did not collect any triage data
reporting only:
[ FAILED ] did not reboot after flash
Add triage data, increase timeout to 4 minutes.
Test: adb-remount-test.sh
Bug: 132070014
Change-Id: Ic607abb5b2575d630bf6c27817a38a90820d24e1
restore() should not run adb enable-verity if device does not
use overlayfs even though it supports it.
Test: adb-remount-test
Bug: 132070014
Change-Id: I55d0e1a87eca9c5f258a1587c844f2a6e4b13b29
For the wipe and remount vendor test, report the df and
mount states to help triage.
Test: adb-remount-test.sh
Bug: 129319403
Change-Id: I4d9a87766d9857a974e601324ab77f69681bfd28
Check to make sure st_dev and st_ino for the uploaded content
is as expected.
Test: adb-remount-test
Bug: 129319403
Bug: 132395411
Change-Id: I89826fc2740dfd2ead4bcd8988cfbbc315b77b09
Check if adb remount resulted in any unlabeled references just before
rebooting the device.
Test: adb-remount-test.sh
Bug: 129319403
Bug: 132395411
Change-Id: Ica0c14da39773f615d9b5e4cfc4602bd50c70e4e
Increase adb_wait time to 3 minutes since blueline device takes
maximum 2:38 (ten samples) to perform a ramdump should an
inopportune kernel panic occur.
Test: adb-remount-test.sh
Bug: 132070014
Change-Id: Icfbb799f9420035a755090c9fc5fc2ee05dd68d3
Report any unusual durations for how long it took to wait for the
device to come back if --print-time flag. Also report the boot
reason if unexpected.
Test: adb-remount-test.sh
Bug: 132070014
Change-Id: I233bbc7b01b025739d7d63191cb62952fa4b7b2a
When developing and using the adb remount test, if device under test
is flashed from another source than the current visible tree, make
sure that the vendor image as-built and visible in a sandbox build
is not used indiscriminantly.
Test: adb-remount-test.sh
Bug: 132070014
Change-Id: I30569a7c871f4c4038b0f7f9c05f5f1a5d12c766
If we reboot too agressively after a fresh flash either just before
test is run, or after vendor is flashed, we run the risk the device
will consider it a bad boot and head towards recovery or revert to
previous system.
Add checks to wait for the screen.
This can result in the test reporting issues with boot complete,
which will not fail the test currently, but can be used to determine
if the device under test is in a boot loop or fragile state.
Test: fastboot flashall ; adb-remount-test.sh
Bug: 132070014
Change-Id: Ia1b3800c44222cb8fbd9b00e897b32a256996ebc
If device records a boot failure, the device could enter recovery
mode. If so, try another reboot to see if the device will heal.
Test: adb-remount-test.sh
Bug: 132070014
Change-Id: I4bee37e11f6344ab1ce176233d7d4e50df132cd7
If bootloader records a boot failure for a slot, the device can
enter fastboot mode. If so, set the expected slot and reboot.
Test: adb-remount-test.sh
Bug: 132070014
Change-Id: I801dcec7fd94ff084e54f585370d3c704a0de265
Get more details about the usb connection when it times out.
Test: adb-remount-test.sh
Bug: 132070014
Change-Id: I784bea3a2cefcef423b576854abb795add47d123
The code to read verity state in userspace is deprecated in favor of
having the bootloader read and report the state, so this change
removes this now unused code.
Bug: 73456517
Test: boot
Change-Id: Ib626fd61850bce3016179ca92a9831c2ac29c032
Unblocked the previous error we are now reaching the
default 5min timeout which is too short for this test.
Increase it to 1h.
Test: None
Bug: 117670584
Change-Id: I7fe40e54a7fb978392ee919226c0f05413e7349e
Older host adb client do not recognize reboot-fastboot,
switch it for "adb reboot fastboot" which should be the
same.
Test: None
Bug: 117670584
Change-Id: Iec5230ca66ec18fe7d7c0ebd3f9ab9596a6e7b3c
Add basic config that can run through atest the remount
script.
Very first step before being able to run in infra.
Test: atest adb-remount-sh
Bug: 117670584
Change-Id: I399f79fb7d7cd1b8a832be23efb3b625be693f7e
On taimen-eng build, the test reports:
[ WARNING ] user fastboot missing required to invalidate, ignoring a failure
ERROR: expected "cat: /vendor/hello: No such file or directory"
got "Hello World! Fri Mar 22 08:56:32 PDT 2019"
[ FAILED ] vendor content after flash vendor
Which is a result of a corner case problem on devices that need to
use overlayfs to support adb remount, but do not have fastbootd as
required by Dynamic Android Partitions (DAP). These legacy non-DAP
devices we consider this a Known Issue.
The message however is too alarming when reporting this Known Issue
that the test has notified you it accepts. Use standard notification
output format, and change the result to a series of WARNING instead.
The output would then look like:
[ WARNING ] user fastboot missing required to invalidate, ignoring a failure
[ WARNING ] expected "cat: /vendor/hello: No such file or directory"
[ WARNING ] got "Hello World! Fri Mar 22 08:56:32 PDT 2019"
[ WARNING ] vendor content after flash vendor
Which still tells us there is an issue, but does not cause a state
of extreme alarm when looking at the test output.
Test: adb-remount-test.sh
Bug: 120448575
Bug: 128876541
Bug: 123079041
Change-Id: I1d8d60f23f7670ade7eae1be629264f7507e0cfd
Add internal fs_mgr_is_ext4 and fs_mgr_is_f2fs to get heads up on
mount failures and thus bypass trying.
Test: adb-remount-test.sh
Bug: 109821005
Change-Id: Ieb1f8c19ced930b6fe2d1791ef710ce528da7e37
Report any discrepancy in the active slot.
Fix a problem with problematic error propagation for adb_cat()
Test: adb-remount-test.sh
Bug: 126256072
Change-Id: I8a5d4e364945c5e60d252333886987b8dca0cfb3
Can supply a specific partition to remount. Partitions can be
specified by name or mount point. Some extra work to differentiate
an unknown partition, invalid partition, or one that is covered by
overlayfs.
Test: adb-remount-test.sh
Bug: 122602260
Change-Id: Iab6f51c2b5ebe01f1cea3fb235445d5e2f495365
We should check if the fs_mgr option starts with "avb_keys" before
"avb". Otherwise, it will treat "avb_keys" as "avb" fs_mgr option.
Bug: 112103720
Test: atest fs_mgr_unit_test
Change-Id: I88446222fa88e8ecfcd6f96d30ad4336ebe146a8
The -R flag tells remount it can reboot to disable verity or to
run fsck on an ext4 deduped filesystem, or both.
Testing may include a manual component because adb-remount-test.sh
needs to run from a device in an enable-verity state to test this.
Only recognizes chained avb.
Test: adb-remount-test.sh
Bug: 122602260
Change-Id: I6ce4372532d9b933dcca9e2bec544d525b76c4d9
There is currently no good option for callers to setup overlayfs
on-device, it is automated as part of the adb services. Add a
remount command that does what is needed that simulates the salient
behaviors of the adb remount command.
Clean up some noise restoring device to original state when done.
Test: adb-remount-test.sh
Bug: 122602260
Change-Id: Idf213800a8182cb1c51600c8f574df8a8cd68d4a
Handle a device in recovery mode gracefully. Handle a device
that fails to boot into a commanded state more gracefully.
Deal with regression where die() calls restore(), and we can not
have this under the conditions where we are ignoring the error
in a subshell.
Test: adb-remount-test.sh
Bug: 118225373
Bug: 123079041
Change-Id: Ie37beb245d0ec55eb00757cdb93da34ff9c42827
The original adb-remount-test.sh when certifying kernels allowed a
pass on 4.4 kernels because it added new content, and missed a test
for overriding existing content. When the test was added to confirm
APEX control of libc.so, it serendipitously added a check for
overriding existing content, which the 4.4 kernel did not allow to
pass. Update the tests and documentation to reflect this new state
of affairs.
Summary: 4.4 kernel overlayfs driver worked partially without the
patch for override_creds.
Test: adb-remount-test.sh
Bug: 126256072
Change-Id: I979ea59a12bc0b9926826b9b09a7893ab3b9ee7f
Make it easier to collect test execution time.
Clean up some noise restoring device to original state.
Test: adb-remount-test.sh --print-time
Bug: 123079041
Change-Id: I56f12698ff25362dcefcf8a6ddd8f96a23b37f34
The copy of /data/* doesn't work now, so put the fstab content
into the unittest source instead.
Also replacing ReadFstabFromFd with ReadFstabFromFile, to prevent
race.
Finally, two test cases are temporarily disabled due to read
fstab file error (root cause is still unknown).
Bug: 124837435
Test: atest 124837435
Change-Id: Ib6a3d931a48bffd8be23bda23fa4492babafd166
Add a test that creates files in the appropriate vendor_overlay directory and
verifies that they are correctly overlaid (or not) onto /vendor after rebooting.
Test: locally running atest
Change-Id: I65860dbeb837f86ac030fa51b3af93844e82de96
Harden adb-remount-test.sh script. Add --no-color and --color
options. Allows --serial to be passed in. Add a recovery handler
that restores the device to verity enabled if possible. List the
partitions sizes as they may be relevant to triaging errors. Allow
for devices that have a mixed set of remounts, some direct, some
with overlayfs. Allow two scripts to run at the same time on a host
machine targetting different devices. Detect if wrong adb is used
for adb reboot-fastboot.
Add a build target for adb-remount-test.sh so that the script
is landed into the host tools bin for easy pickup.
Test: adb-remount-test.sh
Bug: 123079041
Change-Id: I6369a245a656419067ec4350a4dbdf78c9b0533e
Refactor fs_mgr_candidate_list into fs_mgr_overlayfs_candidate_list
that reports all the possible candidates. The caller is responsible
for filtering out any that have verity enabled.
Sundry improvements to the adb-remount-test.sh script to improve
stability and feedback.
Test: adb-remount-test.sh
Bug: 122602260
Change-Id: I2399f83d8ed77d8f3d2ad1405d0c187ccbace764
Expand the tests to deal with the boot environment for marlin.
Recognize that older overlayfs drivers do not report to /sys/module
and the parsing /proc/filesystem is another place to interrogate this.
Suppress adb push and pull noise during testing. Resolve APEX
failures. Add some cleanup to test script.
NB: Running test to completion is difficult because marlin's USB
driver is flakey enough through the multitude of reboots and
may not reconnect. The tester will have to notice when a reboot
is stalling and manually disconnect and reconnect the USB
connection to trigger discovery and to continue through the
test sequences. To make this easier, report when we are
waiting for the device to make it easier to babysit.
Test: system/core/fs_mgr/tests/adb-remount-test.sh
Bug: 120448575
Bug: 123079041
Change-Id: I5fc5f01b4e4788ac57541cb5235f7ac4e4284d71
Mark Salyzyn