Great, I keep my fingers crossed. I would have suggested just using another distro version, but changing the gcc is the last thing that came to mind after seeing your segfault.
Hello there,
thanks for the reply! To be honest, I’m not so sure about the “just” in “just try it”.
While I know my way around Linux, this is my first Android phone, so I have no clue about the stuff going on here.
The only thing I found on the forums is this thread:
It leads me to believe that I need a recovery thingy to be able to unpack the zip I get from the openGAPPS website. But I don’t understand whether all the steps described there are necessary and/or if I can just use the recovery image provided in the thread. It doesn’t include the blobs, and I don’t know if that restricts the functionality of the FP.
I guess I should ask these questions in the thread, but if you have some advice I would love to hear it.
Well, Ubuntu 14.04 is the recommended OS I believe. And actually it is already my third distribution version I’m trying. First attempt failed on Ubuntu desktop 15.10, the vm running ubuntu desktop 14.04 failed as well, and the freshly installed ubuntu server 14.04 failed yesterday as well. Let’s see if it works this time. Tomorrow morning I’ll be able to tell more.
Build it from the source with the blobs, best also build & install TWRP as a recovery and install openGAPPS. But I’m not using openGAPPS so I can help here right now 
But I can tell you that the self-build images work. But maybe it’s best to wait until the FP project offers an easier way to get the “open” images for your phone (they still use the blobs, by the way).
Hi there,
thanks for the effort. I’ve read the main post and some comments. Strangely, it doesn’t seem so hard for a newbie. According to your experience, what are the statistics of success on this operation? What are the chances to get it right (and not brick it) with low/no dev knowledge (therefore, just following the steps, without any “backup plan”)?
Thanks in advance,
oekoniko
Hi @oekoniko. What’s your operating system? Are you familiar with the terminal?
Well, is it strange? You don’t have to write program code yourself, this has already been done. In the end, you “just” have to compile it. 
Therefore, it’s enough to be (or become) a little familiar with terminal commands.
For statistics you need a significant amount of people and solid data. Neither is present in this case. Also, this really depends a lot on previous knowledge of all the people who should be included in the statistics. Hence, I would never dare to state any probability or chances.
I’d only say the following: If you follow the steps carefully and without mistakes, all should work well as it did for most of the people here (there are exceptions as @sjjh who seems to have a lot of bad luck). If you have questions about some steps, feel free to ask!
Even if flashing will not work and you will have softbricked your phone, you could try recompiling (maybe you made a mistake or had a wrong software version of gcc for example) or flash the stock ROM. I wouldn’t say that it’s impossible to completely brick your phone (e.g., I don’t know what happens if you accidentally cut USB connection during the flashing process), but at least it’s quite hard:
1 Like
Talking about bad luck, the latest build try failed again for me. 
Neither in the console output nor in the build log, I can find any helpful error message.
I always run the build via make -j1 2>1 | tee ~/build.log to have the output both visible and in the file. But I’m wondering if I somehow omit the error message… And I still have no clue how to debug the issue.
Anybody an idea? :-/
Seems you’re piping the error output into the nirvana.
Try the following (mind the ampersand [&]):
make -j1 2>&1 | tee ~/build.log
1 Like
@tphysm: Thanks for the reply and pieces of information!
I’ve already done a few things on console, and as long as i just need to follow steps, it went ok. I’m just afraid of the mistake with no return point… But i guess, I’ll give it a shot and hope i do everything right!
I’ll let you know,
Thanks again,
oekoniko
It worked! now i can use cerberus completely! Thanks to everyone involved in these clear explanations! I also slightly changed the main article to add a small advice for newbies 
1 Like
So, I tried building again and failed again. The build log shows a segmentation fault (as previous attempts showed as well). The set-up is the same as in the last try/tries.
Anybody an idea how to debug?
It may still be a hardware problem. Since memtest doesn’t really tax the whole system, it might complete successfully even when there’s an issue that comes up when the system is heavily loaded. Sorry I can’t help you more.
Might be. But shouldn’t I then expect (other) problems (in other situations) as well? Cannot remember that I had freezes, unexpected shut downs or the like.
The physical hardware is as Lenovo Thinkpad Yoga 12 less than a year old.
The log is complete this time, good. The gcc died. Normally this should not happen, so it’s a gcc bug. What gcc version were you using this time? Have you started with a clean “out” dir?
Have you ever tried building on the “bare metal” hardware without any emulation? I would suggest building on the pure os without any emulation and with gcc 4.8.5. And check your logs for hardware issues.
gcc 4.8.5 (but I also tried 4.8.4, which is the default of ubuntu 14.04)
I started with a make clean, before continuing with building the envsetup.
Well yes, but only under ubuntu 15.10 and gcc 5.2.1 (which was “expected” to fail.)
I don’t want to reinstall the whole system, but I can try to downgrade gcc…
Well, the build is a really heavy process, so you might not encounter any issues with normal use. Of course it could be an issue with the virtualization layer or whatever too. You could e.g. try running the VM with VirtualBox to see if it makes any difference. At least I’ve successfully built the FPOSOS with Ubuntu running under VirtualBox with a Mac OS X host.
It could also still be a symptom of running out of memory if you only have 6 GB of RAM regardless of swap. I don’t know how gcc uses the memory, but I can imagine memory being locked so it doesn’t get swapped out in some situations.
You can make “make clean” to rm "out/" completely. But don’t forget to also unpack the bin-blobs again. I’m sorry but nothing more comes to mind. Maybe trying other hardware or asking for the images? Maybe people will send you links to their working images if you can’t currently build your own.
I did successfully compile on kvm with a VM with 4G and 4G swap. The crash after 4 hours leads me to also suspect hardware. The laptop gets (very) warm?
First of all, thank you guys for all of the work that already went into this thread. It helped a lot to avoid some pitfalls.
I tried to build yesterday with limited success (i’ll list the steps I took below). I ended up with a successful build and was able to flash it to the FP. If I turn on the phone now, one of two things happen, and I’m not exactly sure what the conditions are under which each of them happens:
- Boot to the black/white Fairphone logo (fastboot)
- Boot to the black/white Fairphone logo (fastboot), then the blue logo shows (“start a movement”), then it goes into a grey screen with “LOADING…” flashing in white and the green LED goes on and off once in a while.
I left the phone in mode 2. over night but nothing changed.
Does anyone have an idea what to try next?
Details
For reference, here are the steps I took, and problems I ran into along the way:
My host system is a 64 bit Ubuntu 15.04, where I installed all recommended packages. For zlib1g-dev I first installed the wrong version (64 bit) which made the installation of zlib1g-dev:i386 fail. I then removed zlib1g-dev and installed zlib1g-dev:i386, which worked fine. For the jdk I first installed version 8 as recommended by the general android site the was linked from the build instructions, I then noticed that the build instructions recommend to use version 7 and installed that as well. I also installed gcc-4.8 and g+±4.8 and used update-alternatives to make them the default compiler (I also used this to select jdk version 7 of java and javac). I verified that gcc --version, g++ --version, java -version, javac -version all show the expected values (gcc/g++: 4.8.5, java/javac: 1.7.0_95). I also added export USE_CCACHE=1 to my zshrc, but that should not matter because I later switched to bash and ccache should only really help if you do make clean a lot. I also added the rules for USB access as described here: https://source.android.com/source/initializing.html
After registering an account with gerrit, adding my ssh key, I got error messages because the host was not known. The page where you add your ssh key (user preferences?) also shows a line that should be added to ~/.ssh/known_hosts. After adding this, there was a different error (can’t remember), so I retried over https, which worked fine.
Syncing the repository showed a 404 error after every subrepo but @kuleszdl mentioned those are normal. I then downloaded the blobs (version 2.0.1) extracted them and ran the shell script. This gave a warning because it only supports bash and I was using zsh so far. After switching to bash, it worked.
. build/envsetup.sh and choosecombo 1 FP2 2 worked with anything unusual, so I ran make -j4 2>&1 | tee build.log (I don’t have enough cores for -j8). The compile got stuck with the same message that @sjjh reported earlier: You have tried to change the API from what has been previously approved.. I ran make update-api followed by another call to make -j4 2>&1 | tee build.log and the compile was successful. I had a look at the build logs but did’nt read all of it (90k+ lines). I noticed a lot of warnings about uninitialized fields, implicitly defined functions and so on. Some of them sounded like code smells (uninitialized values, etc.), others sounded like legit bugs (checking that and unsigned int is >= 0 is always true, so the test probably does not have the intended effect). I don’t think they are problematic here, though, because you would probably get the same warnings in every android build.
As a next step I tried flashing the images. My user shell did not have the access rights to the Fairphone despite the USB rules, so I started a root shell (bash), repeated . build/envsetup.sh and choosecombo 1 FP2 2 and used fastboot from there. I flashed the following images in this order:
fastboot flash recovery recovery.img
fastboot flash system system.img
Then rebooted and got to the “LOADING…” screen I described above.
This morning, I tried fastboot flashall with the same result. I then booted to recovery, wiped the cache and used fastboot flashall again. Same result: I got to the “LOADING…” screen but not further.
If you read this far (thank you), I have two more questions:
Is it ok to flash the images as the root user?
Is there some way to see what’s going on during the loading screen?