1

My android phone is stuck in a boot loop. To troubleshoot it I was able to boot into TWPR and use adb pull /sys/fs/pstore/console-ramoops to get some boot logs (is that even the right file?).

When opening the file in a text viewer it is very corrupted, with missing letters like in this example...

zalgo logs

Is there another procedure I can follow to either get a correctly encoded or uncorrupted log file or fix the one I got? It was literally the only way I found of pulling some logs from TWRP terminal...

On the troubleshooting part: prior to last known good status no particular action was done... just using telegram briefly.

Then I started getting crashes of system app so I rebooted. This now is the result...

Update: it seems that adb connects during the boot animation. I was able to do adb logcat -v time -b events -b main -b system -b radio >> boot.log and i got a stream of logs, will post the result once it's done boot looping or battery dies.

Update: indeed I was able to get real-time log of the boot process. It is boot looping since my logfile is growing bigger, so it's not "stuck".

Trying to look for information in the log I found this pattern of "waited one second"... which seems to indicate that something is not running or failing to run.

Here is a screenshot of what I mean:

enter image description here

The figure of 838 seconds waited seems right since I had my phone logging for about 15 minutes...

I am continuing to log until something happen, but now I think I need some help debugging this problem...

There seem to be two things that are waited for:

07-01 22:58:59.863 W/slim_daemon(  951): Waited one second for android.framework[email protected]::ISensorManager/default. Waiting another...

and

07-01 22:59:02.359 W//system/bin/cameraserver( 3000): Waited one second for android.hardware.ca[email protected]::ICameraProvider/legacy/0. Waiting another...

My conclusion for now is that there may be something wrong with camera or sensors...

This seems to be readings for temperature.. 53° is pretty hot...

enter image description here

Also this seems to imply that the battery stats dumping took 262k milliseconds. (?)

enter image description here

Are there things I can look for specifically in the log, like some known line or checkpoints like

enter image description here

I would attach the log file, but how can I clean any private data that may be in in there?

Initial problem is solved

I was finally able to boot, disabling the Xposed module did the trick:

  1. booted to TWRP recovery
  2. flashed Magisk Manager for Recovery Mode(mm-201904040.zip)
  3. run it in TWRP's terminal with */mm
  4. selected m) Magic mount
  5. selected xposed_27
  6. confirmed
  7. rebooted with the reboot command

It booted in safe mode, since I previously had modified some files to induce that, so I rebooted again from power menu and it booted normally.

Now I think I want to know what happened specifically so that I can re-enable xposed, since I have some modules I rely on for customizations.

Also with no configuration changes I'm still baffled at how the phone got bootlooped, i remember frequent ANRs of the system app to the point of not able to run anythng and rebooting.

Is it really xposed fault or merely disabling it removed a symptom of something else ?

So the question should be what in xposed caused this bootloop and how to prevent it from happening again ?

Improve this question
9
  • 1
    Mobile phones are off topic here.
    – HazardousGlitch
    Jun 30, 2019 at 18:45
  • In TWRP, have you tried to wipe dalvik and cache? If not, do it, reboot the phone. It might take a long time for the phone to start. Wait and see.
    – Reddy Lutonadio
    Jul 1, 2019 at 4:24
  • Yes, I tried multiple times. I rebooted the phone and it run out of battery (starting from full charge) over night...
    – beppe9000
    Jul 1, 2019 at 12:56
  • Make a backup via TWRP, then try to flash the phone's ROM (if you have it).
    – Reddy Lutonadio
    Jul 1, 2019 at 13:09
  • See update. I can actually get the log... the question should now focus on log file analysis i think
    – beppe9000
    Jul 1, 2019 at 13:21

1 Answer 1

Reset to default
0

Bootlooping with logs this messed up probably suggests that some other process is arbitrarily reading and writing from the io stream of the log file. In layman's terms, very bad stuff.

I think your best option is to just recover as much data as you can and reflash the ROM. Something has clearly gone very wrong.

Improve this answer
4
  • is the one i used the proper file for logs?
    – beppe9000
    Jul 1, 2019 at 13:22
  • i don't know much about, but ramoops is just a dump of RAM so its kind of normal that bytes have changed - its not a corrupt file, just a snapshot of overwritten area of RAM. instead of analyzing logs, how about analyzing reasons? what have you done between the last successful boot and the first time the problem occured?
    – alecxs
    Jul 1, 2019 at 15:10
  • It was literally the only way I found of pulling some logs from TWRP terminal... The problem is that no particular action was done... just using telegram briefly. Then I started getting crashes of system app so I rebooted. This is the result... I actually got live logs... see question updates for some findings
    – beppe9000
    Jul 1, 2019 at 21:57
  • @alecxs question updated
    – beppe9000
    Jul 1, 2019 at 22:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .