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.

Background: I administer a small remote office with about 10 computers which need to be backed up regularly. To do this without disrupting the users’ work, I have the backup server wake up all the machines during the night using WakeOnLAN and, once it is done backing up all the data, shut them down via Windows RPC. Since WoL support has become fairly ubiquituous in recent years this works very well for most of their machines. One of them, a brand new Hewlett-Packard Z210 CMT workstation that we recently acquired, just wouldn’t have it though.

The problem: In fact I already noticed the problem when I first installed the box, as my standard WoL test failed with the PC not finding its boot drive/Operating System. When that happened, I just hit the reset button and then Windows came right up, so I stupidly dismissed the failed boot attempt as a fluke and quickly forgot about it. Over the course of the next weeks however, it quickly became apparent from the backup reports that this box was never getting backed up and every time I attempted to wake it up remotely failed. When probing the local staff about the machine, they mentioned that they often found it powered up in the morning with the message ‘No disk or operating system’.

Thinking back to my failed boot attempt during the box’s installation, I figured that it had trouble starting up when cold due to the disks not spinning up quickly enough or a similar issue. I have previously encountered machines suffering from this, so it was the first logical conclusion to jump to. I walked somebody in the office though how to increase the BIOS’ wait time when starting, change the POST test type from ‘quick’ to ‘full’ and several other options, to no avail. The machine still would not come up for its nightly backups. As I was preparing to send the machine off for repair, I had one of the local staff mention that the machine would start normally for the, even when cold. A quick test confirmed this, and therefore trounced my initial conclusion. Something else was wrong with this machine.

The cause: With the PC starting up normally when using the power button but never coming up for the backups, we started digging around the possibility that something was going wrong only when started via WakeOnLAN. Since I was still remote, I called up one of the people on site and had him shut down the box and watch the screen as I issued a WoL remotely and sure enough, the boot up failed. The local guy mentioned that the machine was trying to do something with the network and a quick check in the DHCP logs indeed showed it grabbing an IP, so apparently it was trying to do a PXE boot instead of booting locally. We went though the BIOS options and sure enough, one specifies the boot source when woken up via WoL. You can set it to ‘network’ or ‘local disk’ but unfortunately, it was already set to ‘local disk’. Why then was it trying to boot of the LAN? Elsewhere in the BIOS, we found an option to disable the PXE/LAN booting altogether, so we did and ran another test. Still no lock. The machine was now going straight to the ‘No disk …’ message. Soemthing was very wrong with the way the BIOS behaved here and since I had already upgraded it to the latest available release, it looked like I would never get this machine to wake up properly.

First workaround attempt: With the PC not coming up regardless of its BIOS settings, I figured I might try to work around the problem by simply letting it boot off the only source that it was trying to, the network, and then having the bootloader it got there redirect it to the local disk (chainload the MBR). I had recently set up all the PXE server stuff needed for network booting at home, so it didn’t take me long to implement that on their local server. The bootloader I used, PXELINUX, which is part of the SYSLINUX project, offers two ways to do this. One is the ‘LOCALBOOT’ command, which according to some Internet comments doesn’t always work, and the other is the ‘chain.c32′ module. I opted for the last one, created this configuration file and woke up the machine…

DEFAULT menu.c32
PROMPT 0
TIMEOUT 5
LABEL bootlocal
MENU LABEL Boot from first hard drive
COM32 chain.c32
APPEND hd0 0

It didn’t come up. I called up the office again to have somebody tell me what was on the screen and it was basically the same problem again. So I figured the ‘chain.c32′ method wasn’t working and gave the localboot one a try:

DEFAULT menu.c32
PROMPT 0
TIMEOUT 5
LABEL bootlocal
MENU LABEL Boot from first hard drive
LOCALBOOT 0

Still no luck, same error. I appears that the BIOS flat out does not recognize the disks when woken up via WoL. It does show them during the detection phase but during boot, nothing is able to get them. This is also why the normal boots, which should continue to disk once PXE failed, does not work.

The actual workaround: Since there was no way to get the system to boot from disk when woken up, I figured that I could possibly get it to work if I could only get it to reboot once and thus reset its BIOS to the normal, working state. So I downloaded the Debian netinstaller network boot parts and started hacking. First I unpacked its initrd.gz file (gunzip it, then extract with cpio) and then started looking around to find its startup script. The /etc/inittab file has this section in it:

# main rc script
::sysinit:/sbin/reopen-console /sbin/debian-installer-startup

# main setup program
::respawn:/sbin/reopen-console /sbin/debian-installer

Sure enough /sbin/reopen-console was the script that I was looking for. I left most of it intact but modified the first few lines to look like this:

