writer->size() is block size aligned and could be bigger than remaining_bytes
If remaining_bytes is bigger, set remaining_bytes to 0 to avoid sub overflow error.
Bug: 136727859
Test: Successfully install a DSU
Change-Id: If493b0f206561239caec2ee234f7cfd70bf927a7
When both ext4 user data checkpoints and metadata encryption are
enabled, we are creating two stacked dm devices. This had not been
properly thought through or debugged.
Test: Enable metadata encryption on taimen (add
keydirectory=/metadata/vold/metadata_encryption to flags for userdata in
fstab.hardware)
Unfortunately metadata is not wiped by fastboot -w, so it is
necessary to rm metadata/vold -rf whenever you wipe data.
fastboot flashall -w works
fastboot reboot -w works
A normal boot works
Disable checkpoint commits with
setprop persist.vold.dont_commit_checkpoint 1
vdc checkpoint startCheckpoint 10
adb reboot
wait for device to fully boot then
adb reboot
Wait for device to fully boot then
adb logcat -d | grep Checkpoint shows the rollback in the logs
This tests encryption on top of checkpoints with commit, encryption
without checkpoints, and rollback, which seems to be the key cases.
Bug: 135905679
Change-Id: I24387a2943dce28b918c34894f24911b20429be7
Normally we reject complex dm targets that would invalidate or shift the
block mappings returned via FIEMAP/FIBMAP. Currently the only targets
allowed are crypt, default-key, and bow. This patch adds support for
"linear" as long as there is only one linear target and it targets
sector 0 of the underlying block device.
This is useful for testing gsid, so we can simulate how a
metadata-encrypted device works without having to create a dm-crypt or
dm-default-key node.
Bug: 134536978
Test: manual test
Change-Id: I7c12bc20d95ff4c90402e66bafb4cf2fce7818e2
device-mapper will accept a "major:minor" string in place of a path for
any target parameter that specifies another block devie. This is useful
to have a helper for, since it lets us avoid a call to WaitForFile().
Bug: 134536978
Test: manual test
Change-Id: I13fd6699dd5d405bfa676830825b006b7810aa0f
When stacking devices with dm-linear, it is possible to get a -1
alignment offset. In this case we should set alignment_offset to 0
rather than fail later trying to divide -1 by the sector size.
Bug: 134536978
Test: manual test
Change-Id: I3862fdda69531a3b230b7316707469a49ba871d6
To avoid introducing dependencies on target libraries, use a statically
compiled test instead.
Bug: 134912860
Test: run vts-kernel -m VtsKernelLiblpTest
Change-Id: Ie24cc8532c7821cb225c024c240c4d485557bfa7
Without this patch, fstab should decribe reserve_root=[# of 4KB blocks] in
f2fs mount option as well as reserved_size=[KB] in fsmgr flag to notify it
to framework.
With this patch, it should be just fine to use reserve_root=[# of 4KB blocks]
in fstab.
Bug: 135003600
Test: checked vold.has_reserved
Change-Id: Iab75f7da9792ad205a6c4d2d0f1eba8c16a5266a
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
Normally MetadataBuilder will refuse to create non-suffixed partitions
on A/B devices. There are some scenarios where this doesn't make sense,
like when gsid needs to build metadata files for
system_gsi/userdata_gsi. It also doesn't make sense for the "scratch"
partition, so we added exceptions.
It turns out that metadata created by gsid cannot be re-imported by
MetadataBuilder, because there's no opportunity to set the "ignore" flag
in MetadataBuilder's constructor. Rather than plumbing a flag through, I
think we should just remove this error. It has too many exceptions
already and it doesn't really protect against anything. The motivation was
to avoid confusion in fastbootd on retrofit devices (where there are two
super partitions), but it's a pretty minor concern.
Bug: 134536978
Test: liblp_test gtest
Change-Id: I4629a3c46070c35bcce1017096338e72aa234371
Right now we completely unwind a device-mapper stacking, but this will
produce incorrect results if the stack doesn't have a 1:1 block mapping.
For example, extents against a dynamic partition will be invalid if used
against the underlying block device (super). In this case, abort the
device-mapper unwinding early, and leave it to the caller to decide if
the device is valid.
In addition to fixing a potentially serious bug, this will allow us to
test gsid by simulating various device types (FBE vs FDE, for example).
Bug: 134536978
Test: fiemap_writer_test gtest
Change-Id: I8164e2b71c4868f5494e17e08d209b65fa0ed4ef
There are cases where fsck.f2fs -f helps to recover from
corruption and thus helps to mount f2fs successfully.
CRs-Fixed: 2458080
Change-Id: I8d91835e464ef86e6ad4f96b7ac83f9f3d57c14f
These tend to get manually, so let's promote to actual helpers.
Bug: 134536978
Test: liblp_test gtest
Change-Id: Ifb79c8d6f247cc3f9635bf6adfd1c99907340002
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
If we just disabled verity, take the step to setup the backing
storage for overlayfs.
Test: adb-remount-test.sh
Bug: 130131892
Change-Id: Ic56569eaf363e4417a0ce5df11ee5480a07b8b03
Cosmetic fix.
If overlayfs gets setup by the remount command, ask user to reboot
since the device is not 100% in a state to run, and is merely only
in a state to take push and sync operations.
overlayfs is only truly ready for developing and running if the
overly mounts had occurred in first stage init, this happens when
the device is rebooted.
We did not completely remove overlapping dead ext4 dedupe code in a
previous change, complete the process.
Simplification for adb remount, the message:
Now reboot your device for settings to take effect
will only occur on the pass that causes the overlays to be populated,
in the same boot session. If subsequent, and ineffectual in any case,
remount command occurs again, it will not request a reboot.
Test: adb-remount-test.sh
Bug: 130131892
Change-Id: I7c4f408546687c49249883e2641b9bc63f68afd0
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
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
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 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
Regression from commit 77c28476f1
("Remove the mount points defined in skip_mount.cfg from
ReadDefaultFstab()") resulted in ReadFstabFromFile to report
errno ENOENT even upon success, preventing clear error propagation
for real failures (ReadFstabFromFile would _always_ report ENOENT).
The bad error propagation resulted in an adb remount failure.
Added immunization against future adjustments that may also
result in a similar regression in adb remount behaviors.
Test: adb-remount-test.sh
Bug: 132594161
Bug: 128961335
Change-Id: Icf5d48bbfc6d938d4b9657ca8004a6a6ddaab5a6
