FP2 random reboots - see #rebootsguide for help


after ten and a half days my phone rebooted. It was in the night on the charger, in the morning I found it requesting SIM pin. I got the /proc/last_kmsg, which looks quite corrupt. Like a HW issue (phones running again)

Here’s the last_kmsg: https://drive.google.com/file/d/0B-9cNi0ys0CMM2IwMVdrdzRUbVE/view?usp=sharing

This sounds a lot like my phone’s behavior since the last update. No reboots for many days and then it started again rebooting, from time to time especially when on charge.

Could you check for /proc/last_kmsg? Maybe one can find some cues from traces…

Sorry, how do I check this file? When should I check it? Just after the next reboot?

Yes, when the phone is back up again, you’ll have this entry. But i forgot to mention that you need root to access it.

I have root. I only have to find where this file is? Where do I find it with amaze?

If you navigate to “Root” you will find proc, this is where this (special) file lies. Just tried it, but opening makes amaze quite laggy (it’s usually a big file)
You can open a terminal (probably need to install one?), and type at the prompt

$ su

then you have to accept it for becoming root. Afterwards the prompt will change to


Then type the following command:

cat /proc/last_kmsg > /storage/sdcard/lastkmsg.txt

This file is best read on a computer (due to its size). You can get it with a file exlorer when you hook the phone to the computer via usb, or adb pull


I can confirm this. Things haven’t become better with latest OS 1.7.0, still a lot of random crashes/reboots, sometimes more than 20 per day.
In my case reboots occur also while GPS is switched off. Sometimes, when I take the phone after some hours, it asks for PIN input – fine, so I was not reachable during this time…
As other members suspected, maybe there is some kind of HW design problem in FP2. I need a working and reliable phone, so recently I ordered a refurbished Samsung S5 and updated it to Android 6.0.1; it runs absolutely stable with same cards as used before in FP2

1 Like

I have disabled the sim pincode and added screenlock-code instead so that when the phone reebots I’m still reachable without the need to enter the sim pincode first. I know this isn’t the safest if the device gets stolen but it makes the problem less irritating at the moment.

As you wrote, I do also think this is a HW problem as otherwise everyone would have had these issues. It seems that we are quite a small group with these exact same issues so hopefully a changed screen or motherboard/connectors will solve it

Since Fairphone repair center changed my motherboard 2 weeks ago I didn’t get any reboot. Before that I got random ones, especially when I used the GPS.
The repair center report said “factory defect”.
This does not mean that every reboot is due to a factory defect and that replacing the motherboard will solve the issue. It just confirms my doubts about google applications such as google maps being the source of the problem. I used them during a 5 days bike trip last week without any problem (appart from the Fairphone overheating, but it sometime does that even when I charge it without anything running).

I’ll jeep you updated if the reboots come back.

What do you think now about what causes the problem after a new mainboard helped your google app not to reboot the device: Can’t google help it ? Or could FP help it to overcome instability ? Reading your case and other carefully I think maybe also my FP2 has a hidden instability that I maybe still don’t know … until the next update :frowning:

I cannot tell what makes every Fairphone 2 reboot. After reading the feedback from different users on this forum it seems that not every fairphone behaves the same way.
My Fairphone’s is just one case and tells very little. I could only adventure to say what the reboots are not caused by:

  • not caused by google services. If this was the source my Fairphone would still reboot. Nor by OsmAnd as I am using it too quite heavily.
  • in my case not caused by my sim cards or my SD card. I still use the same.
  • in my case not caused by my charger. I still use the same.

Please keep in mind that defects always happen, even for high end products. Having one with a defect does not mean that others also have a defect. I have had no reboots for 2 weeks only, it could come back if the issue was not diagnosed properly by the repair center.

The only thing I could complain about is that the forum is not always helpful. Some people tend to be aggressive when users don’t want to be lenient with the Fairphone company, this is not helping them. Others tend to say that they have found the solution too early or that a workaround is acceptable when it isn’t for most people. Blaming third party applications without proof is not an acceptable behavior, even if you like the idea behind Fairphone (which I do). I would say that every person not understanding how drivers or memory work should refrain from such accusations. They just make people loose their time and ruin companies reputation. It does not mean that they cannot report bugs while using those applications, such information is useful, just avoid saying that the applications are the cause (correlation is not causality).

Example: if an application accesses very often the memory it has more chance of triggering a defect in this component. It does not mean that the application is responsible for the defect.

Same thing for chargers and cables. If they work with many other devices (one other device is not enough) the main suspect is the fairphone, not the charger. No need to buy dozens of chargers. Yet people here tend to accuse the chargers. Yes chargers are not perfect but in this case it’s like accusing the road of not being completely flat when your car’s suspensions are broken.

