Analyzing boot loop Root cause from console-ramoops-0 ( & logcat)

Question

Summary - Update 2:
I am not deleting the question content, to preserve history ( but an admin may if appropriate delete that content) but things have change since. A day after I can into the below mentioned TWRP createTarFork() error 255 issue I could manage the data restore /data from TWRP Nandroid backup. The issue is for 2nd install of the same stock ROM - I run into a bootloop. The TWRP backup itself was from an Encrypted partition being restored to another partition ( Encrypted or otherwise regardless ). Trying to get to the RC of the bootloop & some way I an restore my /data I've attached logs of bad & normal boot below.

this is older history. May go directly to update 1 below , skipping it :
Boot-looped and got stuck in powered by android logo. Logcat hasnt been much useful. Wanna know what's causing the stuck. All I have is this from /sys/fs/pstore/console-ramoops-0

'[email protected]::ISensorManager/default': No such file or directory

I am attaching Entire /sys/fs/pstore/console-ramoops-0

what seems the issue ?
I have TWRP backups of vendor system boot that i tinkered restores with. No Luck. This is stock MIUI ROM with TWRP as recovery base so after flashing dm-verify-no encrypt.zip ( cant recall the exact name ) + certification.zi & permssiver I get past MIUI logo but now looping at powered by android logo

fsck outcomes

    olivelite:/ # e2fsck /dev/block/mmcblk0p60
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p60: clean, 4614/65536 files, 184349/262144 blocks
olivelite:/ # fsck /dev/block/mmcblk0p60
/sbin/sh: fsck: not found
127|olivelite:/ # e2fsck -v /dev/block/mmcblk0p60
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p60: clean, 4614/65536 files, 184349/262144 blocks
olivelite:/ # e2fsck -v /dev/block/mmcblk0p59
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p59: clean, 4547/262144 files, 680379/1048576 blocks
olivelite:/ # e2fsck -v /dev/block/mmcblk0p62
e2fsck 1.43.3 (04-Sep-2016)
data: clean, 62826/1389536 files, 3383723/5667584 blocks
olivelite:/ # e2fsck -v /dev/block/mmcblk0p57
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p57: clean, 33/98304 files, 22707/98304 blocksenter 

fsck sounds clean for all partitions
Here is the **logcat** & here's **dmesg** from logcat it could be a decryption issue. But that's only for boot twrpasks for pattern and decrypts just fine. Why cant it happen during boot- that's my hunch on the prob. Not trying to lure in that direction. Like Mikko said pretty much everything screams so its difficult to nab the culprit
Gonna try /data backup wipe and restore lets see...
. Update
as I suspected it appears to be encryption related. the previous successful install had a pattern lock ( at the time that install was built, I flashed - permissiver.zip, certificate.zip & dm-verity-force-encryption w default ops to disable verity & disable forced encryption ) - butTWRP nandroid backup itself is never encrypted. When tried to restore it - I always ended up with TWRP createTarFork() error 255 which is a very generic error - with multiple RC's. In my case it happens immediately ( previous data was wiped & formatted all relevant partitions . Only way I could successfully restore was use flashtool ( that runs fastboot commands underneath ) to install stock -> fastboot twrp & patched magisk boot install and then restore /data ( after running magisk & dm verity attempt twrp restore ) - in that case restore was successful. So with above steps I could successfully restore /data but that restored /data will get stuck in bootloop ( if twrp backups arent encrypted , why then does a simple wipe & format not allow TWRP restore ? only flashtool de-novo stock install will permit restore ? . I read a bug in twrp will not let backup from encrypted partition be restored onto un-encrypted ..ok so I also encrypted de-novo stock install with same pattern & after successfully restoring /data got stuck in the same bootloop again ) .
while I am using this de-novo stock install right now with 'bare minimal survival kit' apps. I could pull up logs of what a successful boot looked like to compare with boot loop after /data restored I uploaded earlier ( as suggested by Mikko - need bad boot and normal boot logs to compare ) .
So the big Question
is how in the world can I get back /data to restore from my Nandroid backup without boot looping
Uploaded these :
Normal boot pmsg-ramoops , dmesg, ramoops ( last 2 are pretty much the same - if you read ramoops- good enough ), logcat Needless to say restore's being attempted on the same stock ROM

