We need to fix the below error happening in early stage.
[ 24.835617][ T1] init: [libfs_mgr]Running /system/bin/fsck.f2fs -a -c 10000 --debug-cache /dev/block/sda1
[ 24.843693][ T1] logwrapper: Cannot log to file /dev/fscklogs/log
Bug: 230637147
Bug: 230879192
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Change-Id: I19bc5f7154577e29414f855de6ce72172b281975
If there are snapshot metadata persisting in /metadata/ota/snapshots,
remove them before applying a new update. Make sure that
the snapshots are indeed invalid before removing them.
On a sidenote, add a comment in init.cpp related to
b/223076262.
Bug: 228250473
Test: 1: Apply OTA in recovery through adb sideload
2: Reboot
3: Apply OTA OTA again through update_device.py
4: Re-run Full OTA updates just from update_device.py
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I116bbafae09042b9c391ccd58c102704571c214e
In Android S, snapuserd binary was on vendor partition.
When there is an OTA update from S -> T, it is possible
that vendor partitions are not updated. In that case,
successive OTA updates T1 -> T2 will continue to have
snapuserd from Android S as vendor partition wasn't updated
to T. All this means, we should disable user-space snapshots.
When installing OTA during runtime, check for property
ro.vendor.build.version.release_or_codename; if the property
is set to "12", then skip userspace-snapshots.
Bug: 227614163
Test: Simulate OTA test on Pixel 6 from T1 -> T2 by forcefully
setting the property to 12 and verify OTA is applied
successfully by falling back to dm-snapshot.
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I95f29145e5cd9ffb8d03d28ae414f0037b88be90
Fix SnapshotUpdateTest.QueryStatusError which
was failing on targets where userspace-snapshots are not
yet enabled.
Bug: 224586316
Test: vts_libsnapshot_test -force_config dmsnap --gtest_filter=SnapshotUpdateTest.QueryStatusError
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Ibaacff9b03eafe0bfa537d0f9cab98b7caceb37e
This should be using unreserved free space, not total free space.
Bug: 223701928
Test: vts_libsnapshot_test
Change-Id: Ic0a657fe094b57734c93958d7e5da56fbfbada7f
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
This reverts commit 471643a909.
Reason for revert: Given https://r.android.com/1960063, it is safe to revert this diagnostics patch
Change-Id: Ib3600c1982ee10a0204ac0fdbc3e160c2833ed07
async merge.
If there are any I/O errors during async merge, we will
retry the I/O in synchronous I/O path. For this to happen,
we have to reset the iterator so that we replay the blocks
which were partially completed during async merge. Furthermore,
we will disable the async merge and continue to do the I/O
in synchronous path.
Additionally, cut down the queue depth to 8 so that
it will decerease the number of the async offload. We don't
want to have a big queue depth with async offload.
Bug: 220991038
Test: Instrument the code to fail the Async I/O's
randomly and make sure merge is completed. Instrumentation
was done both on readahead and merge code path.
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I0db6d0f46054ca5b8423201a598c726b2c3d21ac
This piece of comment was misleading because it only applies to
BOARD_USES_RECOVERY_AS_BOOT devices. Update the text to give a more
accurate description.
If BOARD_USES_RECOVERY_AS_BOOT is true,
* Recovery ramdisk IS boot ramdisk.
* init_first_stage is actually a symbolic link to
init_second_stage.recovery, which links libfs_mgr.recovery.
If BOARD_USES_RECOVERY_AS_BOOT is not true,
* init_first_stage is a real binary in the generic ramdisk.
* init_first_stage links libfs_mgr.ramdisk.
* During recovery boot, the '/init' binary could be the
init_first_stage from the generic ramdisk (A/B), or
init_second_stage.recovery from the recovery ramdisk (non-A/B;
standalone recovery partition).
Bug: 219811240
Test: None
Change-Id: Ib395a796f61869c13f1a5f1735ef17c224c26c8c
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
Certain code in libfiemap should be unreachable in recovery/ramdisk
builds, but whether intentionally or not, __ANDROID_RECOVERY__ is not
working in vendor_boot.
To make sure this is doing exactly what we want, use __ANDROID_RAMDISK__
instead.
Bug: 205987817
Test: build boot, vendor_boot, recovery
Change-Id: Id419f7d9068e791427a896c22569ae4543548df7
When creating a scratch partition on /data, use either the size of
super, or half the free space on /data - whichever is smaller.
Bug: 213617068
Test: adb remount
Change-Id: If42fe9e1dc53d5a0137ace917a440232f70947fa
This ensures that the dynamic "scratch" partition is removed when doing
a flashall operation.
If "scratch" is on /data, disable the partition. Add IsImageDisabled to
ImageManager so EnsureScratchMapped can skip mapping it. Also, fix
"scratch" not getting unmapped if on /data.
Bug: 205987817
Test: adb remount
adb sync
adb reboot fastboot
fastboot flashall --skip-reboot # no errors
Test: adb-remount-test.sh
Change-Id: I4b9702e1dac15fb663635506fb50a8274e1e10d1
I/O failures seen on one specific device intermittently.
Bug: 219642530
Test: OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I5b6fbfb13e40b15b25324b70efef11aede916596
* changes:
libsnapshot: Propagate io_uring enablement to daemon
snapuserd: Cut down worker threads
snapuserd: Terminate daemon spin up during first stage init
snapuserd: Avoid checking system properties when daemon launched from fist stage init and during selinux transition
During selinux init transition, system properties
are not yet enabled. Hence, store the io_uring feature
in snapshot.proto and propagate the same snapuserd
daemon
Bug: 214340811
Test: OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I5458127b00946b5254d5c68d407ab525a0075cb9
We don't need 4 threads per partition all the time.
Cut down to 1 thread for all purposes except during boot time.
During boot, we need multiple worker threads to serve
I/O's to speed up the booting process. For all other
purposes, single thread is sufficient. It will cut
down memory usage ~25MB.
Bug: 214340811
Test: OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: Ib36bf44c63676d3f3169fbda04b7fc3d1760cfbf
from fist stage init and during selinux transition
Bug: 207298357
Test: OTA
Signed-off-by: Akilesh Kailash <akailash@google.com>
Change-Id: I449de1939531dbf3cc35e05c80e51237c4dc2b99
