I recently purchased a G2 off eBay which was stuck on 4.2 and wanted to try to upgrade it, but ended up destroying both the boot and recovery partitions in the process. I got into a similar situation as seen at <http://forum.xda-developers.com/tmobile-g2/help/lg-g2-bricked-download-recovery-t3450021> (how annoying is it when people just say "solved" without any answers?) and then compounded the issue further by wiping the entire phone, partitions and all because it otherwise refused to respond in any way anyway...
Since then, I've been looking around online for ways to reformat Android, not just flash new ROMs through the existing filesystems since ADB/Fastboot/Recovery is all literally nonexistent. I'm already considering this a waste of $80 to begin with, and the phone now literally is "hard bricked" in that it doesn't respond in any way to any buttons or connections or anything. I can still see it as an unformatted drive in Linux (/dev/hdb with an invalid MBR and no partition data) but Windows just gives me the ol "undetected/broken USB device" message. If anyone's got any clever ideas for rewriting the entire filesystem, I'd really like to hear them.
Related
As I suspected early on the issues boil down to corruption within the User Data or Cache partitions, less often on the system partition due to an unexpected shutdown of the device. Shut on these devices need to follow the proper shutdown routine as any linux environment. Following this best practice will ensure that all data is written out to its corresponding file system by flushing all cache, unmounting the file system, etc..
Here are the culprits of why we see so frequent random Force Closes, Market Resetting, etc. ultimately resulting in an unclean shutdown, corrupting some data.
1. The button we use is also a forced off button. Typically if you hold it down too long you are powering off the device.
2. Some times when in sleep mode you see the Viewsonic logo upon starting - that means that the system shutdown (most likely crashed).
3. If your running Vegan your hitting the reboot.. I dont know for sure but I suspect this is NOT performing a clean shutdown... (I dont have a copy of the source)
Anyway... wanted to pass this on... as last night my data partition became corrupt after using the Reboot function on the Poweroff menu of Vega 5.1..
shouldnt need source code to debug a dirty shutdown..Cant you just run an adb logcat? maybe run the shutdown command in a terminal on the device and pipe the output into a text file for later viewing
My internal memory has to be repartitioned every few weeks - I'm certain that something is corrupting it over time. I had massive FC's just a week or so back where the SD partition re-do was the only fix.
I suspect that this happens in stock, as well - the problem of course is that there is no fix for a stock user, other than a return / exchange.
roebeet said:
My internal memory has to be repartitioned every few weeks - I'm certain that something is corrupting it over time. I had massive FC's just a week or so back where the SD partition re-do was the only fix.
I suspect that this happens in stock, as well - the problem of course is that there is no fix for a stock user, other than a return / exchange.
Click to expand...
Click to collapse
I have been on stock since I got the device just moving to the newer versions when they come as OTAs and have never ever had to mess with my partition, so I don't THINK the issue is in the stock software. In fact, the only problems I've ever encountered were when I used the enhancement pack, in which case my screen started to become unresponsive and the calibration.ini I was told to try did not work. Since then I went back to 3389 and the device has been perfect ever since.
I could be wrong though and just very, very lucky....here's to hoping. Another thing to consider is maybe the memory is going bonkers for some reason. I've had flash memory that lasted forever and I've had flash memory that has gone wacky over a period of 6 months....even a wipe by the utility designed to do it doesn't fix it properly. I don't know how CWM wipes or partitions the memory, I do know there's supposed to be a special way to do it.
If it's not faulty memory off the bat, then that leaves something in the 'extras' being put into these ROMs. Maybe some of the newer tegra drivers or some coding to make the ROMs faster - I'm just saying, can't leave any stone unturned.
Has anyone that has stayed loyal to stock encountered these issues? We have to ask that question I think. Then we ask how many of the people playing with ROMs are seeing the issues, this would include people that have used CWM to partition and mess with their mounts initially.
I can say I've never seen data disappear from my internal memory or my SD and I can also say I've never seen multiple FCs except after putting in the enh. pack (keep in mind I got my tab on Dec 20something, so I had 3053 and then 3389 soon after).
The first sign of anything being 'corrupted' on it's own at stock and I'll be sending mine back. As an owner of Android since Android's been around, I've never had my G1 or MT4G (or any smartphone before it) become corrupted due to not being shutdown or reboot properly and while this is a tablet I think the fundamentals should be the same. Pampering 'faulty' memory is a risk. You can wipe and re-do all you want, but if it's faulty it's going to stay that way.
Ive done that but I guess you can say unfortunately I have had only clean shutdowns since then... The last corruption I had I formatted my data and cache partitions before I ran logcat.... Of course thought of that afterward....
Generally if any has FCs, etc. etc. run a logcat and post it here... we will be able to confirm this...
We could change the way the partitions are created and add a sync which will further reduce chances BUT will take a performance hit...
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
I reviewed the out of the box framework source on the google GIT and technically if a reboot command is given a clean shutdown is performed via the framework... but the widget on the shutdown screen I suspect is not calling the method properly or is not being called at all... All speculation at this point... But for sure there is corruption occurring..
Since the last corruption I switch over to pershoots kernel... Even though his kernel seems to be a little slower he seems to have included the latest drivers which other items relate to data integrity (im reading into the release notes).
NEO: The first thing I did when I got my device install CW, Vegan... Updated Kernels also... Never had an issue until the first time (yes about a day ago) I used the reboot feature of Vegan. That corrupted my user data. I suspect if you have not been performing clean shutdown then you are just lucky. Linux, like any other OS, even with Journaling if you do not perform a clean shutdown you will surely encounter SOME corruption. Typically the corruption is re-mediated by the the file systems integrity controls. You dont even know it happened... 1 in 1000 the integrity controls can not overcome the significant loss of data and thus results in crashes, etc. Some times the corruption happens in areas where are lightly used thus why you would get a Market Reset... that data is easily replaceable on the fly. Core components that require subsystem to run are not replaceable and thus why I had to reformtat. What upsets me is that this failsafe is not working properly most likely as its far too frequent.... I too suspect it has something to do with CW.
But again.. between the wrongly placed power switch, the unprovoked reboots (ie viewsonic screen showing when trying to wake up the device) and the reboot button possibly not performing a proper shutdown will sure increase the chances in a wider distribution of users. So it may not be a CW issue and just some poor design.
When I have time today I will verify if the reboot function performs a clean shutdown... if anyone has the time please post the logcat... Im going to be running around today and will try to get to it..
watson540 said:
shouldnt need source code to debug a dirty shutdown..Cant you just run an adb logcat? maybe run the shutdown command in a terminal on the device and pipe the output into a text file for later viewing
Click to expand...
Click to collapse
stanglx said:
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
Click to expand...
Click to collapse
AFAIK they're running yaffs ATM. Next move is to ext4...
Read some articles about this several weeks ago, apparently many apps do not properly flush file caches. One of the articles was a Google developer post about file corruption along with their API method which did a cache flush prior to a close, then a bit later was the Google indication that they were planning to move to ext4 FS to further help alleviate the problem.
stanglx said:
I am very surprised though as the EXT3 filesystem is very resilient to dirty shutdowns (more than EXT4)...
I suspect if you have not been performing clean shutdown then you are just lucky. Linux, like any other OS, even with Journaling if you do not perform a clean shutdown you will surely encounter SOME corruption. Typically the corruption is re-mediated by the the file systems integrity controls. You dont even know it happened... 1 in 1000 the integrity controls can not overcome the significant loss of data and thus results in crashes, etc. Some times the corruption happens in areas where are lightly used thus why you would get a Market Reset... that data is easily replaceable on the fly. Core components that require subsystem to run are not replaceable and thus why I had to reformtat. What upsets me is that this failsafe is not working properly most likely as its far too frequent.... I too suspect it has something to do with CW.
Click to expand...
Click to collapse
That's my point. How many times since we've had our Android and smart phones have we had situations where they are turned off or rebooted without the proper procedures? Power drains till they die, they drop and reboot, we clog them up with stuff or some app drives them nuts and they reboot or shut off....Yet you rarely if ever hear about a phone's data being 'corrupted' with stock software. Sure it may happen with official OTAs etc, but never just off-the-bat like what's happening with the G-Tab. But it's not happening to everyone either so I'm just looking to see if there's a pattern.
Even since the G1 and newer phones, you don't really hear about or see file corruption issues on stock software with these phones. It's when users start going to ROMs that you hear of issues cropping up. That's not to say it doesn't happen at all at stock, I just think we're seeing it in a more concentrated fashion here because of all the formatting, re-partitioning, etc. At first you hear, 4GB is a great partition size, then you hear there are problems so move to 2048, then you hear 256MB swap, then no swap since Android doesn't use it. Then dataloop for speed, then no dataloop because of critical issues. Rules and instructions change almost on a daily basis. I think it's more than these poor flash drives can take I find sometimes it's good to keep it simple.
I owned a Vibrant for a while...decided it was a PoS when at stock I was seeing bad lag (because of Sam's terrible FS). People said...do the speedhack, it'll be fast!, but what was the caveat? Having to reboot the phone almost weekly, sometimes several times a week, and people were seeing what? Data corruption. That's not for me. Give me something that is lag free (doesn't have to be a bullet train, just don't skip on video or audio and make sure my live wallpaper and drawer animation is fluid and I'm happy!). Point being....keeping it simple may help to alleviate some of the issues. If people are seeing these problems with stock, then you're absolutely right and it would be a point of contention that the failsafe isn't working right.
Otherwise it seems the stock OS on these things are able to self correct in most situations and it may just be some of the many tweaked features in these ROMs doing something it shouldn't - or, I may just be very lucky indeed.
I'm still dying to get the OTA - I haven't seen one since 3899 yet.
Dear XDA-Community,
I'm writing to you after extensive google search without any proper help for this weird situation. I'm on a Galaxy S2 with a rooted android 4.1.2 afaik, and unfortunately I'm only the type of "forum expert" that can follow complex instructions but has no real clue about what exactly the software mechanisms behind are.
The phone has been encrypted for years now, password never changed and password is the same as on my tablet. The phone occasionally reboots because the second phone in my pocket pushes against the power button of the S2. Has been annoying but never a problem.
Now today, the same happens. Phone reboots and asks for decryption password as usual. I type it in, short delay, "Please type again". I carefully retype and get the same result. I check keyboard layout or anything and type again while checking every character carefully -> same result. Because at this point I doubt my own intelligence, I check if the same password works on my tablet and it works without problems.
So basically it appears as though my phone "forgot" the pass, if that even makes any sense. I know enough about encryption that that should be impossible and trying other passwords is basically pointless.
What is strange, is that it seems as if there is almost a second delay between submitting the correct password and getting the "please type again" answer, while with incorrect passwords the prompt immediately shows.
I've tried some useless things like entering the pass in recovery mode, whiping the cage and davyk cage (iirc). Restoring obviously don't work because I didn't backup before. Backing up to internal SD yields the following messages:
ClockworkMod Recovery Screen after Backup attempt:
-Start-
ClockworkMod Recovery v5.8.1.8
SD Card space free: 1902MB
Backing up Boot Image....
Backing up Recovery Image...
Backing up System...
Backing up Data...
Can't mount /data!
-End-
only change that might have taken place recently is that a week ago the superSU software successfully downloaded an update and I'm not sure but the phone may not have been rebooted since. Can SuperSU mess with any encryption/decryption password things?
I'm down to 7 chances before my system is whiped and let me say, the amount of idiocy regarding what is on that phone that is not backed up somewhere is unimaginable.
So there I am begging for your wisdom.
Has any of this happened randomly before?
Thank you so much in advance and I wish you the best of days.
P.S.: Back that data up - from a moron who doesn't want to share his feeling of remorse with other undeserving droiders
I purchased two VS995's last year for myself and my wife from Verizon, and up until recently it worked great. Last month, I entered a boot loop that wouldn't stop and took it to a repair shop.
While looking into fixes that might work before contacting a shop, I remember reading that the V20 was encrypted by default as well as that by requiring a user to input a PIN during boot your device also was encrypted.
I assumed this would hinder recovery efforts and that I was throwing money away by taking it to a repair shop, but was assured that it wouldn't matter during a chip off recovery, since no data is stored encrypted.
I am familiar with data recovery from broken hard drives and partitions on both Linux and Windows, but I'm not sure about how the process works with encrypted file systems and chip off methods on Android devices.
If anyone could offer any information on if the above is correct regarding the encrypted file system and it not being a problem, or how to deal with it if it is, I would really appreciate it.
My thought process was to get an image of the file system and load it into either something like BlueStacks as the local file system to extract data off that wasn't backed up to the cloud (Quickmemos, current browser session on Chrome, the list goes on and on), or mount it using linux like any other partition.
I'm not sure if I can go in and ask the repair shop to specifically make a binary image of the chip so that I can recover the data myself or not and provide them with a flash drive, but I figure it's worth a shot. I used my phone in place of a computer, and had pictures of my family's social security information that my work had requested as well as internal documents I had to learn as a manager when I was promoted. I figured they were protected by the boot up password until I could back them up, and the phone died a few days before my scheduled backup. Anyone who repair phones for a living have any thoughts on how to request specific things from a phone repair place or how you want your data handled?
I appreciate all the help, and apologize for the long winded post. I wanted to try to cover everything in one shot I also forgot to mention that the phone is 100% stock. Thanks in advance!
userdata (all your actual data) certainly is encrypted by default (though rooting usually disables the encryption), requiring a pin at boot or not is just changing how the real encryption key is stored ( encryption key of the encryption key). AOSP article goes into some more detail.
No idea how shops handle it, I've just done a bit of research on it before.
Hey all,
I admit, I'm new to this whole android os thing, and this is only the second smart phone I've ever had. so far I gotta say, I'm not impressed with these things.
I've been banging my head against various bricks in this wall for the past three nights, and could really use some help before I decide to incinerate this Xperia.
Im trying to load and run Aosp 10 for this thing, but the few times I've had it stable, I've found It was really rather barren and honestly useless beyond strictly phone calls and texting.
over the course of these past three days, I've encountered; mounting errors (failed to mount oem/system/vendor,) issues with twrp becoming inaccessible (requiring a re-flash) after any successful operation of the Aosp 10 rom, at which point I may or may not be able to get the rom to boot again. Perhaps my assumption that they can coexist (basically a dual boot) is incorrect.
I've tried both the most recent & relevant standard twrp, and the Kagura version of twrp, to no avail. I'm still currently fighting "failed to mount /OEM". this has only ever resolved randomly (seemingly) in the past, only to crop back up again. I've formatted everything (short of the sd-card) 6 ways from sunday (getting the "failed to mount /OEM" the whole while during this operation).
I've tried older versions of roms, twrp, etc..
I'm burnt out on this trouble, and perhaps my choice of rom or phone was a mistake. All I'm after here is a rom (or phone, or hell, maybe a PDA) that works reliably, doesn't glitch a ton, have its screen adhesive fail, or suffer encryption so deep and aggravating its useless for simple and plain operations (looking at you APPLE). A "set it and forget it for a while, works when I need it and doesn't glitch out when needed,
well thought out and designed device.
Point me in the right direction here guys. My programming days are years behind me and the rest of the world, and I've not got the time or patience to learn & write a new rom/os from scratch.
sincerely-Psykora
Hey all,
I'm a little in a pickle, but first some background I have a nice phone, a Samsung Galaxy Note 2, running Android 12 (not actually relevant, but like mentioning it regardless ). A while ago, I had to replace the motherboard, because the modem wasn't working anymore. I had a spare motherboard that I bought off of Ebay some time ago (to do some experimentation/hacking with) and used that as the modem was actually still working.
Last week, my phone just started to bootloop all of a sudden, sometimes stuck on the logo, but often just the Lineage logo looping forever. Looking at adb shell just showed zygote crashing and restarting, not important, but after some experimentation from within twrp and memtester, it might seem that the RAM was bad, or so I thought.
A factory reset (e.g. wiping USERDATA), made the phone boot somewhat, but it was almost impossible to get through the setup wizard, very slow, lots of crashes.
Anyway, I dd-ed the USERDATA partition into a file (can mount it just fine on my desktop), fsck says its fine), and put it on my old motherboard (which after lots of cleaning of the whole phone, like an engine overhaul the modem works again!), the same linegae failing to boot/zygote crashing came back. Strange, wiping the userimage partition and setting up the phone makes everything work fine.
Right, so now, I want to move over some apps from the old partition to the new. I can't boot the old phone, not in safe mode, just twrp (though it's dissasembled, so is not really easy atm) and access the old partitions. Particularly, I want to move over Signal, as it contains my chat history and media. I can copy some folders around, but I'm sure the user permissions will be off. So my thinking right now is, install signal, note uid/gid, copy over files from old phone with proper permissions and be done. First thing I noticed though; is that Android 12 stores app and (secure?) app data with some ~prefix~, do I need to worry about that? Are the other gotcha's.
In the end I figure, if all the data is exactly there as on the old phone, it should 'just work (tm)' (in theory) but with signal particularly, there's some crypto magic of course (I don't mind factory resetting stuff and copying more stuff, but I have a dark feeling, that the bad ram caused some bits to be rotten in some 'slightly more important' files making my dump less prestine as I would have hoped.).
Thank you,