Trashed NAND


ZXDunny

Deep avatar
Joined
Oct 12, 2010
Messages
2,585
Ok, installed SZ5a, downloaded and installed android PND, rebooted, downloaded the CM7 google apps archive, unpacked to the android appdata directory, rebooted into android...


Now hangs with a "Settings manager" grey strip across the top of the screen, does nothing else - no way to kill android. Rebooted pandora (hard reset) and now the NAND is trashed :(


Gonna have to reflash the firmware - beware, folks!


D.
 
If you still have the boot loader, "thrashed NAND" is maybe a bit excessive ;^).


GL anyway ^^.
 
Now i hope everyone learned the most important lesson! Linux traitors defecting to android will suffer!!!Ahahahaahahaaaaaaaaaa
 
That's not an Android bug.


It's some bug still left in the new kernel 3.2, it can also happen when the unit freezes in the normal OS right now (happened 2 - 3 times for me already. Need to try to reproduce it while a BoB is connected to send logs to notaz).
 
But if we consider that Android got a Linux kernel, and the kernel 3.2 has a bug, it's still an Android bug. No ?


;p
 
I've seen that crash a few times, it's always touch and go when I have to hard reset my Pandora!!


(null)
 
Did you remove the Metainfo folder after copying the gapps? Like suggested everywhere?
 
Did you remove the Metainfo folder after copying the gapps? Like suggested everywhere?

Of course. Followed instructions exactly as documented in the pinned topic, and Android failed to boot after the google apps download (for CM7, as documented) was corrrectly installed by unzipping it, and removing the meta-inf directory.


Not only do I now have to re-flash the firmware, but I also have to remove the Android appdata folder and re-install that too :(


D.
 
It's some bug still left in the new kernel 3.2, it can also happen when the unit freezes in the normal OS right now (happened 2 - 3 times for me already. Need to try to reproduce it while a BoB is connected to send logs to notaz).
It's not a bug. You can't just cut power at random time and expect everything to work.
 
Last edited by a moderator:
It's some bug still left in the new kernel 3.2, it can also happen when the unit freezes in the normal OS right now (happened 2 - 3 times for me already. Need to try to reproduce it while a BoB is connected to send logs to notaz).
It's not a bug. You can't just cut power at random time and expect everything to work.

True, but as this happens with Kernel 3.2, but not with the old kernel, there's something that seems to be different here, or not?


Kernel 2.6 seems to have some code different so that this corruption doesn't happen.
 
Last edited by a moderator:
I think corruption does happen on 2.6 but it's different, most likely corrupting individual files instead of everything. This would cause strange behavior (like xfce no longer starting) and would need to be reflashed anyway, so now at least it's clear right away that you need to reflash.
 
Hm, within the last 2 years using Kernel 2.6, I think I only had to reflash one or two times because of weird file corruptions.


However, it happened 3 - 4 times within 2 weeks with Kernel 3.2


Are there maybe some sync-settings (timeout, etc.) that are configured differently?


That could be a probable cause. Maybe UbiFS in the old kernel is configured to sync right away and the new one takes a while?


Or maybe the other way round: Kernel 2.6 crashes BEFORE the UbiFS is written to (so nothing happens), whereas Kernel 3.2 starts writing to it right away and THEN crashes while writing...?


I don't know.


I agree it's certainly bad to suddenly cut the power, that's for sure :)
 
Are there maybe some sync-settings (timeout, etc.) that are configured differently?


That could be a probable cause. Maybe UbiFS in the old kernel is configured to sync right away and the new one takes a while?
No.

Or maybe the other way round: Kernel 2.6 crashes BEFORE the UbiFS is written to (so nothing happens), whereas Kernel 3.2 starts writing to it right away and THEN crashes while writing...?


I don't know.
Me too.
 
It's just an inconvenience; nothing of value was lost.


It's odd that the Pandora was completely unable to boot - all I could do was start again at the boot menu, and set up sz5a from SD Card again :(


What is galling is that I'll have to go through the whole first-boot setup again, then set up the desktop as I like it, removing the icons from the taskbar/panel and setting the theme and compositing options etc.


Which leads me onto another question...


Given that we only have 512MB of NAND, would a utility be useful for folks that backs up the entire of the NAND to a compressed file which, if present on the left SD card could be used to restore to a known state? If people don't want to devote a few hundred megs of SD space to it they can opt not to, but given the size of SD cards these days it might be a useful option. If this archive could be created at any time by the user, it would be very good indeed - it would be pointless to have it as an option in the OS installer, but tucked away in the system menu would be more useful.


Then we'd just need the bootloader to be modified to use it...


Thoughts?


D.
 
Back
Top