Currently, this is only enabled for Virtual A/B devices. When /data uses
F2FS, then proper pinning support must be enabled.
Because /data cannot be mounted in recovery, we can't delete the scratch
image backed by /data while in fastbootd. Instead, we mark it as
disabled in /metadata. The remount command now has an init script that
checks for and removes a disabled scratch partition.
Bug: 134949511
Test: adb remount on V A/B device with patched F2FS
Change-Id: Ifc8720378259654472d3822e97059b6c366f601d
Marks this CTS test module as supporting secondary_user, meaning that
the tests are eligible to be run from a regular Android user other
than the system user (i.e. other than user 0).
Note that 'user' here refers to the concept of users in Android
Multiuser; it is NOT the same as a uid.
Bug: 141773058
Test: module passed with secondary_user params
(--enable-optional-parameterization --module-parameter secondary_user)
Change-Id: I1829a4297a49cd38b4b8a2558c92941acab8ab9a
Now the logic is handled by following API:
GetMountedEntryForUserdata(Fstab* fstab).
Behind the scenes it does the following:
1. Reads /proc/mounts and gets block device /data is actually mounted on.
2. In case of it's a dm-device, recursively goes into it's slaves until
finds the underlying block device.
3. Optimistically assumes that corresponding block device is a symlink
and tries to read it.
4. Reads all the entries corresponding to /data from fstab.
5. For each of them, optimistically tries to readlink block_device.
6. If it matches the resolved block devices, we found our fstab entry!
Also added a test to CtsFsMgrTestCases asserting that /data was mounted
from one of entries in default fstab.
Test: on blueline & taimen, with & without checkpointing:
Test: atest CtsFsMgrTestCases
Test: adb reboot userspace
Bug: 135984674
Change-Id: Ic70daeeb18096c7b134004334cc674dacc6e36f3
We now defer parsing encryption options to the fscrypt library. To avoid
adding a dependency, we simply record the options string in the fstab
and defer parsing until it's needed.
Bug: 143307095
Test: cuttlefish still boots
Change-Id: Ied13ea2f731c63b0524aed11db6983a86dab9fa1
When aosp/1149619 is merged, userspace reboot will start to depend on
the fact that default fstab has an entry for /data, hence this test
to make sure that this is the case.
Bug: 135984674
Test: atest CtsFsMgrTestCases
Change-Id: I7a3c181a6b27a7b4dfc344ff04be712f3fe3376e
It was failing with:
Expected equality of these values:
mnt_opts
Which is: { "data=ordered", "discard", "noatime", "nodev", "nosuid", "rw", "seclabel", "sync" }
fs_options
Which is: { "data=ordered", "discard", "noatime", "nodev", "nosuid", "rw", "seclabel" }
Test: atest fs_mgr_unit_test
Change-Id: I3bb084d62e81fda8948a100515bdaad62d18bb54
Enable fsck phase for scratch filesystem. Solved a resulting
problem where the end of the fsck executable would result in a
SIGHUP to the caller.
Add some debugging details from adb-remount-test.sh script
Test: adb-remount-test.sh
Bug: 138577868
Bug: 139283818
Bug: 139226412
Change-Id: I129d86b7cf4e938001ba6db8d03247bc9903988d
Allow the encryption policy version to be specified as a third field in
the "fileencryption=" fstab option, and expose it through the fstab
record so that vold can use it.
Bug: 140500999
Test: tested as series; see If64028d8580584b2c33c614cabd5d6b93657f608.
Also updated and ran the fs_mgr unit tests.
Change-Id: If5d56f4c84c4cd51e3f14c0a861c3e3ab6ff903f
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