#!/bin/sh

/sbin/reboot

With that done, I repackaged all of this back into an initrd.gz file and replaced the original one with my hacked version. To avoid having to disturb the local users again, I also decided to test this image first, so I quickly installed a VirtualBox VM on their server, set it up for PXE boot and fired it up for a test. Since the VM seemed to work exactly as I had planned, I reconfigured the PXE config files for the failing machine to use the same image and then woke it up via WoL. By this time, nobody was in the office anyway so I figured that the machine will either start or have to sit there powered on all night until people came in in the morning. Fortunately for me, the latter did not happen. About a minute after the WoL packet was sent, I had the machine pinging and could log in to shut it down properly.

Conclusion: Open Source software: 1 – broken HP BIOS: 0

Open Source software rocks! There is no way I could ever have gotten this to work using any other Operating System or platform. The fact that I could just download a PXE bootloader and PXE-bootable Debian distribution which I could then modify to just reboot as soon as started, is what saved me from having to wait for HP to fix this bug in their BIOS, which I’m still hoping they will eventually do. (Yes, I have e-mailed them about it, no response so far.)

With the PXE server set up anyway, I’m now planning on putting a properly bootable Linux image on it for the times where I am on site and need to debug a non-booting Windows again.  That will save me from trying to hunt down the local Knoppix disc or downloading/burning a new one every time.

First things first: I’ve only tested this on Froyo 2.2 and you will need a rooted phone to pull this off. The usual disclaimers apply. (I’m not buying you a new phone if you break yours, you may get sued into oblivion by Samsung, cause the destruction of the entire universe … or worse. You’ve been warned.)

1. Signing up for an account.

This needs to be done from ‘Location and Security’ menu on the device, but typically will be met with an error message like ‘SSO_2010′. To fix that, root your device, download the MarketEnabler application (just google it) and use it to fake another provider (like ‘T-Mobile US’). Signup should work fine with that.

2. Triggering a location update request.

With the account you created in step 1, you can log into samsungdive.com. Sadly, when trying to use the ‘locate’ feature, you may get another error message stating that this is not allowed in your country ‘for legal reasons’. (I can’t fathom a legal reason that would prevent me from requesting the location of my own phone, but that is what it says.)

To fix this, log into the Samsung Dive site and go to the Mobile tracker. Once there, access the following URL while replacing ‘YOURPASSWORD’ with your account password to trigger a location update request:

http://www.samsungdive.com/locationN/forwardLocationRequest.do?password=YOURPASSWORD

That page will return gibberish which your browser probably won’t like. Just ignore it and go back to the Mobile tracker page, where your request will be pending or have completed in the meantime.

3. Issuing a remote lock command.

If you want to issue a remote lock for your device, use this URL:

http://www.samsungdive.com/lockN/forwardRemoteLockResult.do?password=YOURPASSWORD&currentReqId=REQUESTID

YOURPASSWORD = your account password
REQUESTID, PHYSADDRESS and USERID can be extracted from the source code of the mobile tracker page. You will see something like this in there:

//remote lock
var lockCurrentUserId = “USERID”;
var lockCurrentRequestId =”REQUESTID”;
var lockCurrentRequestStat = “2800″;
var lockCurrentRequestStatMsg = “Operation Success”;
var lockCurrentDevicePhysicalAddress = “IMEI:XXXXXXXXXXXXXXX”;

It is likely that USERID and PHYSADDRESS are static, REQUESTID changes over time (either on login or even for every request).

4. Issuing a remote wipe command.

To issue a remote wipe, use this URL while substituting YOURPASSWORD with your account password:

http://www.samsungdive.com/wipeN/forwardRemoteWipeResult.do?password=YOURPASSWORD

Note that I have not checked this functionality because I did not really want to wipe my device. If you tried it, please let me know in the comments if this works or not.

In conclusion, there is really no reason why these services are not enabled or allowed for people in countries other than the US. I know numerous other products that offer similar functionality without any issue. That said, Samsung can probably close the loopholes listed above very easily but until they do, enjoy the full functionality of your phone.

Update: While writing this, I noticed that the Remote Lock and Remote Wipe features are now also blocked. These used to work regardless of country, with only the Locator feature being blocked but apparently Samsung decided to further restrict functionality to their users. I have added the URLs to use for the lock and wipe commands as well. YMMV.
Update 2010-12-19: Apparently the Remote Lock URL changed again so I’ve updated this post.

P.S. Huge thanks to computeruniverse who kindly replaced the defective motherboard for free (incl. shipping and everything). They’re definitely worth their money!