Related
Here's what I've done so far and info relating to my setup
Phone: klte - G900T (T-Mobile Samsung Galaxy S5). I'm not on SafeStrap, I'm installing to system. I'm running TWRP recovery 2.8.4.0.
I first installed the CyanogenMod 12 nightly for 20150204 with Paranoid Android GApps 5.0.1RC3. All good there. I then went to "Security" and clicked "Encrypt Phone." It didn't ask me to set a password, so I assumed it'd generate a random key for LUKS and encrypt it with the default password. All good there. It rebooted into the "Encryption Wizard," and went through encrypting the phone. Cool, I thought.
It then boot-looped on start, seemingly because it didn't yet understand how to decrypt using the default password. TWRP decrypted data on startup of the recovery just fine, so that's cool. Okay, so maybe the nightly doesn't support decrypting on boot yet. Fine. I upgraded to CM 12 20150208 (today's) and tried again. Nothing.
I then did a factory reset and wiped system, reinstalling CyanogenMod from scratch. No joy either, couldn't boot. What was weird was that I still noticed that it was mounting /dev/dm-0 at /data, so my data was still encrypted. Shoot. How to get rid of encryption? I wrote a ton of zeroes to the beginning of data to wipe out the LUKS header:
Code:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=4096
I terminated this process a while in (probably should have been more exact by specifying how much to zero, but laziness). I then ran
Code:
make_ext4fs /dev/block/platform/msm_sdcc.1/by-name/userdata
Next, reboot recovery, and all is well. Install ROM, and try encrypting again, this time setting an unlock code so that it actually uses a real encryption key instead of default. It reboots, takes a really long time, and then just continues into regular boot, no encrypting taking place, it seems to bypass that. Dangit.
I then tried switching off and on again the set_encrypted_filesystem flag to recovery:
Code:
adb shell recovery --wipe_data --set_encrypted_filesystem=off
adb shell recovery --set_encrypted_filesystem on
No joy, when I try to encrypt it still just reboots regular (albeit really slowly) into regular system and doesn't encrypt. Ugh, I feel like I've lost all progress. I've made sure to clear Dalvik and regular caches on each try, so things shouldn't be persisting. I had an old backup of the stock T-Mobile ROM, so I flashed back to that, and then tried installing CM 12 again and encrypting, and no matter what I do, I can't get to that encryption screen. (my original T-Mobile backup had EFS, Modem, etc. basically everything that TWRP would let me include) [email protected]##$!!! Y U NO ENCRYPT!?
What are my next steps? How can I see what happens in that boot, ie what fails, so I can fix it and get onto my lovely life outdoors?
Shoot, logcat shows the following
Code:
E/Cryptfs ( 241): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
I'd better just zero out the entire thing to bypass this madness. Maybe that's what I screwed up?
I wrote all zeroes to the data partition to clear it out completely:
Code:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=512
Then, encrypt, and fail to encrypt. Output from logcat:
Code:
E/Cryptfs ( 242): Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 242): Error getting crypt footer and key
I'm now going to try again by doing
Code:
adb shell dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=512
adb shell recovery --set_encrypted_filesystem=on
We'll see what happens. This is a weird process.
I am no expert but I had trouble with encryption on my s3 with cm rom a while back.
What eventually helped was to flash official ROM and recovery using Odin, which brought the phone back to life. and then flashing whatever you need.
Hope it helps you.
I'll have to try that. I'm compiling a list of what to try next. This is a bit of a nightmare, but I'm convinced that eventually I can get back to the way it was originally.
Okay, so all this is pretty spooky stuff, but here's what actually worked.
Grab the latest stock ROM. This will take you forever trying to find it on a stupid pay-per-download website and you'll have to hack your way around or through it to get to the download (which won't complete if you have a free account because it's too big, be forewarned). After your (premium!) download completes after 3 hours, use Odin and flash. Once your phone reboots, it'll see something's wrong with /data and will fix it. I'm not sure what fixing it entails, but I have to imagine it's something like wiping the LUKS header/footer (yes, there actually is something called a LUKS footer, as I discovered through this process) and reformatting the partition. It'll reboot again, and you'll be in happy stock land.
Next, install your recovery weapon of choice using Odin (reboot bootloader, flash, reboot recovery).
Next, wipe system and install CM 12. (20150204 works for me) Boot into CyanogenMod, and go to encrypt the phone. Here's the catch: you must use a PIN that's longer than 4 characters. I found this out the hard way. I'm not sure if six characters are required, but my four-character PIN simply didn't work and was the source of so much frustration. Give a good PIN or passphrase (passphrase is obviously better) and go forward with the encryption. My device rebooted a bunch of times and seemed to get into a boot loop. However, on each boot, it'd ask for the PIN, so I knew I was getting somewhere. Unplug it from the wall, and it should boot into the ROM.
Thank goodness, I lost a lot of time on this today.
An interesting aside: it seems that now in Android you can set a different disk encryption passphrase than your screen unlock pattern. FINALLY! Android Lollipop is awesome!
Having the exact same issue with multiple devices!!!
it is always the same! if a device was encrypted on cm12 and you wipe out everything, you will run into that problem again.
So, if a device is used and you want to format it and reuse it, the encryption will always fail! That can not be the right approach!
Understand the problem.
CyanogenMod 12 as of this point doesn't support the default encryption password, which is why it fails to boot. If the encryption password gets set to the default password, like if you change your screen pattern and not specify it for encryption also, it will fail to boot. This is a bug in CyanogenMod 12.
Your recovery also has a bug. If and when you factory reset, if the device is encrypted, the recovery should overwrite the encrypted filesystem footer with zeroes and then recreate an ext4 filesystem there and configure it properly. It doesn't, which leads to this annoying problem of not being able to boot.
rfkrocktk said:
Understand the problem.
CyanogenMod 12 as of this point doesn't support the default encryption password, which is why it fails to boot. If the encryption password gets set to the default password, like if you change your screen pattern and not specify it for encryption also, it will fail to boot. This is a bug in CyanogenMod 12.
Your recovery also has a bug. If and when you factory reset, if the device is encrypted, the recovery should overwrite the encrypted filesystem footer with zeroes and then recreate an ext4 filesystem there and configure it properly. It doesn't, which leads to this annoying problem of not being able to boot.
Click to expand...
Click to collapse
Still struggling with an S4 mini, going back to stock and reflashing again works, but after encryption i have a lot of FCs and clearing cache etc. does not help @ all
So you mean, setting a pin BEFORE encryting will cause this fault?
Cheers,
saint
saintxseiya said:
Still struggling with an S4 mini, going back to stock and reflashing again works, but after encryption i have a lot of FCs and clearing cache etc. does not help @ all
So you mean, setting a pin BEFORE encryting will cause this fault?
Cheers,
saint
Click to expand...
Click to collapse
Not exactly. If you setup encryption with a password or PIN, the encryption should more or less work. If you then change your PIN or password and that change doesn't hit the disk (ie: you elect not to use your screen unlock password as your encryption pasword), the default password will be used, which will fail on boot.
rfkrocktk said:
I wrote all zeroes to the data partition to clear it out completely:
Code:
dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/userdata bs=512
Click to expand...
Click to collapse
This is gonna be hella necroposting, but I did the same thing on different device and I know what I did wrongly. You can't just blow away the entire partition because the last 16KB needs to be dedicated to the crypto footer. Without that, Android has nowhere to store the encrypted key, "magic" header, etc. it needs to process the rest of the partition. That's also why FDE that isn't hardware-backed isn't a great idea. Anyway, that's all. Time to reformat using a slightly smaller filesystem size.
LUKS AFAIK typically uses a header and not a footer on these volumes, which is why I was confused. No idea why the logic is better to store these things at the end of the disk, it makes it much more difficult to target easily.
Hey all,
First post here on XDA and I'm hoping someone with more experience than me will be able to give me a hand! Until last week or so, I was running an up-to-date version of Lollipop (5.1.1), when my tablet started randomly freezing up on me, requiring "soft resets" to get it going again, or simply shutting off on me. Thinking it was software related, I tried wiping the cache with no success, so ended up doing a full factory reset. The issues *seemed* to clear up for a day or so, but came back, and so figuring it was Lollipop related, I wiped out the OS and installed CM12.1 (which was my first experience working with ADB and fastboot, and first time installing a non-stock ROM) with a TWRP recovery. A few days later, the freezing and shutting down issues began popping up again, with the shutdowns *usually* happening during sleep, but the freezing happening at anytime from initial "Google" logo to boot animation, to the middle of running an app. I had made a backup on TWRP when I got CM12.1 configured the way I wanted it, so I performed a soft reset when it froze on me, and booted into the bootloader. The tab kept freezing in the TWRP window before I could select a restore, so out of desperation I tried just doing a factory reset from within TWRP. Long story short, something must have happened during that reset, because it kept hanging on the boot screen. I thought I may have unknowingly messed something up, so I tried downloading and flashing a stock KitKat (4.4) ROM from Google's site, but kept encountering bootloader errors during the flashing and ended up only being able to boot to the bootloader screen (apparently got a faulty 4.3 bootloader in that ROM, which gave me a headache until I was able to get straightened out). I have been able to get a stock bootloader (4.23) up and running now, along with a stock recovery (going with Lollipop now, so stock for LMY47V) going, but that's it. I've tried flashing the stock lollipop image via shell script (I'm running a Fedora 23 machine), via individual commands, and via "fastboot update -w factory_image.zip" without success. ADB sideload still works via recovery, but I wasn't able to sideload the OTA packages for 5.1 either. The common errors that pop up seem to indicate an error (corruption? fragmentation?) on the cache partition, but I'm not a dev when it comes to Android, so I'm at a loss here... I keep getting "E: failed to mount /cache (Invalid argument)", and other errors associated with accessing/opening files further down the /cache tree. Would this error be more likely to be a hardware issue, or would it be a software/firmware issue? I've had similar errors before with USB drives, when they would start to bad and partitions begin failing, but have always been able to rebuild them and get my data back. If something like this is happening on my N7 and the cache partition has indeed become somehow corrupted and failed (but not physically....), is it possible at all to rebuild partitions on Android in a similar manner? I've scoured the web, but haven't been able to find anything that can help me out with something like that, so I figured my best bet before condemning the N7 to the junk drawer was to see if any of the pros around here had any words of wisdom that *might* get me back up and running. Thoughts and advice much appreciated!!
Thanks!
(Oh, I apologize for the lengthy post, but I wanted to be sure to provide enough background info..... Sorry for the lengthy read!!)
Honestly that sounds more like a hardware problem than a software problem.
During the early stages of booting, everything that happens is extremely deterministic - meaning that it should be completely repeatable in terms of the order & timing in which activities occur.
So, for it to behave erratically during early boot suggests that it is not software, but marginal hardware. If hardware is barely meeting logic levels or timing requirements, a small amount of random noise (which is always present) can cause a fault to occur at any time - and that sounds approximately like what you are observing.
Further, you replaced your ROM entirely and the problem persists - again suggesting that the problem is hardware, not software.
The most cost effective way of dealing with repair of a $200 tablet is - unfortunately - disposing of it and buying a replacement.
Sorry.
Thanks for the reply!! Shoot, that's what I was leaning towards too. What is the life expectancy of these tablets? I mean, I got 3 good years of use out of it, so I'm not going to complain, but it seems like they should have lasted longer... Would it be worthwhile to maybe grab a cracked screen N7 off eBay for parts and try to get my tab working with those parts maybe? I'm hoping the rumors are true about Google coming out with a new tab this fall, but I'd love to get mine working before then lol...
Hello, I have a huge problem with my Tab 4. As you can see in the video, my Tab 4 will not go to the start screen. I have tried booting into recovery mode and tried the options in there. I installed the stock ROM, but it didn't help. Please someone help me:crying:
sly742 said:
Hello, I have a huge problem with my Tab 4. As you can see in the video, my Tab 4 will not go to the start screen. I have tried booting into recovery mode and tried the options in there. I installed the stock ROM, but it didn't help. Please someone help me:crying:
Click to expand...
Click to collapse
Try samsung kies or download stock firmware and flash with odin
I have the exact same thing. I deleted android off of mine because I rooted it. I fd up after i rooted it doing something wrong. now I'm trying to get it to work again. I wiped mine (you may have to also) now I'm trying to find android 5.0.1 to load on it. I need help too. But I know some stuff about our tablet.
T530NU - Bootloop Freeze
Resurrecting this thread after over a year hoping someone is paying attention...
I have the same problem as well. I have downgraded from 5.0.2 to 4.4.2 hoping that would work. I have the exact same issue as seen in the video above. I flashed PACMAN custom ROM and GAPPS 6.0 nano last night and was able to get in and through setup, but the wifi will not work nor does it detect any nearby networks.
Looking for answers here... Corrupted partitions maybe? I have stable stock ROM's
Maybe sideload APK's to evaluate/fix the issue from the ui side - if any apps exist?
megamb11 said:
Resurrecting this thread after over a year hoping someone is paying attention...
I have the same problem as well. I have downgraded from 5.0.2 to 4.4.2 hoping that would work. I have the exact same issue as seen in the video above. I flashed PACMAN custom ROM and GAPPS 6.0 nano last night and was able to get in and through setup, but the wifi will not work nor does it detect any nearby networks.
Looking for answers here... Corrupted partitions maybe? I have stable stock ROM's
Maybe sideload APK's to evaluate/fix the issue from the ui side - if any apps exist?
Click to expand...
Click to collapse
Update:
Been working on this throughout the day. I have CM14.1 installed with GAPPS 7.1.
Ran system, data, and cache partitions through change (ext4 to exFAT to ext4) and repair in TWRP 3.1.0.
I am able to run through the boot up, but now the interface is crashing about 3 minutes in and rebooting with no variances in this process.
Still no wifi and no networks showing where I know they should be...
Corrupt Data and Cache Partitions Cannot be Fixed with e2fsck
Update:
Partition repair, while working, is not fully fixing the cache and data partitions, which I believe to be the issues. I am beginning to learn the Linux environment even more now as I learn how to fix this issue
# e2fsck /dev/block/platform/msm_sdcc.1/by-name/cache is returning a percentage that is non-contiguous for the cache partition
fdisk /dev/block/mmcblk0p24 did not seem to work
This may move beyond just this thread and into its own thread as it involves troubleshooting the Android OS in general.
To any devs out there that may view this, I am looking for some direction on how best to proceed. Next step would be to re-partition manually. If there are additional tools available to be able to further investigate the partitions then I would be happy to know what they are.
Thanks in advance for any help!
Update:
Cache and data do not seem to be the issue...
I am beginning to find a lot more info on this issue and wonder if the OTA update to the tab from KK to LP caused the issues that I am seeing - no wifi or BT. Still no stock firmware bootup though I am able to get in to the interface via custom ROM's.
Now dumping modem, efs, modemst1, modemst2, fsc, fsg, and backup partitions to view information in the files.
Update:
I hate problems that fix themselves!
I pulled APNHLOS, modem, efs, modemst1, modemst2, and boot partitions for further evaluation yesterday using the dd if= of= command - no results yet. However this morning I Odin-flashed stock 4.4.2 KK to see if I could pull something from logcat before it crashed. For whatever reason, I am now running stable stock ROM with TWRP and no SU binary installed - one problem just fixed itself. Still no wifi and BT yet, though.
I need help getting a logcat while my phone is shutting down and also while it is booting up.
Here is some history of my problems which will explain why I need to do this.
Note 3 sm-n900v
Currently running OF1 firmware and Alliance t-mobile rom
Rooted and unlocked bootloader TWRP recovery
I got this phone used for cheap and thought it would be an easy fix. I started with a clean odin of the stock OF1 firmware to put it in factory condition. Everything went great and had good signal and 4G LTE ran smooth and set up with no problems.
After the first time I rebooted the phone I had no signal. Checked About phone and my IMEI, baseband and serial number were gone.
I reflashed the phone in odin and everything was back. Another reboot and all is gone again.
I have tried different roms after rooting including some AOSP roms and always the same result.
I have checked to make sure that the phone wasen't a victim of the "NVbackup/restore" bomb and my NV partitions do not seem to be corrupted.
When I power off the phone it seems to take a long time to shut down (1-2 min.) so I suspect that something is being rewritten on the phone during a reboot. This is why I need to get the logcats so I can have some wizard/guru/hero/Android God read them for me and hopefully tell me what is happening to the phone and how to fix it.
I can work in ADB if someone would be kind enough to give me the commands needed to get the logs and where to post them or who to send them to for help.
I'm old but not stupid. Just an old fart that needs some help getting across the Android freeway.
Thanks in advance to anyone that can help.
Loaderboy
"got the phone for cheap" - did you call Verizon and inquire if the ESN was blacklisted?
If not, I would inquire before trying anything else.
(for shutdown; assumes you are rooted.)
Code:
adb shell
su
cd /data/local/tmp
cat > watcher.sh
#!/system/bin/sh
cd /data/local/tmp
logcat -c
logcat -v threadtime > watch_shutdown_logcat.txt 2>&1
^D
chmod 755 watcher.sh
./watcher.sh 2>>/dev/null &
exit
then reboot.
I know it's a pain in the butt to re-Odin the phone & re-root in order to run a single experiment, but you might also try the reboot cycle with the phone in airplane mode (or better yet in a location where you know you do not have a cell signal) to see if that has an effect.
Does the rooting process require a reboot? If so that would seem to be a chicken-and-egg problem - if your IMEI gets wiped on the first shutdown, then it would be hard to install a new ROM to find out whether it is carrier ROM software that is performing the changes.
Other possibilities: an intermittent hardware problem that is being mis-diagnosed as software behavior. If this were the case, occasionally the problem would appear even after a fresh Odin flash.
Other ideas include performing checksum (md5) signature comparisons on the stuff in /firmware and /firmware-modem before and after reboot to see if anything is changing, e.g.
find /firmware /firmware-modem -type f -exec md5sum {} \;
PS This advice doesn't mean I'm planning on helping you examine your logcats, but you should feel free to put them in a pastebin and provide the link here. You might want to scrub the file of any personal or device identifier information before you do that.
No the phone is not blacklisted, first thing I thought of. The problem happens on Verizon and Tmo roms alike.
The last time it lost the IMEI and baseband I got it back when I flashed Alliance rom but I havent rebooted since. The phone didn't lose root so I think I can experiment without odining the stock firmware and rerooting.
I will get the shutdown logcat and see if I can find anything before posting it.
Thanks so much for your quick reply.
The observation that it is ROM-independant is significant.
That would suggest that it is less likely to be due to a piece of application software unless all the ROMs carried the same application/code, or the functionality was coming from the TrustZone, or perhaps code in a kernel shared in common between ROMs exhibiting the behavior.
You seem to be suggesting that it can be corrected by simply flashing a new ROM. Normally that only involves the /system, /cache, and /data (when you wipe) partitions not the /firmware or /firmware-modem partitions.
It's just one hypothesis, but my money is on flaky hardware that causes a failed initialization during boot up. Evidence for that might be:
(1) boot the phone several times after you lose IMEI, both warm reboots as well as shutdown/boot and shutdown/battery pull&reinsert/boot. If it comes back up during any cycle... flaky hardware. (Note also that if you put the phone on the charger when it is "off" it actually performs a "silent boot"... I think the bootloader does this by providing the kernel with an alternate (skinny) ramdisk. In any event, many pieces of hardware could be fully powered up & kernel initialized when doing this, so potentially this could affect flaky hardware. Just be aware of it so you are correctly appraised of "how many time did I boot this thing?")
(2) Alternatively, NOT recovering service in a reproducible manner (e.g. flash & boot a ROM 4 or 5 times using the exact same procedure and one of those times service is not restored) also would be indicative of intermittent hardware troubles.
(3) if you have TWRP installed and the problem was due to some stateful behavior (e.g. something recorded into a file on the previous boot), performing a full wipe of /data might alter the behavior as that is the most likely place for it (esp. since you say that ROM flashing cures the problem). Try wiping & booting several times - does the problem come & go?
well I rebooted and lost signal. I then booted to TWRP and wiped data and still no signal.
I did this 3 times and no signal. Then I wiped dalvik /art cache and cache without wiping data and signal is back.
Getting closer. I will reboot to lose signal and then reboot to TWRP and wipe each one seperatly to see if I can narrow it down.
Stay tuned.
Wiped dalvik/art cache and signal is back. Tomorrow I will restore my stock backup and see if it works on that as well.
Thanks for giving me the tips on where to look. If it works on the stock rom I will then have to try to find out what is causing this to happen.
... and the result is?
.
bftb0 said:
... and the result is?
.
Click to expand...
Click to collapse
Flashed stock backup and everything was there. reboot and it's all gone. Boot to recovery and wipe dalvik cache and baseband IMEI etc. all back.
Sorry for the long break but spent the weekend moving a friend.
Sent from my SM-N910P using Tapatalk
loaderboy said:
Flashed stock backup and everything was there. reboot and it's all gone. Boot to recovery and wipe dalvik cache and baseband IMEI etc. all back.
Sorry for the long break but spent the weekend moving a friend.
Sent from my SM-N910P using Tapatalk
Click to expand...
Click to collapse
Looks like you have your work cut out for you. Somehow I doubt you are going to find something meaningful inside of /cache, but I'd look there first since that is likely to be the simplest in terms of effort.
I suppose you could try a binary division method of manually deleting half of the .dex files and the corresponding entries in places like
/data/system/packages.xml
/data/system/packages.list
/data/system/install
/data/system/users/0/package-restrictions.xml
/data/system/users/0/runtime-permissions.xml
and then iterating (the divide the right group by half) but thats gonna get tedious fast - and possibly just cause bootloops or hangs.
Frankly, I still think there is an underlying bit of flaky hardware - if the ESN was clean, what would be the point of software being intentionally coded to "turn off the phone" on an otherwise clean ESN device, and a completely vanilla ROM (i.e. no personalization by initialization of a Google account credential, no market apps, etc).
If you decide to use logcat and you discover that you need to launch on boot because the logs are rolling over before you can manually run a logcat (very likely because of the long Dalvik rebuild times), you will either have to choose a ROM which has a hook for auto-starting a script (e.g. CM13 userinit.sh files), or you have to re-pack the boot image to execute a one-shot service during late boot (customizing init.rc), making sure to put the logcat invocation into the background so the service doesn't block init. In both those cases, make sure you write the log to someplace like /data/local/tmp - you can't use /sdcard as the automounter tends to mount it quite late in the boot.
good luck
I had LineageOS 17.1 + TWRP running fine on my Galaxy S5 klte, then the glue on the top part of the screen came away and disconnected the screen while the phone was on. After that it would only boot to part way through the Lineage animation, dimming to low brightness in the middle of it and rebooting into recovery.
Wiping the cache in recovery did nothing, but wiping the data partition fixed it, so I guess the data partition became corrupted. Restoring the data partition from an old TWRP backup of the same install works too. The hardware and ROM seem fine.
I made a full backup of the bad install, so is there anything I could do to try to get that working again or diagnosing what happens at boot? Any cache/settings files I could try deleting from the image if that's possible? I did find stuff about getting the last kmsg output but that doesn't seem to work with this phone/Android build. I wish I'd though about running fsck on the partition before I wiped it. No idea if the screen thing is a red herring or not.