20 Thoughts After Resurrecting My Galaxy Tab

I got my Samsung Galaxy Tab P1000 for free in December of 2010 through a promo of Smart.  The promo offered the free GT-P1000 if I subscribed to Smart's unlimited mobile Internet plan for around $45 monthly and a lock-in period of 24 months.

The warranty expired 12 months later and I cancelled my subscription in December 2012 after the lock-in period was over.  A few days into 2013, the internal storage of my Galaxy Tab failed, becoming read-only, reducing my Android tablet into a pricey media player.

6 months later, after a month of research and trial-and-error, I was finally able to revive my tablet. I'll be writing about how I fixed my Galaxy Tab in more technical detail at a later date, but for now, I'll just give a summary of the procedure of my solution:

1. Root the tablet
2. Enable boot or init.d scripts
3. Add a MicroSD Card
4. Create a loopback filesystem image on the MicroSD card
5. Mount the loopback filesystem image and copy /data to the loopback filesystem
6. Edit the boot scripts to unmount /data and mount the loopback filesystem as /data
7. Edit the boot scripts to mount the MicroSD card as /mnt/sdcard

The key thing with my fix is that there is no need to open the tablet and remove the internal storage chip.  There is no need to partition the MicroSD card.  I was able to increase the storage space of the /data partition and I can resize it at anytime.  The move apps to SD card functionality was retained.  The only problem with my solution is that you can't remove the MicroSD while the tablet is on.

When I bought it, the GT-P1000 was the best Android tablet you could find.  Unlimited Internet costs about $22 a month so, essentially, I paid just $540 for the unit which was a very good deal at that time.  Even then, it still cost a lot and it was difficult to accept that all that money went down the drain when my tablet was damaged.

Even if the loss of an expensive item was hard to take, I did realize my first lesson:

1. Buying the Samsung Galaxy Tab GT-P1000 in December 2010 allowed me to start my app collection cheaply.

I'm glad I got the tablet.  It was the first of many android devices I was to own.  Owning an Android device with the specs of the GT-P1000 that early, allowed me to catch the incredible app marketplace sales of Google where I was able to buy all the cheap apps because my tablet specs met all their minimum requirements.

If I didn't have an Android device when the super-cheap marketplace sales came out, I wouldn't have gotten the apps that I have now for a pittance.  Even if I had an Android device, if it didn't have Froyo or a sufficient CPU and GPU, I might not have been able to get some of the apps for so cheap.

So even if it seemed I'd lost a valuable item, I shouldn't regret spending so much to get the tablet because it gave me a chance to acquire apps for my account at an affordable price, apps which I could use on future Android devices.

Although I don't regret getting my Galaxy Tab, that fact that it did conk out so soon led me to the following conclusion:

2. Samsung Android devices are just too expensive

Samsung Android devices are priced at a premium therefore I expect them to last longer than cheaper Android devices.  Unfortunately, anecdotal evidence proves otherwise.

I've seen a lot of posts in forums of people who own a GT-P1000 with damaged internal storage looking for or discussing a fix. I've seen similar posts for other Samsung Android devices.  My brother experienced this before his warranty ran out but my misfortune wasn't as timely and this goes for a lot of people as well.

Right now, I can buy a cheap tablet for about $55 and a good performing one for about $120.  The cheapest Samsung tablet now goes for $200, almost twice as much as a cheaper, similarly performing generic Android tablet.

I would expect the cheapest Samsung tablet to last close to two years but I don't have the confidence that it will, given the fact that my more expensive $540 Samsung Galaxy Tab lasted only two years before it experienced catastrophic failure.

I'm better served by buying a cheaper tablet at half the price and have it fail within the one year warranty period.  If it lasts longer than the warranty period, then I'd feel that I got more than my money's worth and then buy another cheap one when it fails.

Because it was so expensive, I had to try to resuscitate my Galaxy Tab.  I tried finding the best solution for my issue but I could find very few answers:

3. There are only a few solutions to fix Galaxy Tab GT-P1000 tablets with damaged internal storage

The only solutions I found were to open the tablet and remove the movinand chip, extract the boot image file and edit the init.rc file then rebuild the kernel, and compile a custom ROM with edited build files.  All of these were too difficult for me to do or would just take too long for me to learn.

It was then that I realized that there were no easy and quick way to get my Galaxy Tab working again.  That's when I decided that I had to find my own solution:

4. My solution is the easiest way to fix the read-only internal storage problem of the GT-P1000.

