search

bringmeup / hub

1 stars 0 forks source link

"Enter password to start Android" #9

Open nazgee opened 6 years ago

nazgee commented 6 years ago

When working wit LVDS bringup I rebooted board very often, and I end up with 'encrypted' data partition.

http://androidxref.com/7.1.1_r6/xref/packages/apps/Settings/src/com/android/settings/CryptKeeper.java#219

nazgee commented 6 years ago

I tried this on a /data/ partition (from a host machine):

$ sudo fsck.ext4 -v /dev/sdf4

And I got this:

e2fsck 1.43.5 (04-Aug-2017)
data: recovering journal
JBD2: Invalid checksum recovering block 1 in log
JBD2: Invalid checksum recovering block 1 in log
JBD2: Invalid checksum recovering block 1 in log
Journal checksum error found in data
data was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1401077, counted=1401057).
Fix<y>? yes
Free inodes count wrong (368391, counted=368377).
Fix<y>? yes

data: ***** FILE SYSTEM WAS MODIFIED *****

        1095 inodes used (0.30%, out of 369472)
         123 non-contiguous files (11.2%)
           1 non-contiguous directory (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 1038
       75546 blocks used (5.12%, out of 1476603)
           0 bad blocks
           1 large file

         360 regular files
         677 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
          48 symbolic links (48 fast symbolic links)
           1 socket
------------
        1086 files

... and it fixed the problem. Not sure if I've lost any data or broke something. Maybe this step should be done each time we attempt boot? Not sure if we have proper version of fsck available on target, though.

di0x7c5 commented 6 years ago

In ML10 before the file system is mounted, this check is done by Vold. In my understanding because ramdisk is mounted before running vold (vold is part of ramdisk), so this check is never done. However, We should make sure why this problem occur. I suspect that you turn off the power supply when SD card was in use (probably during saving some apk data or something). This is why SD card screamed that it was not "cleanly unmounted". I'm suggesting to using dd save a big part of data (from /dev/random) to sdcard and during save turn the power off. After that check if problem is present.

nazgee commented 6 years ago

I think that we had this issue because selinux prevented fsck to work -- this should not happen anymore, so this issue should never occur again...

I think we can add check flag to mount options for data parition to force fsck on every boot in /fstab.freescale

see:

nazgee commented 6 years ago

This patch forces fsck on every boot for data partition

--- a/nexo/fstab.freescale
+++ b/nexo/fstab.freescale
@@ -16,7 +16,7 @@
-$BD5    /data     ext4    nosuid,nodev,nodiratime,noatime,noauto_da_alloc,errors=panic                     wait,encryptable=$BD9
+$BD5    /data     ext4    nosuid,nodev,nodiratime,noatime,noauto_da_alloc,errors=panic                     wait,check,encryptable=$BD9

Unfortunately, our fsck version is not good enough. I recall, that I had to get a bleeding-edge fsck version on my Ubuntu machine in order for fsck to be able to work with (and fix) data partition:

fs_mgr: Running /system/bin/e2fsck on /dev/block/mmcblk0p5
random: e2fsck urandom read with 18 bits of entropy available
e2fsck: e2fsck 1.42.9 (28-Dec-2013)
e2fsck: /dev/block/mmcblk0p5 has unsupported feature(s): metadata_csum
e2fsck: e2fsck: Get a newer version of e2fsck!
e2fsck: e2fsck terminated by exit(8)

Also, we get plenty of selinux violations:

audit: type=1400 audit(1521944394.500:3): avc:  denied  { getattr } for  pid=195 comm="e2fsck" path="/dev/block/mmcblk0p5" dev="tmpf
s" ino=161 scontext=u:r:fsck:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1
audit: type=1400 audit(1521944394.530:4): avc:  denied  { read } for  pid=195 comm="e2fsck" name="mmcblk0p5" dev="tmpfs" ino=161 sco
ntext=u:r:fsck:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1
audit: type=1400 audit(1521944394.550:5): avc:  denied  { open } for  pid=195 comm="e2fsck" path="/dev/block/mmcblk0p5" dev="tmpfs" 
ino=161 scontext=u:r:fsck:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1
audit: type=1400 audit(1521944394.570:6): avc:  denied  { write } for  pid=195 comm="e2fsck" name="mmcblk0p5" dev="tmpfs" ino=161 sc
ontext=u:r:fsck:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1
audit: type=1400 audit(1521944394.590:7): avc:  denied  { ioctl } for  pid=195 comm="e2fsck" path="/dev/block/mmcblk0p5" dev="tmpfs"
 ino=161 ioctlcmd=127c scontext=u:r:fsck:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1
nazgee commented 6 years ago

not able to reproduce :/

nazgee commented 6 years ago

still able to reproduce -- 2 times today...