1

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

'android.frameworks.sensorservice@1.0::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

1
  • Universal Disable_Dm-Verity_ForceEncrypt.zip still has bug and will cause boot-loop on encrypted data (although not related to twrp bug restoring failure)
    – alecxs
    Sep 19 at 17:22
2

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.

2
  • 1
    Your boot log also had some random bytes intermixed with the text. The first random byte appears in the middle of timestamp on line This means that this is a DEBUG kernel. Jul 22 at 10:45
  • Yes it a debug kernel log it actually says so somewhere in the beginning. I am going to attach dmesg & logcat & Update the question. Thanks SO much for peeping in . BTW I ran permissiver ( flashed ) script. So By the time it was boot and dandy - Selinux was permissivve Jul 22 at 13:55
0

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

11
  • Note that it is not safe to use ROM that doesn't have SELinux enabled as your daily driver. It sounds that the ROM you're trying to use is just broken or if /data/tmp/tar-arm wasn't provided by the ROM, that's the problematic part of your adventure. If you have encrypted data partition, you have to use good enough TWRP version or you cannot actually have a working backup (it's easy to notice - if you have encrypted data partition, TWRP should prompt for password). Note that the backups made with TWRP are not encrypted; see android.stackexchange.com/q/188339/5738 for details. Aug 4 at 13:58
  • Howdy Mikko SeLinux 1 is kept so state in many Custom ROMs . In my case for stock ROM I keep it at 1 momentarily to see where all did I violate & accordingly change context before toggling but that is at ease . /data/tmp/tar-arm isnt expected as per what the link mentioned - you have to grab it from the smallest available gapp. Still dont follow why 1) that /data restore boot-looped 2) UnEncry'd backup from Encry Partcant be restored simply & causes Tar Fork found that as a bug report in an older TWRP version & this is few hoops ahead Aug 4 at 14:47
  • thanks Alec ..actually busybox tar as well as arm tar both were tried and they both threw up in the middle of the road so as to say. If it was a problem of wrongly using it - they'd not extract partially . Entire f would be rejected w something like 'not a tar archive' --this error was unexpected end of tar. AFA UUIDs are concerned. Yes I did that by a program I wrote that grabbed individual UID & GID after the apks got installed and run chown but that wasnt part of Q I asked. I will nonetheless put in an udpdate line for completeness Sep 19 at 1:48
  • Well bad might be a 'bad' name after all. It should at least be able to list out the contents vide tf option and that is just where it gives that error as welll . And on Linux it worked just fine no issues. So I guess the bad was reference to its incompatibility with my tar. AFAIK when I made that tar using TWRP I never used the compress option. I grabbed an ARM tar based on the link choosing the smallest package size...should have delved into it being available solo ... Sep 19 at 11:58
  • so you say the malformed header is not caused by twrp-tar on creating, and the error output (which is filtered with 2> /dev/null in linked question) does only appear on arm but not on x86? that's strange because I always get it. what is your linux tar version, is it star maybe (because that's what twrp-tar is based on)?
    – alecxs
    Sep 19 at 17:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.