My solution does not involve opening up the tablet nor do you need to compile your own kernel or build your own ROM, so you don't need to learn how to open a tablet, compile a kernel, or build a ROM.  All you need to know is how to root the Galaxy Tab, install an app to enable boot scripts, and copy scripts to the internal filesystem.  Basically, my solution relies on scripts to fix the problem.

Before I started looking for a solution, when I first found out that the internal storage of my tablet became read-only, I immediately regretted not rooting it earlier.  I thought that I could no longer root it because of the damaged internal storage.  Well I was wrong:

5. Samsung Galaxy Tab GT-P1000 tablets with a damaged internal storage can still be rooted

When it dawned on me that something was seriously wrong with my tablet, I thought that the device was most likely dead and useless.  I had already been planning on rooting the Galaxy Tab when the unfortunate turn of events happened.  What immediately came to mind was that I should have rooted the device earlier and now I was too late.

I later attempted to root my GT-P1000 using SuperOneClick 2.3.3 and, to my surprise and delight, I was successful.  I was fortunate that I was still on stock Gingerbread ROM 2.3.3 so that SuperOneClick would still work.

Later on, after settling on a solution for fixing my damaged Galaxy Tab, I realized that rooting, among others, wouldn't have prevented the failure of the tablet:

6. Rooting or flashing custom recovery and kernel wouldn't have prevented the failure of the internal storage of the GT-P1000 nor would they provide a direct fix.

I thought that rooting the Galaxy Tab would allow me to format, re-partition, fsck, wipe, erase, or remount as read-write, the partitions on the damaged internal storage of the tablet.  I found out otherwise.

Even using a custom recovery and kernel, CF-Root v3.3, did not end up with me being able to wipe the contents of the damaged internal storage.  I concluded that even if my GT-P1000 was already rooted and had a custom recovery before it had failed, these alone would not be enough to fix my tablet.

I needed more than just rooting my Galaxy Tab and I realized later that I didn't really need a custom ROM nor a custom recovery and kernel.  What I needed was a way to run scripts at boot:

7. You only need root and the Uni-Init tool, instead of a custom ROM or a custom recovery and kernel, to run scripts at boot

Through trial and error, scripts became my preferred proposed method for fixing my tablet, winning over removing the movinand chip, rebuilding the boot image with an edited init.rc, and compiling a ROM with edited build files.  I was able to run scripts at boot because I had already flashed a custom recovery and kernel, CF-Root v3.3.

If I knew then what I know now, I would've used the Uni-Init apk to enable init.d scripts to be able to run scripts at boot instead of flashing the custom recovery and kernel.

When using boot scripts, for safety purposes, don't save the main scripts you make to the internal filesystem because it will be difficult to access if something goes wrong:

8. Save your main boot scripts on the external SD card and copy them to the internal filesystem to run.

I entered something wrong in a boot script I had placed in the internal filesystem so the tablet would no longer boot.  I could not get access to the console so I had to flash a stock 2.3.3 Gingerbread ROM to get my tablet bootable again and gain back access to the console where I could run commands and copy my scripts.

To prevent a script from making my tablet unbootable, the initial script that is run at boot from the internal filesystem, only contained commands that I deemed safe but necessary and at the end had commands that copies the main script from the external SD card to the internal filesystem and runs it from there.

I can't stress just how important it is to make sure that your edited scripts are on the external SD card so that you can change the scripts from a PC if these scripts make your tablet unbootable.

One of the first commands I tried putting in the boot script that worked was for unmounting /data:

9. To unmount /data you need to force unmount it

To unmount /data, just using the normal command 'umount /data' will not work.  You need to use 'umount -f /data'.  I found this out by executing the command in the console.

After I entered this into a boot script and booted my tablet, I discovered a significant result:

10. Unmounting /data will allow the Galaxy Tab with damaged internal storage, to be bootable and to boot quickly

I figure the reason why the GT-P1000 won't boot or takes a long time to boot when the internal storage is damaged, is because Android keeps on trying to write to the /data subfolders but can't.  It won't boot too if Android can't read the contents of the /data folder.

By unmounting the partition on the internal storage from the /data folder, the /data folder becomes readable and writeable because the /data folder was created on the root filesystem which is a ramdisk.

Once I could get my tablet to boot quickly, I was able to experiment more.  I tried to mount different subfolders of /data to folders on the SD card.  The first thing I noticed while doing this was that not all /data subfolders could be copied to the SD card:

11. Some files in a few of the /data subfolders have filenames that are not compatible with the FAT/FAT32 filesystem.

