tl;dr the shallow_flash.sh file used to flash Firefox OS nightly builds t to phones such as the Flame now works on Cygwin on Windows. The reason for previous failure and the solution highlight a difference between Linux and Windows.
Mozilla’s Firefox OS is undergoing rapid development, with the cutting edge nightly builds now at version 2.2 (as compared to the less frequent Vendor supplied builds). Each Firefox OS phone has slightly different mechanism for flashing using these Mozilla builds but the general approach is similar. Basically a base version of all the full software stack (Gonk, Gecko and Gaia) is available for flashing and then partial builds update just Gecko and Gaia). There are also OTA updates that can be just Gecko & Gaia not requiring a reboot, or a full update (FOTA) requiring a reboot.
Firefox OS developers almost exclusively use Linux, or OS X. This is for good reasons,. In particular building on Windows can be slow as it is not so hot at processing lots of small files as required for a build. Something I soon found when building Desktop Firefox on my Windows laptop.
However, when it comes to flashing, we find that people who are not building the software also want to use the pre-built images on their phones and these community members are often using Windows. They often do not wish to build and may not be particularly technical. Also the Mozilla builds have been created with a full set of features that can be lacking from personal builds (at least they are from mine).
Unfortunately the official ‘shallow_flash.sh’ script used for the partial flashes has been developed for linux. Although it should work on the Cygwin linux ’emulator’ for Windows, flashed phones would never reboot. This has now been fixed.
The core problem with the script highlights another reason Linux is better than Windows for Firefox OS development. In short, Firefox OS uses the Linux kernel and HAL layer from Android. Thus the close match between target and host operating systems when using Linux reduces many problems. In particular, some of the files contained in the Gecko updates require the X (executable) file attribute in order for Firefox OS to work at all. Windows doesn’t have this attribute and so when the files are unarchived and pushed to the phone the x attribute is lost resulting in a dead phone. In fact Cygwin tries to emulate the x attribute, but it really only pretends it is on for files it thinks are executable, something completely useless for the Firefox OS files in question.
The good news is Cygwin provides all the wonderful *nix commands which have been used for years to perform administrative magic with seemingly little effort. The philosophy of using small focussed tools in combinations in order to get the job done comes to the rescue here. A single line can be added to the script to reset all those x attributes that got lost, Here it is
1 |
run_adb shell chmod 777 $(tar -tvf $GECKO_TAR_FILE | awk '$1 ~ /^[^d].*x$/ {print "/system/" $NF}') |
Without going into details this extracts from the .tar.gz archive the list of files with x set (and that are not also directories) and passes it to chmod to set the x attribute on the files on the phone. Simples.
While I was at it I also fixed a bug with the way local files were handled. A hack copying files to a temporary folder worked around the problem and could be removed with a simple fix. Also, when testing we found problems if the files were place in a folder with spaces in the name so that was fixed too.
Until the patch is merged in you can find the fixed version of shallow_flash.sh in this pull request .
In addition as the person this work was for is not especially technical, I created a single zip file containing the script, the Firefox OS update files and a minimal version of Cygwin. This gives an easy download, unzip and run flash.bat UX. Since the Cygwin installer is complex and hardly accessible this might be useful to other folks too.
As a foot note having submitted this pull request I found someone else had recently submitted a similar pull request (though only setting the x attribute on a few predefined files). I do wish I had seen this one earlier as it took some time to figure it was the x attribute causing the problem. Heh. Such is open source 🙂