How to debug boot loop?

Question

I have a boot looping Samsung Galaxy S4 Mini LTE (also known as GT-i9195 or serranoltexx â€“ this is not GT-i9195i or serranoveltexx).

Current behavior: when the phone is off, pressing power button results to normal boot screen with usual yellow text in the top left corner about custom kernel ("Set Warranty Bit : kernel"). The screen stays in this view for around 20 seconds, turns to black, vibration motor runs for two short periods and the system reboots. I guess the system is failing to boot until hardware watchdog resets the system due timeout exeeding. If I boot with Volume down + Home + Power held, the phone enters into download mode as usual. And if I boot with Volume up + Home + Power held, the phone enters recovery mode (TWRP version 3.3.1.0) where everything seems to work as usual, too. I was running LineageOS 16 (Android 9.0) with SELinux enforcement enabled with June 2019 security patches. The system has XXUCOL3 modem firmware if I remember correctly.

In the end, I can successfully boot into download mode and into TWRP recovery. However, the system started to fail to boot to normal system after normal shutdown-restart cycle and the system was working okay before shutdown. Is there any way to diagnose and possibly fix the problem without wiping all the data?

Steps that I've already tried:

Wiping Art/Dalwik Cache, Cache partition and System partition and re-installing full system image via TWRP.

Removing battery

Booting with SIM card and sdcard removed

I really want to understand why this happened to avoid it in the future. I really don't want to have a device that randomly enters this state and the only way to fix it is to wipe the whole device. Being able to bring the current system to usable state without full wipe would be a nice bonus because it avoids reconfiguring all the settings and apps again.

_{And yes, I know this device is old and I had to previously replace motherboard due emmc chip failing but I really like the form factor and no vendor is nowadays providing similar device. If Sharp Aquos R2 compact didn't have notches on the screen it would be my next phone.}

— Mikko Rantalainen | Sources

Answer

In practice, the only way to debug early boot loops is to read the kernel log as follows:

Minimum steps to get log if you have a working adb and TWRP:

When the device is boot looping, press and hold VOLUME UP + HOME until the boot loop repeats and you get blue "RECOVERY" text in top left corner (specific key sequence will differ depending on actual harware but above should correct for Samsung devices). The important part is that you have to enter the TWRP recovery directly after failed boot and exact steps to do this depend on the hardware. The above example should be correct for all Samsung devices with hardware home button.

Attach the phone to computer with an USB cable and wait for TWRP to finish booting (the order to attach the phone and TWRP booting is not important).

Extract the kernel log from failed boot. Run following on the host computer command line:

The required command for linux host:

adb shell cat /proc/last_kmsg > ~/Desktop/boot-loop-kernel-log.txt

The required command for Windows host:

adb shell cat /proc/last_kmsg > %UserProfile%/Desktop/boot-loop-kernel-log.txt

You'll end up with a file called boot-loop-kernel-log.txt on your desktop which contains the kernel log of failed boot.

This works because /proc/last_kmsg contains the memory contents of previous boot kernel log ring (this works because kernel keeps this log in known memory address and next boot saves the contents of that memory area before writing the new log in the same location). Some vendors put the previous boot kernel log ring to file /sys/fs/pstore/console-ramoops or cat /sys/fs/pstore/console-ramoops-0 so you may need to do

adb shell cat '/sys/fs/pstore/console-ramoops*' > ~/Desktop/boot-loop-kernel-log.txt

instead, but the idea is still the same. Obviously, if the hardware overwrites all memory with zeros on boot, this cannot work.

In my specific boot looping case the problem was caused by "Live Display" color correction failing during boot process if its settings had been changed from the default. With that specific problem, the workaround was to boot to recovery and execute following as root

rm /data/vendor/display/.displaymodedefault

Long version of instructions to acquire boot log during a boot loop: https://forum.xda-developers.com/showthread.php?t=1520508

— Mikko Rantalainen | Sources

Topics