As a result of this, not all of the /data subfolders folders could be mounted on the SD card.  They had to remain on a Linux compatible filesystem.

Some of the folders could be copied fully to the SD card but did not work as they should because they lacked the proper ownership and permissions present on a Linux compatible filesystem:

12. Some /data subfolders need the correct ownership and permissions for Android to work properly.

Most notably, the /data/data, /data/dalvik-cache, /data/app, and /data/app-private subfolders need to have the correct permissions for Android to work correctly.  This means they must be on a Linux compatible filesystem.

Since some /data subfolders can't be copied to a FAT32 drive and some folders require correct permissions, it's obvious that the /data mount partition must reside in a Linux compatible filesystem:


13. The /data partition needs to be on a Linux compatible filesystem

I tried all I could to move parts of /data to the SD card and I came to the conclusion that /data requires a Linux compatible filesystem so it seems there's no way around this.  After I copied the contents of /data to an ext2 filesystem on the external SD card and mounted that filesystem as /data, everything worked correctly.

In order to create an ext2 filesystem on the external SD card, you have two options:

14. Either create a partition or create a virtual filesystem to have an ext2 filesystem on an external SD card

Most solutions recommend creating a separate partition on the external SD card for the ext2 filesystem.  The disadvantage with this solution is that you have to format the contents of the whole SD card, erasing everything on it.  The storage space allocated for /data is fixed and cannot be increased.

If you switch to a different SD card, you have to format the SD card, erasing everything again and then create another partition.  To reuse the whole storage space of the old SD card, you have to format it, erasing everything as well.

I bypassed these issues by using the other method for creating an ext2 filesystem on an external SD card:

15. A loopback filesystem can be created on the external SD card

I found out you can create a blank disk image file on a FAT32 filesystem, format the disk image as an ext2 filesystem, associate the disk image with a loopback device using the 'losetup' command, and then mount the loopback device.  With this method, you can create and then mount an ext2 filesystem image on an external SD card without having to format and partition the SD card.

The advantage of using a loopback filesystem on an external SD card, instead of partitioning it, are - you don't need to format the SD card to create another partition, you can easily transfer the disk image to another SD card when you want to switch, and you can resize the filesystem by creating a larger disk image and copying the contents to the new filesystem.

Like the partition method, the loopback filesystem can be used to increase the storage space of /data:

16.  The storage space of the /data partition can be easily increased by using a loopback filesystem

After I created a disk image of 2.6 Gb, larger than the 1.8 Gb size of the internal /data partition, I mounted it as a loopback device on /data.  This gave me a larger space to use to install more apps.

After I solved how to make /data writeable again, I turned to fixing the internal SD card:
 
17. Mounting the external SD card to /mnt/sdcard allows normal operation

 By experimentation, I determined that unmounting /mnt/sdcard and then mounting the external SD card to /mnt/sdcard provided successful results.  I made sure there was a /mnt/sdcard/ext_sdcard folder on the external SD card.

I tried many different ways on how to mount the external SD card as the internal.  I tried swapping them in the vold.fstab file and it worked but I couldn't move apps to the SD card because it was read-only.

I did what I could to mount the external SD card as both the internal and external but no matter what I tried, using the vold.fstab wouldn't work completely.  In the end I avoided using the vold.fstab:

18. There is no need to modify the vold.fstab file

All you need to do is mount the external SD card on /mnt/sdcard and create an ext_sdcard folder on the external SD card. This allows the external SD card to be detected as both the internal and external SD card and allows apps to be moved to the SD card.

The last thing I found while researching a solution is not really required to fix the Galaxy Tab:

19. There is script code that is able to detect and wait until the external SD card is mounted

I used this script code for awhile in my experimentation but in the end, it was not part of the solution.

Finally, even if the Galaxy Tab was pretty expensive, its popularity resulted in a lot of people sharing knowledge about the device:

20. I was able to find a solution because of the openness of Android and the fact that the Galaxy Tab GT-P1000 was widely known.

If our iPad, iPhone, or iPod Touch failed, I doubt if I could find information on how to fix them at the OS level and that's because there is very little capability and information on how to modify iOS similar to what can be done to Android.

If the same problem happened to a lesser known tablet, I don't know if I could draw on enough available information to be able to fix the tablet.  Despite their cost, the strength of Samsung devices is the sheer number of people who own them, which results in the wealth of knowledge that can be found throughout the Internet.

So although the Samsung brand may be costly, it, together with Android, ensures that there will be enough support to be found when you look for it.