Fairphone 2 support for B2G-Installer, landed!

(Lissyx) #41

Recovery got built successfully, that is strange, they are very similar. At
least they are produced the same way. It means that if you flash just
boot.img out of a build tree on top of your broken blobfree flash, it
boots, right?

(Lissyx) #42

Can you clean only the .img files in that folder and retry? Maybe we have a
nasty race condition that breaks building … Also, if that still does not
work, please use the VM to perform the operations, just to be extra
cautious this is not a mac side effect :frowning:


No. Had to flash system as well otherwise it still didn’t boot.

Done. I cleaned out all img files and restarted from scratch. And now i see all 4 .img files but hold your self.
-Now flashing gives out a error… http://pastebin.com/CHMfw9JR

(Lissyx) #44

We cannot see the size of your partitions. Please use the VM, there are too many variables there to know what is really broken …


the vm is not able to flash due to a known problem that after restarting the device to fastboot mode it doesn’t recognize it because it gets a new name… so i have to test the flashing on my osx but as you can see it causes the same build problem in the vm…
size on osx:
boot.img - 15MB
data.img - 209.5MB
recovery.img - 13.5MB
system - 255.4MB

and the same behavour in the VM if i remove the 3 .img files and restart the process it generates 4 .img files correctly…

so i proved that it behaves exactly the same on both linux VM and native OSX.

(Lissyx) #46

I am not sure what you are talking about. Is this the USB IDs ? The VM is supposed to be configured properly for them, as following:

If your fastboot IDs are not the same, then you should change them.

For the size, can you get the byte-exact ones? Here there is rounding applied and I cannot trust that :confused


on osx:
boot.img - 15’249’408 Byte
data.img - 209’481’852 Byte
recovery.img - 13’846’528 Byte
system.img - 255’448’740 Byte
on vm in tmp/:
boot.img - 15’249’408 bytes
data.img - 209’481’852 bytes
recovery.img - 13’846’528 bytes
system.img - 255’448’740 bytes
on vm in B2G/out (blobfull):
boot.img - 15’351’808 bytes
userdata.img - 209’481’852 bytes
recovery.img - 13’948’928 bytes
system.img - 320’272’024 bytes

(Lissyx) #48

Ok, verify by flashing the images produced by the VM :slight_smile:



  1. i flashed the tmp/b2g-installer .img files
  2. rebooted - nothing happened
  3. i flashed boot.img from B2G/out…FP2/boot.img
  4. rebooted - nothing happened
  5. i flashed system.img from B2G/out…FP2/system.img
  6. rebooted - nothing happened
  7. i flashed - system & boot .img from tmp/b2g-installer
  8. rebooted - nothing happened as previous state in step 2.
  9. i flashed - system.img from B2G/out…FP2/system.img
  10. rebooted - boot successful

don’t know why the first time this didn’t work because im sure i have done the exactly same…
But now it looks like the boot.img partitions of b2g-installer causes the problem alone…

the size of boot.img from B2G/out…FP2/boot.img is 15’351’808 bytes so slightly bigger…

(Lissyx) #50

Ok, so ONLY boot.img is the culprit here? Right. When you are referring to tmp/b2g-installer, is that from your OSX run or from within the VM?


the vm.
im able to flash manual and with ./flash.sh in vm but the b2g-installer has a problem that may be caused by my special parallels vm host. I will have to test if other vm software works…

(Lissyx) #52

Ok, please collect:

  • Content of Object in the log for this line: B2G Installer: Calling mkbootimg with Object { kernel: "/Users/FirefoxNightly/Library/Cache…", ramdisk: "/Users/FirefoxNightly/Library/Cache…", output: "/Users/FirefoxNightly/Library/Cache…", dt: "/Users/FirefoxNightly/Library/Cache…", cmdline: "console=ttyHSL0,115200,n8 androidbo…", pagesize: "2048", base: "0x00000000" } bootstrap.js:104, the paths are stripped and we might miss some infos ;
  • Content of the build log for: rm out/target/product/FP2/boot.img && ./build.sh out/target/product/FP2/boot.img 2>&1|tee boot.img.log

This should expose us the arguments to mkbootimg we need to check that we have all the exact same ones. The difference could be the dt.img. I fear you will have to hack very low level to verify what happens here …

(Lissyx) #53

No please stop adding more variables to the problem, it is already complex enough to debug this :(. Stick to the VM with VirtualBox, this is what was working for sure for everyone.

(Lissyx) #54

Crap! that’s is very very different than what you have on the other: system.img - 320'272'024 bytes. I am starting to wonder if the difference in size would not come from missing blobs!

@atilag I remember you killed some blobs in your PR to fix the path, are you sure you have not killed some important ones?

@Novski would you mind to share me the working and the non working boot.img ? I will compare their content :slight_smile:


whait. If we roll up this with Juan i wold like to ask for a pause.
The thing is that FP has updated their repo and made a new git where we are able to get the blobs more easy and eventualy also the updates more comformitable…
its this one: https://github.com/FairphoneMirrors
Maybe (and i wold like to hear what you guys think of that idea) its better to change now…