Difficult reboot after reflash

[GoogleCodeExporter]

After flashing all CM7.2.4 versions, the first reboot is usually stuck with "M" 
logo on display. Even after waiting for a long time (like 5 minutes), the logo 
is still there and the reboot process is apparently stuck.

Currently I use 7.2.4e, but the problem occurs with every 7.2.4 version.

What steps will reproduce the problem?
1. The phone has any CM7 version running (it was installed according to 
instructions linked from project home page).
2. I boot to open recovery.
3. I clean cache partition and dalvik cache.
4. I apply update CM to the latest release after checking MD5 hashes etc.
5. I apply update Google apps (otherwise Google apps like Market or Mail are 
not present after update)
6. The first reboot will not complete while the "M" logo on the display is 
still visible. I had to reboot (by removing the battery) and potentially 
reflash several times before it finally works.
7. The reboot usually takes more time but still, the "buggy boot" process is 
different from "the first longer boot".

I use 1GB ext3 partition to extend internal memory and allow installation of 
many/big apps.

There is a tip in the discussion in the home page to remove the ext3/4 
partition prior to booting or boot without SD card but I am not sure if it is 
possible and safe to perform the first boot without the SD card if many (if not 
all) apps are installed on the ext3 partition.

Original issue reported on code.google.com by martin.b...@gmail.com on 19 Jan 2013 at 11:03

[GoogleCodeExporter]

Something goes wrong while you're applying the update in OpenRecovery.
There may be some bad blocks in your internal NAND that limit the available 
space in some mtd block in your case, so the files from the CM update zip do 
not fit there.
If you'd be able to fetch /cache/recovery/open_recovery_log after the 'apply 
update' action, it could help to pin-point the issue.
You can use e.g.:
adb fetch /cache/recovery/open_recovery_log
on command line in PC, while in OpenRecovery, after the update.
Please post the log here for inspection.

Original comment by kabal...@gmail.com on 19 Jan 2013 at 11:55

• Changed state: Reviewed

[GoogleCodeExporter]

oops, it should be:
adb pull /cache/recovery/open_recovery_log

Original comment by kabal...@gmail.com on 20 Jan 2013 at 12:31

[GoogleCodeExporter]

OK. I have done what you asked me to do: I have got a open_recovery_log (I had 
to copy it to SD card from console in OR since I don't have working ADB on my 
64bit Ubuntu... nevertheless, I got it). I noticed some "bad block" issues 
there, but you will probably know what is wrong here and if there is any way 
how to fix it...
BTW, I am not sure if it is OK, but when flashing the CM, it takes some time 
before the progress bar shows something.
It seems that after second CM+GApps flash the reboot is OK.

Original comment by martin.b...@gmail.com on 20 Jan 2013 at 11:16

Attachments:

• open_recovery_log

[GoogleCodeExporter]

Hi, did the file I uploaded help you to figure out what's the problem about?

Original comment by martin.b...@gmail.com on 31 Jan 2013 at 10:19

[GoogleCodeExporter]

Which version of OpenRecovery are you using?
The system is not mounted at all during the installation.
There was a bug that caused that in old OpenRecovery versions (prior to the 
current v1.46).

Original comment by kabal...@gmail.com on 31 Jan 2013 at 10:48

[GoogleCodeExporter]

I use OpenRecovery 1.46 from OpenRecovery_v1_46_SHOLS_2ndboot_2_6_32_Charge.zip 
(I don't know how to get better version information from the OR, OR only says 
1.46, nothing more).

Original comment by martin.b...@gmail.com on 31 Jan 2013 at 10:57

[GoogleCodeExporter]

Please update to the current 2ndbootOR_v1_2:
http://code.google.com/p/cyanogenmod4milestone/downloads/detail?name=OpenRecover
y_2ndbootOR_v1_2.zip
Let me know if it helped, thanks.

Original comment by kabal...@gmail.com on 31 Jan 2013 at 11:05

[GoogleCodeExporter]

I have updated the OR to the suggested version.
Then I have reflashed the CM twice and in both cases the flash process went 
smoothly, with no issues, no got-stuck-in-the-middle-of-something troubles.
I think that it can be closed, as it seems, it was caused by OR version.
Thank you very much for help!

Original comment by martin.b...@gmail.com on 31 Jan 2013 at 3:39

[GoogleCodeExporter]

Rádo se stalo :)

Original comment by kabal...@gmail.com on 31 Jan 2013 at 4:30

• Changed state: Done