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
Background:
We now have two sets of Bionic: the bootstrap Bionic which is at
/system/{lib|bin}/bootstrap for early processes and the default Bionic
which is from the runtime APEX for all the others. In order to give the
same path for Bionic to both categories of processes, the init prepares
two mount namespaces and bind-mount appropriate Bionic files onto the
common mount points under /bionic. For example,
/system/bin/bootstrap/linker is bind-mounted to /bionic/bin/linker for
the early processes. Likewise, /apex/com.android.runtime/bin/linker is
bind-mounted to the same path for rest of the processes.
In addition, in order not to propagate mount events in one mount
namespace to the other namespace, /bionic itself is created as a mount
namespace (via self bind-mount) and its propagation type is set to
private.
Changes required:
This however requires some adjustments to adb sync and remount
mechanism.
For remounting, /bionic path should also be re-mounted for RW, because
it is a RO mount in the beginning. This remounting is done only for the
system-as-root devices where entire / can be re-mounted as RW.
For synching, the sync thread creates a temporary mount namespace where
there is no bind-mount. This ensures that a path that the thread handles
is pointing to the correct file that is expected from the client side.
In addition, push operation to /bionic path is done without unlinking.
This is required because the mount points under /bionic are gone in the
current mount namespace but are still active in other mount namespaces.
If unlinked, the existing mounts on the path are all silently removed.
In order to prevent the unwanted situation, the moint points are not
unlinked but truncated to 0. This however is not a significant problem
because the files that serve as mount points do not carry any
useful information (i.e. the content is meaningless).
Bug: 879416
Test: adb sync
adb push <random_file> /bionic/bin/linker64
adb push <random_file> /system/bin/bootstrap/bin/linker64
system/core/fs_mgr/tests/adb-remount-test.sh
Change-Id: Id87dc9ee7ec5c43d06b54969b55e2cb394329317
It doesn't really make sense to have extra logic to convert these
strings to enums then back again to strings for usage, especially
since with the C++ fstab, these strings are small enough to fall into
the small string optimization of std::string.
This will help make future changes cleaner as well.
Test: boot, fs_mgr_test
Change-Id: I5669ed10f2fc3eafdb137747446a2e93c24d55c4
WAI: Using mount -o rw,remount command can only work after the
overlays are setup. After the second 'adb disable-verity' or
'adb remount -R' has been issued; the first only disables
verity and does not setup the backing storage. If mount remount
command is issued after the first on an overlayfs system, it will
report a r/o filesystem.
Add a test that confirms that at least this supported behavior is
working, we do not test the corner case.
In the case of overlayfs, we have declared we will not support the
mount remount operation until then; we would need to modify toybox
to add logic that resides inside adb remount service. toybox is
allowed to be adjusted to compile under Android and bionic, but it
is not supposed to have code that is specific to Android.
Fix last test to before this one to move us back into this state.
Fix the adb_sh command parser to handle properly quoting arguments
as it passes them to adb, since we will need it working for this
added test.
Report the product serial number of build description to aid triage.
Test: adb-remount-test.sh
Bug: 109821005
Bug: 122602260
Bug: 123079041
Change-Id: Ida051dbe2a918182db97f0f22f64b299e3c0a068
And fix a bug in the meantime, where mounts with no filesystem
specific mount options were incorrectly having an empty string in
their set of mount options.
Test: this test
Change-Id: I9b1f14d00a90f8b95a13fcecb3cfa7fe10a2f96a
If there is no userspace fastboot, then overlayfs has a corner case
bug where overlay content is not wiped when the partition is flashed.
We will report a warning instead.
This is done to reduce the flakiness of the test results as we do not
intend to fix this specific corner case in the short term. We would
require to record a sha representing the flash image, and the risks
were evaluated as too high of an impact on libavb to add interfaces
to expose the signatures, especially at first stage mount time. All
new devices must support Dynamic Android Partitions (DAP), which
means they all have support for userspace fastboot, it will be
considered a misconfiguration and thus the position is we will not
fix this issue and only use this test adjustment to deal with legacy
products. If a legacy non-DAP product wishes to close the issue
today, they must supply a user space fastboot.
Test: adb-remount-test.sh
Bug: 109821005
Bug: 123079041
Change-Id: I420cb87c19e3e184a974dfc373fb17c097d4858f
