Here we go again.
Just recently, I tried to update my Galaxy Tab 10.1 from Android 3.0 to 3.1, only to find out that the upgrade process is not fond of encrypted /data partition. As the result, I had to wipe clean all of my data and start again from scratch.
So, a few weeks later, it seems that I'm facing the same proposition. I hit the infamous boot loop, which, in my case, seems to be the result of a corrupted database file on the
So... here's what happened.
Upon trying to open a PDF file in the Astro file manager, my tablet just froze up. So I tried to reboot it, which at first it was not willing to do. "Fortunately", holding down the power key a bit longer seemed to do the trick, only to find out that the tab is now unwilling to boot.
Upon power-up, one of two things happen.
It either gets into what appears to be a kernel panic (which I'm not sure how to explain yet):
or gets stuck in, what some people call, "boot loop".
The "boot loop" is just
Fortunately, I had enabled "USB Debugging", so at least I have
Why would this file affect the entire booting process? Well, since the
Other than rooting (which I don't want to do on my primary device), I'm left with wiping it clean yet again... and starting over... hoping that it will be kinder to me in the future.
For anyone wondering, this is what I'm seeing in the logs:
In case you are wondering how to hard-reset your tab, you can follow these steps:
1) Power off the device by holding the power key for about 8 seconds
2) Press the volume down key (the one to the left, as I always confuse them) and then the power key
3) Within a couple of seconds, you'll see two logos on the device, one for USB and another, that looks like a Android dude shoveling earth
4) Press the the volume down button to select the the USB icon, and then press the volume up button to make the actual selection
5) Your device is now in the "fastboot" mode
6) Finally, open up your terminal/shell and type
7) Restart your device
8) You should now be prompted to set it up... all over again
Just recently, I tried to update my Galaxy Tab 10.1 from Android 3.0 to 3.1, only to find out that the upgrade process is not fond of encrypted /data partition. As the result, I had to wipe clean all of my data and start again from scratch.
So, a few weeks later, it seems that I'm facing the same proposition. I hit the infamous boot loop, which, in my case, seems to be the result of a corrupted database file on the
/data partition. System wipe, here I come again :-(
So... here's what happened.
Upon trying to open a PDF file in the Astro file manager, my tablet just froze up. So I tried to reboot it, which at first it was not willing to do. "Fortunately", holding down the power key a bit longer seemed to do the trick, only to find out that the tab is now unwilling to boot.
Upon power-up, one of two things happen.
It either gets into what appears to be a kernel panic (which I'm not sure how to explain yet):
Code:
====================================
Entering upload mode...
Upload_Cause: undefined
====================================
or gets stuck in, what some people call, "boot loop".
The "boot loop" is just
/system/bin/samsungani running (displaying the Samsung animation), while system_server (powering Android's application framework services) is trying to start up. Fortunately, I had enabled "USB Debugging", so at least I have
adbd running - so I am able to adb shell to the device. Running logcat shows that the the com.android.providers.settings.SettingsProvider is failing to start up because it is unable to read from /data/system/accounts.db SQLite database file. This file appears to be corrupted because right next to is a 0-byte accounts.db-journal file, indicating that the accounts.db was not properly synced after the last write. Why the sync? Well, as of 2.3, Android prefers the ext4 file system over yaffs2 (for a number of good reasons). The problem with ext4 is that it is a journaling file system, which does quite a bit of buffering - for performance reasons. If you don't sync()... you don't commit your writes. This would normally not be such a big deal if I was able to root to the device to repair it, but given that I run it stock, there is not much I can do to fix this file (which is 660 and owned by system:system). Why would this file affect the entire booting process? Well, since the
SettingsProvider is failing, this is causing the entire system_server to fail, so Android's init process tries to restart it, only to run into the same problem again... and again... and again.Other than rooting (which I don't want to do on my primary device), I'm left with wiping it clean yet again... and starting over... hoping that it will be kinder to me in the future.
For anyone wondering, this is what I'm seeing in the logs:
Code:
...
I/SqliteDatabaseCpp( 1217): sqlite returned: error code = 14, msg = os_unix.c: open() at line 26528 - "" errno=30 path=/data/data/com.android.providers.settings/databases/settings.db-shm, db=/data/system/accounts.db
I/SqliteDatabaseCpp( 1217): sqlite returned: error code = 14, msg = unable to open database file, db=/data/system/accounts.db
E/SqliteDatabaseCpp( 1217): CREATE TABLE android_metadata failed
E/SQLiteDatabase( 1217): Failed to open the database. closing it.
E/SQLiteDatabase( 1217): android.database.sqlite.SQLiteCantOpenDatabaseException: unable to open database file
E/SQLiteDatabase( 1217): at android.database.sqlite.SQLiteDatabase.native_setLocale(Native Method)
E/SQLiteDatabase( 1217): at android.database.sqlite.SQLiteDatabase.setLocale(SQLiteDatabase.java:2115)
E/SQLiteDatabase( 1217): at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:984)
E/SQLiteDatabase( 1217): at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:956)
E/SQLiteDatabase( 1217): at android.database.sqlite.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:1021)
E/SQLiteDatabase( 1217): at android.app.ContextImpl.openOrCreateDatabase(ContextImpl.java:742)
E/SQLiteDatabase( 1217): at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:149)
E/SQLiteDatabase( 1217): at android.database.sqlite.SQLiteOpenHelper.getReadableDatabase(SQLiteOpenHelper.java:223)
E/SQLiteDatabase( 1217): at com.android.providers.settings.SettingsProvider.query(SettingsProvider.java:398)
E/SQLiteDatabase( 1217): at com.android.providers.settings.SettingsProvider.ensureAndroidIdIsSet(SettingsProvider.java:317)
E/SQLiteDatabase( 1217): at com.android.providers.settings.SettingsProvider.onCreate(SettingsProvider.java:256)
E/SQLiteDatabase( 1217): at android.content.ContentProvider.attachInfo(ContentProvider.java:955)
E/SQLiteDatabase( 1217): at android.app.ActivityThread.installProvider(ActivityThread.java:3883)
E/SQLiteDatabase( 1217): at android.app.ActivityThread.getProvider(ActivityThread.java:3685)
E/SQLiteDatabase( 1217): at android.app.ActivityThread.acquireProvider(ActivityThread.java:3701)
E/SQLiteDatabase( 1217): at android.app.ContextImpl$ApplicationContentResolver.acquireProvider(ContextImpl.java:1573)
E/SQLiteDatabase( 1217): at android.content.ContentResolver.acquireProvider(ContentResolver.java:909)
E/SQLiteDatabase( 1217): at android.content.ContentResolver.insert(ContentResolver.java:715)
E/SQLiteDatabase( 1217): at android.provider.Settings$NameValueTable.putString(Settings.java:595)
E/SQLiteDatabase( 1217): at android.provider.Settings$Secure.putString(Settings.java:2428)
E/SQLiteDatabase( 1217): at android.provider.Settings$Secure.putInt(Settings.java:2506)
E/SQLiteDatabase( 1217): at com.android.server.ServerThread.run(SystemServer.java:524)
E/SystemServer( 1217): Failure starting SamplingProfiler Service
...
In case you are wondering how to hard-reset your tab, you can follow these steps:
1) Power off the device by holding the power key for about 8 seconds
2) Press the volume down key (the one to the left, as I always confuse them) and then the power key
3) Within a couple of seconds, you'll see two logos on the device, one for USB and another, that looks like a Android dude shoveling earth
4) Press the the volume down button to select the the USB icon, and then press the volume up button to make the actual selection
5) Your device is now in the "fastboot" mode
6) Finally, open up your terminal/shell and type
fastboot -w, which will completely erase your userdata and cache partitions (took about 12.5 seconds for me). I got the fastboot by building it from source, but you can download pre-built binaries from various sources on the web7) Restart your device
8) You should now be prompted to set it up... all over again