OverlayFS on Device Mapper on Dynamic Partition / Split Fiemap doesn't
seem to report stable dev_t values of the underlying "wrapped" device.
For example, when not using overlayFS, the dev_t of a file in /system
may be something like 253:8, a dm-verity wrapped device (253 is device
mapper's major id).
When overlayFS is enabled, the /system mount point is mounted with a
overlayFS device wrapping a dm-linear device wrapping the actual storage
device. In this case, stat-ing a file in /system shows the dev_t to be
something like 0:23. Not only is the major id not correct, the minor id
is not stable across reboots, too.
For now, suppress the error and make it a warning so it don't report
false negatives. We may want to turn this check back on if the overlayfs
driver is fixed of this issue.
Bug: 165925766
Test: adb-remount-test.sh
Change-Id: I035caec3e00d179f227850cbc9835fb3aedf88e5
This allows colors to rendor according to user preferences
in terminal emulator settings.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: make sure colors make sense
Change-Id: Ie2749dcce66954deddbca2863dadfa270cc6633e
This script did not run on a MAC, adjust so that it is usable.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: script can be used to test and replicate reported problem
Change-Id: Id1c97b9cd85d150a96733b8d39e40f6a4bcc0721
Report kernel version as part of the report. Also warn user that
they are waiting for the screen to come up, and if the delay is
far too long, or the device is headless, then consider using the
--no-wait-screen option
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Test: adb-remount-test.sh
Bug: ????
Change-Id: I68d1757da62d028dc3633b1175b06af19e469d9f
Causes flakes as the ramdumpfs may temporarily be applied
to check and/or retrieve content.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 161454607
Test: no more flakes
Change-Id: I8e4b6a808ab81ec5b4f760a810b9b651a0b329d0
Some of the test cases in CtsInitTestCases and CtsFsMgrTestCases require
root. This CL makes it possible to run such tests cases on userdebug
builds, which in turn means that they will be run on presubmit.
New option was implemented in
https://android-review.googlesource.com/c/platform/tools/tradefederation/+/1283834
Test: atest CtsInitTestCases
Test: atest CtsFsMgrTestCases
Change-Id: I3d29789ddd7ac549e40ac193c58d986670c49285
Use realpath as a canonical representation of block devices. This makes
it easier to reason about block devices. This also fixes a bug, in which
fs_mgr_get_mounted_entry_for_userdata didn't properly work on devices
that don't support metadata encryption.
Test: atest CtsFsMgrTestCases
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 153363818
Change-Id: I139c2be46336a632bbaee86667019c075d7de814
Vendors may add additional functionfs mounts. Since these
will never be remounted, we can safely filter these out.
Bug: 153008210
Test: Test device with previously unfiltered entries.
Change-Id: I7f384b8a0ce93dd6701fe3c4d9dd2557370b31e1
The tests are only needed in vts10 suite.
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL removes vts10 tests from vts suite.
It won't change test logic or behavior.
Change-Id: I4d468be075b54213b56c7e1aa94af94f2bdce9ff
This is to prepare renaming vts to vts10.
Bug: 151896491
Test: local build
Exempt-From-Owner-Approval: This CL adds all tests in vts to a new
suite vts10. vts10 will be the new name of existing vts suite. This CL
won't change test logic or behavior.
Change-Id: I3c7ccef142de30f02a59046cecba121480f6e436
Logic of unwinding dm-device stack to figure out what entry was used to
mount userdata turned out to be a little bit more involved, and it
shouldn't be part of libfstab
This CL just moves code around and cleans API a little bit, actual fix
will be in the follow-up CL.
Test: atest CtsFsMgrTest
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 148612148
Change-Id: If0f8a765dba63adb0e6a711eb81fffdcabea3480
Merged-In: If0f8a765dba63adb0e6a711eb81fffdcabea3480
(cherry picked from commit 8f50cfc28d)
Logic of unwinding dm-device stack to figure out what entry was used to
mount userdata turned out to be a little bit more involved, and it
shouldn't be part of libfstab
This CL just moves code around and cleans API a little bit, actual fix
will be in the follow-up CL.
Test: atest CtsFsMgrTest
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 148612148
Change-Id: If0f8a765dba63adb0e6a711eb81fffdcabea3480
Change metadata_cipher fstab option to metadata_encryption
that includes encryption flags in addition to the cipher.
wrappedkey_v0 encryption flag is used to denote that the
inline encryption hardware supports wrapped keys. dm-default-key
device is created and a wrappedkey is provided along with the
optional wrappedkey_v0 argument.
Bug: 147733587
Test: FBE validation with Fscrypt v2 + inline crypt + wrapped
key changes kernel and metadata encryption with wrapped key.
Change-Id: Id1a18db175680dd6b0adb4594d06566eb1285785
To improve the test period for adb-remount-test.sh, if the device
fails to get to the launcher on the first try when wait_for_screen,
then print a warning to skip all later wait_for_screen conditions.
The wait_for_screen testing is really there to deal with first
confirming that the device is capable of getting to the launcher,
and that later tests that influence corners of adb remount behavior
do not result in a failure to get to the launcher screen. The
developer should look into ways to fix the failure to get to the
launcher on the first try, but failure to do so should have no
bearing on the remaining tests, so dropping the wait_for_screen
functionality is not an issue.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Test: adb-remount-test.sh
Bug: 148881519
Change-Id: I5b4a87d6e1f545a304eb74f2114aadd1128f25b3
Regression from commit cb1a8e7fdd
("Don't retrigger bootstat during userspace reboot.")
sys.boot_completed and either sys.logbootcomplete (legacy) or
sys.bootstat.first_boot_completed set to determine if the display
has gone active for bootstat. For adb remount test we have no
desire or need to wait for bootstat complete, reduce script
complexity.
Also solve a possible problem with no content supplied to xargs.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Test: adb-remount-test.sh
Bug: 148804390
Bug: 135984674
Change-Id: Ieefddf583ff7422e8811d2e338a0f16c8943b0d7
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
