diff options
| author | Eric Biggers <ebiggers@google.com> | 2020-08-04 11:11:13 -0700 |
|---|---|---|
| committer | Sayali Lokhande <sayalil@codeaurora.org> | 2020-11-30 18:05:00 +0530 |
| commit | a0186aba4aed74447c8a9eb8fe00a4dba2b0fb46 (patch) | |
| tree | dbee248bf5e17f9ee996ec4895aa2bc2d12170ad /init/builtins.cpp | |
| parent | 1ce494d98a38e1534020f793b7a876782792e46c (diff) | |
fs_mgr: Revert "Try to recover corrupted ext4 /data with backup superblock"
This reverts commit 72abd7b246f733e5f417e2bc529c9b482c4a778b
(change Ia39af3340c0e241f62557b7c2cc8b800443342f9).
When vold enables either FDE or metadata encryption, it encrypts the
filesystem in-place. Unfortunately, due to a bug, for ext4 filesystems
it hasn't been encrypting the backup superblocks.
Also, in read_ext4_superblock(), the check for
StartsWith(blk_device, "/dev/block/dm-") can return true even if the
encryption mapping hasn't been added yet, since when a GSI image is
booted the userdata block device is a logical volume using dm-linear.
The result is that read_ext4_superblock() can recognize a backup
superblock when the encryption mapping hasn't been added yet, causing
e2fsck to run without the encryption mapping and corrupt the filesystem.
https://android-review.googlesource.com/c/platform/system/vold/+/1385029
will fix this for new or factory-reset devices. However, there probably
are many existing devices that already have their backup superblocks
unencrypted. Therefore, the EncryptInPlace fix isn't enough and we have
to revert the change that started using the backup superblocks too.
CRs-Fixed: 2828666
Bug: 161871210
Bug: 162479411
Change-Id: I279f84c072bc6c8d3e251a5e95c78f8d6c0d50ba
(cherry picked from commit dc3e897a881291c7803dd1fc517915952396dd98)
Change-Id: I5618ae005c5306b58d83b5e6ab47cea403605424
Diffstat (limited to 'init/builtins.cpp')
0 files changed, 0 insertions, 0 deletions