Answer 1

If you run stock firmware and it's bootlooping, there's really not much that you can do because you don't have source code to the firmware you're running.

Your boot log seems to have a couple of interesting parts. I think this might suggest some kind of permission problem. Have you touched SELinux stuff (e.g. changed ACLs)?

[    0.629174] ------------[ cut here ]------------
[    0.629189] WARNING: CPU: 0 PID: 1 at /home/work/olivelite-p-stable-build/kernel/msm-4.9/drivers/base/core.c:600 device_create_file+0x7c/0xac
[    0.629193] Attribute otg_status: write permission without 'store'
[    0.629197] Modules linked in:
[    0.629205] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.112-perf-gd9f74a7 #1
[    0.629209] Hardware name: Qualcomm Technologies, Inc. SDM439 (Flattened Device Tree)
[    0.629226] [<c0113194>] (unwind_backtrace) from [<c010dbc0>] (show_stack+0x20/0x24)
[    0.629235] [<c010dbc0>] (show_stack) from [<c04e791c>] (dump_stack+0x94/0xa8)
[    0.629245] [<c04e791c>] (dump_stack) from [<c012f760>] (__warn+0xf8/0x110)
[    0.629253] [<c012f760>] (__warn) from [<c012f7d0>] (warn_slowpath_fmt+0x58/0x74)
[    0.629260] [<c012f7d0>] (warn_slowpath_fmt) from [<c0761e24>] (device_create_file+0x7c/0xac)
[    0.629271] [<c0761e24>] (device_create_file) from [<c087ebc8>] (msm_otg_probe+0x1668/0x1c28)
[    0.629281] [<c087ebc8>] (msm_otg_probe) from [<c0769a10>] (platform_drv_probe+0x48/0xac)
[    0.629289] [<c0769a10>] (platform_drv_probe) from [<c0767860>] (driver_probe_device+0x244/0x2f0)
[    0.629297] [<c0767860>] (driver_probe_device) from [<c07679d4>] (__driver_attach+0xc8/0xcc)
[    0.629303] [<c07679d4>] (__driver_attach) from [<c07652dc>] (bus_for_each_dev+0x8c/0xd0)
[    0.629311] [<c07652dc>] (bus_for_each_dev) from [<c07670e0>] (driver_attach+0x2c/0x30)
[    0.629317] [<c07670e0>] (driver_attach) from [<c0766c70>] (bus_add_driver+0x1ac/0x224)
[    0.629324] [<c0766c70>] (bus_add_driver) from [<c0768768>] (driver_register+0x9c/0x120)
[    0.629331] [<c0768768>] (driver_register) from [<c0769974>] (__platform_driver_register+0x50/0x58)
[    0.629341] [<c0769974>] (__platform_driver_register) from [<c16473dc>] (msm_otg_driver_init+0x1c/0x20)
[    0.629350] [<c16473dc>] (msm_otg_driver_init) from [<c0101ccc>] (do_one_initcall+0x60/0x1a4)
[    0.629359] [<c0101ccc>] (do_one_initcall) from [<c1601070>] (kernel_init_freeable+0x1f4/0x2b0)
[    0.629369] [<c1601070>] (kernel_init_freeable) from [<c0f7fd4c>] (kernel_init+0x18/0x158)
[    0.629378] [<c0f7fd4c>] (kernel_init) from [<c0108a10>] (ret_from_fork+0x14/0x24)
[    0.629384] ---[ end trace 09e0ec112fb2ab2d ]---
...
[    3.606115] init: Couldn't load property file '/odm/default.prop': open() failed: Nk such file or directory: No such file or directory
[    3.606592] selinux: avc:  denied  { set } for  scontext=u:r:vendor_init:s0 tcontext=u:object_r:exported_secure_prop:s0 tclass=property_service permissive=1
...
[    5.976174] e2fsck: e2fsck 1.43.3 (04-Sep-2016)
[    5.976174] 
[    5.976210] e2fsck: /dev/block/bootdevice/by-name/persist is mounted.
[    5.976210] 
[    5.976222] e2fsck: e2fsck: Cannot continue, aborting.
...
[    7.388219] type=1400 audit(54437781.749:20): avc: denied { setattr } for pid=404 comm="init" name="shared" dev="mmcblk0p62" ino=1157358 scontext=u:r:vendor_init:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
[    7.399091] type=1400 audit(54437781.749:20): avc: denied { setattr } for pid=404 comm="init" name="shared" dev="mmcblk0p62" ino=1157358 scontext=u:r:vendor_init:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
[    7.399114] type=1400 audit(54437781.759:21): avc: denied { setattr } for pid=404 comm="init" name="tombstones" dev="mmcblk0p62" ino=514055 scontext=u:r:vendor_init:s0 tcontext=u:object_r:tombstone_data_file:s0 tclass=dir permissive=1
[    7.402174] type=1400 audit(54437781.759:21): avc: denied { setattr } for pid=404 comm="init" name="tombstones" dev="mmcblk0p62" ino=514055 scontext=u:r:vendor_init:s0 tcontext=u:object_r:tombstone_data_file8s0 tclass=dir permissive=1
[    7.402193] type=1400 audit(54437781.769:22): avc: denied { write } for pid=404 comm="init" name="misc" dev="mmcblk0p62" ino=385537 scontext=u:r:vendor_init:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
[    7.402323] type=1400 audit(54437781.769:22): avc: denied { write } for pid=404 comm="init" name="misc" dev="mmcblk0p62" ino=385537 scontext=u:r:vendor_init:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1
[    7.402339] type=1400 audit(54437781.769:23): avc: denied { add_name } for pid=404 comm="init" name="dts" scontext=u:r:vendor_init:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1

