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
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
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
The intention of inserting this synthesised mount entry is for the
FirstStageMount() procedure to eventually fallback to this entry if all
previous mount lines failed.
In order for FirstStageMount() to retry mount, the mount lines have to
be grouped together.
This change ensures that would happen and add test.
Bug: 220074274
Test: atest CtsFsMgrTestCases
Change-Id: Id042a6a6738d27c06a397ef7f4e0977907371c05
Since Android 10, new devices have been required to use FBE instead of
FDE. Therefore, the FDE code is no longer needed.
Make fs_mgr reject fstabs where FDE is enabled.
Unfortunately, there is a quirk where the "encryptable" flag (which was
originally meant just for FDE) was overloaded to identify adoptable
storage volumes. It appears that we have to keep supporting this use
case. Therefore, don't reject the "encryptable" flag completely.
Instead, just reject "encryptable" when it appears without
"voldmanaged", or without "userdata" as its argument.
Here are some references for how "encryptable=userdata" is being used to
identify adoptable storage volumes:
* https://source.android.com/devices/storage/config#adoptable_storage
* f26c7e9b12:system/vold/main.cpp;l=269
* f26c7e9b12:device/google/cuttlefish/shared/config/fstab.f2fs;l=17
* f26c7e9b12:device/generic/goldfish/fstab.ranchu;l=7
[ebiggers@: modified from a WIP CL by paulcrowley@]
Bug: 191796797
Change-Id: I3c4bbbe549cc6e24607f230fad27ea0d4d35ce09
This reverts commit 0a799bdfd6.
Now that the kernel bootconfig feature has been to updated to handle
mixed subkeys and values, androidboot.hardware parameter is supported.
Test: build and boot Cuttlefish with "androidboot.hardware=cutf_vm"
Bug: 191502832
Change-Id: I0e436a27730d20689bc6974562c3e88d744385db
Our CI is failing because the host machine is using mawk instead of gawk.
mawk v1.3.3 cannot parse regex such as '/[/]/', while mawk v1.3.4 and
gawk can.
Change regex of '[/]' to '\/' so that our test script is as backward
compatible as possible.
Bug: 188862155
Test: Run adb-remount-test.sh on CI
Change-Id: Ia4fbce58a61325a5e5280ede0d5b7760832d8ec1
Refactor skip_administrative_mounts so that it filters by device name,
mount point and filesystem type. (Was filtering by device name and mount
point.)
We need this because pseudo filesystems such as tmpfs and overlayfs can
have free-formed device name:
blah /mnt/mnt_point overlay ro,lowerdir=...
However the filesystem type (third field of /proc/mounts) must be
reflecting the actual filesystem, so to robustly filter out
administrative filesystems, we have to check the filesystem type field.
Bug: 188862155
Test: adb-remount-test.sh
Change-Id: I5058cbe8a36920f25b73a5d5833e9fc5a096e90f
fs_mgr flags "slotselect" and "slotselect_other" are specific to A/B
devices, so remove these options from testcases because
CtsFsMgrTestCases could be ran on a non-A/B device.
Fixes: 187759127
Fixes: 187427233
Test: atest CtsFsMgrTestCases on sdk_phone64_x86_64-userdebug
Change-Id: I31c1429652629bb68e0ca504295c959ac7e013e2
And use the new fs_mgr C++ API.
Bug: 186504948
Test: atest CtsFsMgrTestCases
Test: atest CtsFsMgrTestCases in DSU
Change-Id: I80d68d72fb3aa9f5a0dc7d9400b4d0f80cc7deb3
As ReadFstabFromFile() may append / remove / modify the fstab read from
the file, we cannot make assumptions about the number of fstab entries.
We can however test that the returned fstab contains at least the
entries we expect.
Fixes: 185826755
Test: atest CtsFsMgrTestCases on GSI & DSU
Change-Id: I539e7eed3f7ae14db7e9983bed7f68754c9fff39
This patch adds an option, readahead_size_kb in fstab entry option. It supports
to set a proper readahead_size per block/dm devices before using them by mount,
which is useful for low/high-end devices when addressing memory pressure issue.
Bug: 181567573
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I549962e68f8488417d76bcfb283958bc33fd5d7a
The parameter "androidboot.hardware" has been removed from bootconfig
and replaced by "hardware" parameter.
Test: launch_cvd with 4.19 and 5.10 kernels
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: I627426ae1bd0a165b70b8f2584ec184abfb4236f
As parameters are moved from kernel cmdline to bootconfig,
fs_mgr needs to be updated to handle the new location.
/proc/bootconfig should be checked first, if not present, then check
/proc/cmdline.
Test: atest CtsFsMgrTestCases
Test: launch_cvd
Test: launch_cvd with 4.19 kernel artifacts that do not support
bootconfig
Test: Both of the above configurations with --num_instances 0 or 4
Test: Both configurations with androidboot.boot_devices or
androidboot.boot_device set
Bug: 173815685
Change-Id: I23fb07a17c25c9459833cb931ced79d5ccc3e42a
Androidboot parameters are being moved from the kernel commandline to
bootconfig.
fs_mgr looks for these parameters in properties and falls back to
reading directly from /proc/cmdline. So both of these sources are
updated for bootconfig.
The androidboot parameters from /proc/bootconfig
are added as ro.boot properties, and fs_mgr will fall back to searching
/proc/bootconfig if it is too early.
Test: boot cuttlefish with androidboot.fstab_suffix and
androidboot.hardware in bootconfig and not in cmdline.
Test: atest CtsFsMgrTestCases
Bug: 173815685
Change-Id: Iea36a0da94c26e1aa37d97c576725e0ad77cd3ad
As we are just using it to generate gibberish, we might as well just
hardcode the gibberish in the script.
Also fix unhandled `grep` failure.
Bug: 179752308
Test: Forrest
Change-Id: I534c7cacdb12a104f26d380fe3a571332091490e
I'm getting this error:
[ FAILED ] /cache/overlay wipe
If /cache is not mounted, in which case it would be RO and empty, then
don't try to do `rm -rf /cache/overlay` as it would fail.
If /cache is RO and /cache/overlay doesn't exist, then `rm -f` would
fail, albeit the "-f" flag, this is a toybox bug.
Check file path existence before `rm`-ing so we don't trigger this error.
Change `ls <type> <path>` to `test <type> <path>` for robust checking.
Bug: 178683776
Bug: 165925766
Bug: 178771232
Test: adb-remount-test.sh on GSI + Pixel
Change-Id: Ie95de690d96146892127ab11a461d80cb6cb56fa
securityfs /sys/kernel/security securityfs rw,relatime 0 0
is causing the noatime check in adb-remount-test.sh to fail.
Bug: 165925766
Test: Create an aosp_cf_x86_phone-userdebug AVD && adb-remount-test.sh
Test: Use DSU to install GSI on the AVD && adb-remount-test.sh
Change-Id: Ibae0d4bbbbc78fb74f4ad82f2313251598c77f72
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
