LG Nexus 5X - Random Reboot

[ghost]

This is my first bug-report, so don't hesitate to say if anything is missing.

As of now, the device will reboot randomly, often within an interval of 30 to 60 minutes after boot. This happens with both wifi enabled and disabled. No sim card has been inserted yet.

It seems a similar bug has been reported, and since it has happened again, I am opening a new issue.

General:

• LG Nexus 5X H791 - 32GB.
• Android Version 7.1.1, Build Number N4F26T.2017.03.30.01.11.28
• Device bought in Europe.
• Installed the N4F26T.2017.03.30.01.11.28 version of Copperhead OS, as described in the "Install" documentation.
• The OEM has not been locked after installation.
• The first couple of times I tried to install Copperhead OS, it failed with "Encryption Unsuccessful". Repeated the installation process until it installed correctly.

Steps to reproduce:

1. Turn on phone
2. Enter FDE passphrase
3. Lock screen after boot
4. After given amount of time it reboots to the FDE screen

ADB Logcat Dump
logcat_out.txt

[thestinger]

You're missing whatever caused the crash so I can't act on this. It was likely a kernel panic. You could try adb shell cat /sys/fs/pstore/console-ramoops on a boot following it occurring.

[thestinger]

You're missing whatever caused the crash so I can't act on this. It was likely a kernel panic. You could try adb shell cat /sys/fs/pstore/console-ramoops on a boot following it occurring.

[ghost]

I tried some other options I read about too. These were the results I got:
# adb shell cat /sys/fs/pstore/console-ramoops
/system/bin/sh: cat: /sys/fs/pstore/console-ramoops: No such file or directory

# adb shell cat /proc/last_kmsg
/system/bin/sh: cat: /proc/last_kmsg: No such file or directory

# adb shell cat /data/dontpanic
/system/bin/sh: cat: /data/dontpanic: No such file or directory

Any other ideas?

[ghost]

I tried some other options I read about too. These were the results I got:
# adb shell cat /sys/fs/pstore/console-ramoops
/system/bin/sh: cat: /sys/fs/pstore/console-ramoops: No such file or directory

# adb shell cat /proc/last_kmsg
/system/bin/sh: cat: /proc/last_kmsg: No such file or directory

# adb shell cat /data/dontpanic
/system/bin/sh: cat: /data/dontpanic: No such file or directory

Any other ideas?

[thestinger]

It might have to be enabled somehow. I'm not familiar with it since I have a headphone serial debug cable so I don't need to use that interface to debug issues like this.

[thestinger]

It might have to be enabled somehow. I'm not familiar with it since I have a headphone serial debug cable so I don't need to use that interface to debug issues like this.

[ghost]

I'll keep on trying some different stuff then. Thanks.

Update
After updating to N2G47J.2017.04.04.01.07.02, the bug's still present.

[ghost]

I'll keep on trying some different stuff then. Thanks.

Update
After updating to N2G47J.2017.04.04.01.07.02, the bug's still present.

[thestinger]

Can you see if it happens without enabling WiFi?

[thestinger]

Can you see if it happens without enabling WiFi?

[ScottyBauer]

can you try adb pull /sys/fs/pstore/dmesg-ramoops-0 .

[ScottyBauer]

can you try adb pull /sys/fs/pstore/dmesg-ramoops-0 .

[thestinger]

If you're unable to access the /sys/fs/pstore/ then it seems this isn't actually a kernel panic. It's likely not actually rebooting but rather just going back to the boot logo. If you aren't seeing the Google logo and the verified boot notification screen again, it's not actually a reboot.

[thestinger]

If you're unable to access the /sys/fs/pstore/ then it seems this isn't actually a kernel panic. It's likely not actually rebooting but rather just going back to the boot logo. If you aren't seeing the Google logo and the verified boot notification screen again, it's not actually a reboot.

[thestinger]

Can you do a fresh boot, and then get more complete logcat output leading up to this happening?

[thestinger]

Can you do a fresh boot, and then get more complete logcat output leading up to this happening?

[thestinger]

You can email it to daniel.micay@copperhead.co if you're worried about something confidential leaking into it.

[thestinger]

You can email it to daniel.micay@copperhead.co if you're worried about something confidential leaking into it.

[bluuub]

I just wanted to give you an update since the other issue is closed and referenced in this issue:
This issue seems to be unrelated to #611. I don't have any further reboots since the update mentioned in issue #611 nor after the update to Android 7.1.2 yesterday.

[bluuub]

I just wanted to give you an update since the other issue is closed and referenced in this issue:
This issue seems to be unrelated to #611. I don't have any further reboots since the update mentioned in issue #611 nor after the update to Android 7.1.2 yesterday.

[thestinger]

Yeah, that's why I closed and locked it - I fixed something, so the information there will just be confusing since some is about a fixed issue. The issue there seemed to be an actual reboot (i.e. not just going back to logo but actually rebooting and going through Google logo and verified boot screen again).

[thestinger]

Yeah, that's why I closed and locked it - I fixed something, so the information there will just be confusing since some is about a fixed issue. The issue there seemed to be an actual reboot (i.e. not just going back to logo but actually rebooting and going through Google logo and verified boot screen again).

[thestinger]

I don't really have anything to go by here beyond what appears to be either a use-after-free or use of uninitialized memory in the boot animation code. I've switched to using zero-based junk filling for production builds to keep the same exploit mitigation while tending to paper over bugs instead of making them crash, which will be in the next release. That's the only thing I have to by here and I'm considering it the bug for this issue. If someone still has problems after the next release, file a new issue with logs.

[thestinger]

I don't really have anything to go by here beyond what appears to be either a use-after-free or use of uninitialized memory in the boot animation code. I've switched to using zero-based junk filling for production builds to keep the same exploit mitigation while tending to paper over bugs instead of making them crash, which will be in the next release. That's the only thing I have to by here and I'm considering it the bug for this issue. If someone still has problems after the next release, file a new issue with logs.