Also note the e2fsck aborting in the middle of the process.

I would guess SELinux config being messed up or a filesystem corruption.

You'd really need a log from correctly booting phone with the identical firmware version to compare to know for sure. In many cases official vendor firmware is a piece of crap that may emit all the above errors on every boot so you really cannot know if you're looking at red herring.

Usually the only good way to debug issues like this is to take full boot log from known working phone and compare it to full boot log from a phone that doesn't boot. (Obviously you need a comparision tool that can ignore the timestamps at the start of the lines. I'd use meld with filters.)

Usually the problem is caused by the first error in the log. However, as I mentioned, vendor firmware often have lots of errors on every boot so you cannot know which are fatal if you don't have known good boot log to compare. The line you mentioned in the question (ISensorManager/default) is way after all the above mentioned errors. I would assume that the ISensorManager failure is just a result of the other stuff going wrong.

Answer 2

Issues & solutions much as I could reach
Cant restore TWRP /data backup
Can't figure out why TWRP backup itself being un-encrypted ( albeit from an encrypted phone ) cant be restored to any phone with the same ROM. This is with TWRP 3.5.x. Work around was flash ROM de-novo ( wipe / format in TWRP did not work ) & then attempt restore. But I ran into bootloop. There is another solution that targets Luks Header , but did not bother going further down the rabbit hole.
I really appreciate Mikko's dig into those logs , which is understandably is boring and frustrating .much as I'd have like to accept his answer - it's way off. This is abs nothing to do with SeLinux( permissive 1 as the log shouts everywhere ) neither it was a corrupted fs ( e2fsck issue)

Bootloop after /data restore
Something to do with my older install being encrypted but I cant figure out presicely. I took my TWRP files and attempted manual restore :

$r --selinux --xattrs -vxpPf data.ext4.win003 /data/data/com.whatsapp

where r is /data/tmp/tar-arm as suggested here . My whatsapp data ( primary target of recovery besides other apps ) was straddled across 03 an 04 volumes and I ran into issues invalid tar format or some. The issue was not with backup but /data/tmp/tar-armwasn't capable . I pulled it into Linux and ran regular tar similarly and restored. Lesson : if tar utils says backup is bad - dont take it for-granted. It might be a bad tar