What is clearly missing with the fairphone are simple diagnostic tools which people can run and send reports to the support. Fairphone is meant to be repaired by users. They can order new components to replace bad ones. The problem is that they have no clue as to which part needs to be changed and need to send the whole phone back.
Simple RAM, NAND flash and other component tests would already be a big help. It would detect case where a component is not working properly and would avoid having people wait for the next update which won’t fix the problem at hand.

Sorry for ranting, this does not answer your question. What I would advise in your case is try to find diagnostic applications which stress the memory, cpu and other components (if somebody knows a good tool for that I am interested too). If the phone crashes every time you run it or the report says that there are defects, contact the support. Otherwise wait for updates hoping for a fix. If it is not fixed in one month or so, contact the support. If they don’t answer after a month, complain a little on twitter, this seems to get their attention.

In my case I just found out that using the GPS was triggering more reboots, whatever application I was using, with and without SIM and SD. This was enough to suspect either a hardware defect or a driver bug.


True and amazing description. I guess we own still the same device. My reboots are rare but I would also mention GPS that I also rarely use. Due to the not so stabe state and design of FP2 I find your opinion not so long as some might think. And yes, FP doesnot seem to have found diagnostic tools either remote or in their own laboratories to find roots of several instabilities. I guess.simple enough that the glitching contacts due to the.modular design takes a good share to.some instable device. The biggest advantage of FP2 maybe is not really mature. Only one year after prototype left clean rooms a revilutionairy modular design cannot be expected to be stable. And maybe this was the reason why google abandoned their ara project ? Who knows

Does FP-team monitor this thread? It would be very interesting to hear from FP-team the latest findings concerning the random reboot issue, even if the info is not 100% proved.
So, does FP-team think the problem is induced by bad SW or by bad/instable HW?

In case of a SW problem, I agree to former posts which say that in this case some Unix/Linux guru would have been able to upload and analyze some memory core dump or other diagnostic info, and the problem would for sure have been fixed already. However, problem is still not solved. So it seems likely that we have some kind of HW issue in FP2. Whether this concerns only rather few devices or a majority – perhaps only FP-team knows. I think it is important that FP-team communicates this issue openly.
BTW, does someone remember the former German website “wir-sind-einzelfall”? :wink:


Probably not very thoroughly, they have better ways to spend their time.

I’m not a FP employee, but I’m going to answer your questions anyway. (As far as I can):

There are currently beta tests going on which implement some kind of automatic bug report which is sent to FP after a report.

I don’t think you can talk about the problem. Random reboots can and do have very many different root causes.

I’m sure they don’t have any relevant data about how many people have this issue. Not everybody who has reboots reports them. On the other hand people who report issues to the support team or on the forum are not representative of everybody out there who has a Fairphone either.


Just my two cents. I cannnot confirm the following statement (it is just an observation), but I’m curious to know if I’m the only one to have detected the same behavior or not :

I own one of these crashing-at-least-once-a-day-or-two fairphone. Until now it was a bit annoying (mainly because fairphone open take an eternity to boot (~5minutes for my phone !!)) but I do not take the time to try anything.

It begin to change with the previous upgrade (the v.16.07). Before it, my fairphone randomly freeze and I must manually push the power button >10s to hard-reboot it. After the 16.07, it continues to crash but at least my fairphone reboot by itself. I worried less about the lifetime of the button.

But, since the 16.08 update last week… tadaaam no crash at all. Yes, your read it! So I do not know if fairphone (or android) team fix the one thing causing my phone crashing or if it’s just astral alignment or god intervention, but it seems to be fixed for me know. Anyone else experiencing the same freedom?

Disclaimer/test: in fact I cannot confirm the 16.08 upgrade solves my problem, because I only realize today I’ve pass a week without crash. It may have been resolved by something else. In the mean time, for example, I stop using muzeo app. May my previous crash be linked to this app?

In my case 16.08 have made no difference. I have a google free OS (no gapps). That saves alot of time when it reboots. For me it takes just 20-30 secs when it reboots until I can use it again so it’s not something that makes me wait. The reboots itself is still very annoying though, especially as its not connected to using a specific app but simply using the phone with the screen turned on.

One thing that would greatly help would be to read some kind of error log. I guess the ver few last entries before reboot could give a clue. Its possibly even the absolute last one before reboot which could lead the way to finally get a clue of what is making these reboots happen.

Is there any good logger that can manage to do this? To have a constant logging going on all the way until the moment the phone hangs and then keep this info until I have read it?

Such a logger is included in the 2 latest beta versions and - I believe - has brought FP a lot of information already. You can always apply for beta testing if you want to help more.

1 Like

That sounds very promising. Beeing part of the beta would be fun. I do however feel that my Android-knowledge is limited. I go bust on simple stuff as: Explain adb so that a child can understand.