Migrating to CyanogenMod – the dragons that I summoned

Disclaimer: Below you will find a “quick” recount of my personal experience in migrating my Samsung Galaxy S GT-i9000 Android phone from the Samsung stock ROM (2.3.5 / XXJVS) to CyanogenMod 7.1.0. Following any of the procedures listed here may wipe your data, kill your apps, destroy phone, eat your dog or cause the end of Life, the Universe and Everything, so consider yourself warned.

It all started harmlessly enough: My phone was already rooted and equipped with the ClockworkMod recovery so I downloaded CM7 off the CyanogenMod website

, made sure I had a backup of all my apps and data on my PC (Titanium Backup is very handy for this), enabled the USB-Debug mode for apps and ensured I could get into Download and Recovery mode using the 3 finger salute. (The last one is actually very important. If you cannot get into Recovery or Download mode, you run the risk of bricking your phone.)

Next, I did as instructed, rebooted into recovery, did a wipe data/factory reset from there and used the ‘update from zip’ function to flash the new ROM. The next reboot went from showing the stock Samsung logo to the modified CM7 boot screen, then spat out some text and promptly caused the phone to reboot… Whoever they said ‘here be dragons’ in the upgrade instructions wasn’t kidding.

Fixing the boot loop

Since the text big only flickered past my eyes for a fraction of a second, I resorted to filming it with my other phone, a lowly BlackBerry Torch 9800. The result was a rather blurry sequence of frames which revealed a just barely readable ‘file not found’ error message, referencing ‘update-cm-7.1.0-GalaxyS-signed.zip’, the name of the update ZIP-file that I’d uploaded onto the internal SD partition. Turns out, the fix for that was rather simple:

Rename the ‘update-cm-7.1.0-GalaxyS-signed.zip’ file to ‘updatecm.zip’

Whether it’s the dashes, the period signs or just the length of the filename that bothers the script, I did not care to find out. The rename and subsequent Wipe/Flash process fixed the problem. (I also renamed gapps.zip, just to be sure.)

So I let the whole thing boot up, gave it my Google Account credentials, downloaded Titanium Backup and told that to restore all my apps and data. All good right? Of course not! Dragon number two was rearing its head.

Fixing the Titanium Backup restore process

The first problem was, that Titanium Backup would get stuck restoring half way. Part of it was due to it trying to restore apps that could no longer work (like Samsung-provided system stuff) and another part was the /datadata partition that CM7 is fitted with.

The system apps, nothing could be done about so I simply started excluding them from the restore. When that still didn’t help, dug around the phone and eventually noticed that /datadata had become full (At only 172M, this partition is quite small.) and simply started the long overdue process of cleaning my phone by throwing out unused apps. On a whim, I also enabled the ‘Use Internal storage’ option in the CyanogenMod options, in the hope that this actually gives my apps more space to work with. (I have no idea whether that is actually true or not.)

To sum it up:

– Don’t restore Samsung specific apps and old system apps.
– Clean out old/unused applications to keep /datadata from filling up.
– Enable ‘Use Internal storage’ option without knowing what it does. ;)

Update 2012-01-04: After a few weeks with this ROM, I have come to the conclusion that the ‘Use Internal storage’ option does in fact not help here. All it does is invert the internal and external SD cards, causing unruly apps to pollute your external SD instead of the internal one, if they use the SD. Since my /datadata was still filling up often, especially with Tweetdeck dumping 20+M of cache data there, I’ve opted to use an adb shell to move stuff out of it onto the Internal SD card and symlink to that. (

Right, what else could possibly go wrong? Well, this ‘Skyrim’ of upgrades would not be complete without a third and final dragon coming down on me with fire-y breath.

Fixing the ‘Force Close’ epidemic

That’s right. With the apps restored I was facing the next problem, the dreaded ‘Force Close’ errors causing a number of them to crash. I had already dealt with this problem once before, so I was familiar with the fix_permissions script you’re supposed to use to correct the permissions of the application data directories in the filesystem so that apps can read their data again. Unfortunately for me, this did not solve my issue. Some apps would recover while others would break, and after every reboot the problem would affect different ones. Some more digging and several Google searches later, I simply resorted to deleting the ‘packages.xml’ file to get it rebuilt. This apparently worked because after the next reboot, EVERYTHING was Force Closing… so I hooked the phone up to my PC and went in with an adb shell (you can get the necessary USB driver via the Android SDK) to run fix_permissions and issue a reboot again. Lo and behold, the dragon was slain! I have not seen a single ‘Force Close’ since then.

Recipe against ‘Force Close’ crashes (requires shell access via terminal or ‘adb shell’):

– rm /data/system/packages.xml
– reboot
– su
– fix_permissions
– reboot

Was it worth the trouble?

This question can only be answered with a resounding ‘Hell yes!’. The performance gain that I’ve achieved by installing CyanogenMod is nothing but astounding! My phone went from unusable, with unresponsiveness levels ranging from ‘stuttering when scrolling’ to ‘making the unlock screen time out because touch events are not being registered due to load’, to buttery-smooth ‘I can compete with the Galaxy S II on less than half the CPU power’ UI goodness, that makes it an absolute joy to use. I cannot commend the CyanogenMod team enough for the amazing work that must have gone into the production of this fine piece of software.

Leave a comment

Your email address will not be published. Required fields are marked *

Bear