and run fsck with -f on clean shutdown instead.
With -f, fsck.f2fs always performs a full scan of the /data
partition regardless of whether the partition is clean or not.
The full scan takes more than 2 seconds on volantis-userdebug
and delays the OS boot.
With -a, the command does almost nothing when the partition
is clean and finishes within 20-30ms on volantis-userdebug.
When the partition has an error or its check point has
CP_FSCK_FLAG (aka "need_fsck"), the command does exactly the
same full scan as -f to fix it.
Bug: 21853106
Change-Id: I126263caf34c0f5bb8f5e6794454d4e72526ce38
We need to have partition.*.verified properties even when bootloader
is managing dm-verity mode, because we may have failed to set up the
verified partition and need a property to indicate this.
This means we still need to run fs_mgr_update_verity_state and walk
through all the partitions to verify the device mapper status, just
without updating verity mode.
Bug: 22489805
Change-Id: Iaf28185adb8b80e5452447e54e1f4e4417a34168
Using a getenv('OUT') in such a deep down function is a wrong design
choice. Replacing with explicit parameter that may be NULL in case
device specific files can be accessed from /.
Since TARGET_COPY_OUT_SYSTEM may be defined to something different than
system we also ensure that we use a path relative to TARGET_OUT to
compute path to fs_config_* files.
Bug: 21989305
Bug: 22048934
Change-Id: Id91bc183b29beac7379d1117ad83bd3346e6897b
Signed-off-by: Thierry Strudel <tstrudel@google.com>
If verity state is managed by bootloader, it will pass the verity
mode to the kernel in the androidboot.veritymode command line
parameter. Init copies the value to the ro.boot.veritymode property.
Check for ro.boot.veritymode in fs_mgr and use the value to set
dm-verity mode. If this property is not set, store verity state in
metadata as before, if a storage location is specified in fstab.
Bug: 21605676
Change-Id: Ife3c978c133248432c302583d3b70e179605fe42
(cherry picked from commit ac5c1224cf)
If verity state is managed by bootloader, it will pass the verity
mode to the kernel in the androidboot.veritymode command line
parameter. Init copies the value to the ro.boot.veritymode property.
Check for ro.boot.veritymode in fs_mgr and use the value to set
dm-verity mode. If this property is not set, store verity state in
metadata as before, if a storage location is specified in fstab.
Change-Id: Ife3c978c133248432c302583d3b70e179605fe42
This option only exists for ext4 filesystems, so it shouldn't be
used when mounting ext2/ext3.
This bug would cause the mount system call in check_fs to always fail
with ext2/ext3 filesystems.
Change-Id: I3c8938029357a4a4170355118b6757f61ff4b227
Using logical op on unitialized memory is a bad thing. Good thing
is that this bug is dead because the structure is completely
cleared later via create_verity_device() -> verity_ioctl_init().
Change-Id: Idf5515a888bc6216eda0e23885a789f9b0320bac
If the zramsize entry has a % size at the end, as in the following example:
/dev/block/zram0 none swap defaults zramsize=25%
then we will set the value as that percentage of total RAM, as read by scanning
/proc/meminfo.
b/20760266 Seed common build allocated too much for zRAM-backed swap
Change-Id: I17c91d311ba99ae7adae112bfe1b38542ea69b80
Signed-off-by: Iliyan Malchev <malchev@google.com>
Move fastboot's format logic into fs_mgr, to consolidate the knowledge
about how to do this (and when to wipe metadata).
Try to format these formattable paritions if they are wiped.
If formatting fails, we will fall out to let recovery mode handle it.
Bug: 20082763
Change-Id: I397cc197550e78d932e8a154fd234695c46dbe7b
Daniel Rosenberg