Database Info

Phone powers off after flashing CAF based ROMS no boot.

Hi guy,
I have been trying to figure this out for a while now and can't seam to figure it out. Everytime I flash a CAF based ROM after clicking reboot the phone turns off. During this time it is very hard to get the phone to turn back on. Holding the power button does not seam to do anything. I have to hold the power+volup+voldown for around 30 seconds let go and do it again in order to get back into recovery. I am not getting any errors at all when flashing. I really have no clue what it could be. I have tried every CAF based ROM I have come across here and they all do it. The only thing I can come up with is my phone has had the screen, camera, and battery replaced. Could one of these parts or another part be causing a problem that doesn't allow CAF based ROMS to work? I know its a long shot but thats all I can think of at the moment.
Right now I am working on trying to flash CyanogenMod from this thread. I have tried both version 13 and version 14 both have the same problem. This is what I have tried.
Flash HammerheadCAF reboot back into recovery
Flash bootloader&radio_HHZ20h+2.30.zip reboot to recovery
Flash cm-13.0-20161029-UNOFFICIAL-hammerheadcaf.zip
Flash opengapps
Flash SuperSu
Reboot
Black screen of death
What is wrong with this process? I have also tried the same process with cm-14.0-20161029-UNOFFICIAL-hammerheadcaf.zip. I am now going to try this same process with cm-14.1-20161029-UNOFFICIAL-hammerheadcaf.zip. I don't expect any difference though. Anyone have any suggestions?
Thanks,
Rocky
*****Update*****
I have tracked the problem down to CAF TWRP. I have formatted the phone which has removed everything except CAF TWRP and I am still getting the black screen of death situation. When the phone reboots it completely turns off. It will not respond unless I hold down power+volup+voldown for around 30 or 40 seconds. Then the phone will finally enter the bootloader. Are there any other recoveries that will flash CAF based ROMs? I don't know what else to do =(

Maybe don't flash supersu? Cm comes prerooted?

audit13 said:
Maybe don't flash supersu? Cm comes prerooted?
Click to expand...
Click to collapse
Thanks for your reply and time. I also tried flashing without SuperSU and it did the same thing. When I tapped reboot the phone would not turn on. I also tried just flashing the ROM and rebooting. The problem is with TWRP CAF because I have even formatted the phone so there was no ROM just TRWP CAF and when I tapped on reboot to recovery the phone just turned off. The power button wouldn't do anything. It would not even turn the phone on. The only thing I could do was hold the power+voldown+volup for 30 sec let go and press them again and go into bootloader.

Hey guys anyone else have any suggestions? I have tried sending a support ticket to twrp over a week ago. I haven't heard a word from them. I really want to use CAF ROMs

Hi!
I'm facing the same problem. I've been trying everything I can think of, and everything ended with a black screen when trying to boot:
Flashing stock again and then TWRP and CAF.
Flashing a lower version of TWRP (2.8.7.0) and then flashing CAF.
Flashing an AOSP version of CM, then TWRP for CAF and finally CAF.
Fixing permissions.
Changing filesystems to F2FS.
I tried to logcat, but adb logcat keeps waiting for the phone and it doesnt find anything.
Anybody has another idea of what could be happening or how to solve it?
Thanks!

I can flash caf, aswell as noncaf roms on my N5 just fine.
I used the CM14 darkrom CAF. Excellent performance, great battery life
i wiped the device in TWRP caf (Latest) (system,data,cache,dalvik0
Then i flashed the rom and the Darkrom gapps (use only those, as rom comes withouth a launcher. Pixwl launcher embeded into gapps package)
Wipe cahce/dalvik & reboot
It looped like: GOOGLElogo ,bootanimation ,self restart and it works perfectly fine since then
---------- Post added at 18:54 ---------- Previous post was at 18:53 ----------
I should also mention, that i use the european D821 model

I was beginning to wonder if it was just me. I felt like an ass for posting for help because I felt like it was my fault. I still have not gotten any response at all from twrp support. I really want to use car based Roms. I use to be able to when I first got the phone. Now I don't have a clue what the problem is. I am using the 820 USA model.
After doing a Google search for CAF TWRP no boot black screen and other combinations I have found posts around the web from people with the same issue. The only resolution was to revert to stock. I have sent TWRP support another email linking to this topic as well as contacted them on g+ hopefully we can get a resolution.

since i dont own the device.... no logs= we cant help you

Funny thing is twrp caf and non-caf are identical, the ONLY difference is that they are looking for a different device name when flashing. So I'd suggest to use the non-caf one, download any caf rom, edit the updater-script and replace every "hammerheadcaf" with "hammerhead" and it will flash just fine. If it really is just a twrp issue that will work. But I don't know why, I feel it's bound to be more than that...

I'm having this problem too, I can flash any non-CAF ROM and it will bootup fine, but any CAF rom will leave me in a black screen. Did you found any solution yet?

I have not been able to find a solution to the problem. TWERP tech support seams to be non existent. I have emailed them numerous times. They don't even take the time to say they will look into it =(

Dark_Eyes_ said:
Funny thing is twrp caf and non-caf are identical, the ONLY difference is that they are looking for a different device name when flashing. So I'd suggest to use the non-caf one, download any caf rom, edit the updater-script and replace every "hammerheadcaf" with "hammerhead" and it will flash just fine. If it really is just a twrp issue that will work. But I don't know why, I feel it's bound to be more than that...
Click to expand...
Click to collapse
What else could it be if we are able to flash absolutely anything else we want to flash except for a CAFE ROM?
I have never tried editting the updater script. Could you please explain how to do the things you described?

Ok I got an update. Today just for ****s and giggles I tried to flash the latest TWRP twrp-3.0.2-0-hammerhead.img on top of itself from inside TWRP using the image flashing process. I got the black screen I been getting that we are discussing here. Therefore, that tells me that the problem is not with TWRP CAF but with flash recovery's in TWRP. For some reason TWRP does not like that. Therefore, I am manually flashing the fallowing files the old fashion way by hand using the android sdk and adb.
1.) TWRP CAF
2.) The latest bootloader directly from the latest google factory image
3.) The latest radio directly from the latest google factory image
4.) Install the latest build of Dark ROM
I will report back with my findings.
Findings are epic fail. No boot, black screen of death.:crying: After holding down volup+voldown+power I am able to get back into recovery just like with flashing all the files through recovery when I first started. However, I can't get the damn thing to boot the ROM. I don't know what to think anymore. I think we just have to come to the conclusion that CAF based ROMs are out of the question for us :crying: :crying: :crying: When my son gets home and can hold the tablet while I operate the Nexus 5 maybe I will try to make a video of the problem. Hopefully this will help lead to a resolution.

Let me guess. All your phones have been repaired or are second-hand devices, aren't they?

experience7 said:
Let me guess. All your phones have been repaired or are second-hand devices, aren't they?
Click to expand...
Click to collapse
will a repaired device not work, mine has had the screen replaced. Nothing else just the screen.

experience7 said:
Let me guess. All your phones have been repaired or are second-hand devices, aren't they?
Click to expand...
Click to collapse
Yup, I have replaced the screen, why is that? Is it too much different than the original, shouldn't it work normally?

Not sure what's wrong with the hardware. No CAF for you guys, I'm sorry.

experience7 said:
Not sure what's wrong with the hardware. No CAF for you guys, I'm sorry.
Click to expand...
Click to collapse
Wait seriously? because i fixed my screen i am not able to use a caf rom on my device? That seems ridiculous, what would cause that to even be a thing? is there some sort of security flag it checks for?

Yeah I replaced the screen on mine too. Not sure how that plays a role. The only thing I can think of is unless there is a missing driver or something like that because our screens are different.
There's gotta be a way to fix this problem. I wish I knew how to build ROMs, kernels, and recoveries. I don't think anyone will go out of their way to fix a problem that doesn't directly affect them. So for me it is stock, rooted, with ElementalX till this pos croaks.

Not sure what the problem is. Fact is that your screen somehow differs from the 'original' one which causes CAF ROMs to blackscreen.
If you really, really want your phone to run CAF you have to provide a lot more information. You could try to get a running system and fetch some hardware information. Pretty sure there are apps on the Play Store that print hardware brands/model names, etc. Report your results and I'll use the same method to get mine. We should compare. Furthermore we'll need logs. Try to boot CAF. Of course it will blackscreen again but you can reboot to recovery and pull some logs. Maybe last_kmsg and dmesg where the latter one should be even more interesting.
And last but not least I'd like to tag @myfluxi here. Perhaps that's interesting for you...

The interesting story of how an OTA rendered my Z almost-useless

Just for background info, at the time it happened, my Z was running NPL25.86-30 from the following thread;
https://forum.xda-developers.com/moto-z/development/android-nougat-moto-z-versions-t3506342
It was running perfectly fine, then an OTA thing appeared. Well, I made the single big mistake of accepting it, and thus, it encountered an error and while the phone booted fine and even displayed the new build "NPLS-25.86-30-5", it started to randomly reboot when the phone either goes to sleep or when CPU loads are very low.
Well, I was distraught. The phone which was working perfectly fine just a few minutes ago was rendered almost useless as I had to keep turning it off after I used it to avoid it going into a reboot loop. So making calls was difficult enough as the phone would never receive a call as it would be endlessly rebooting anyway.
So, when I returned home, I fired up ADB, connected the Z in Fastboot mode and reflashed the NPL25.86-30 firmware from that link. For a while, it seemed to be fine, but then it started doing it again. I tried again and it still does so.
I was at a loss as I wasn't sure what else to do. Since the OTA update was there, I was afraid that the bootloader may have upgraded and causing me to lose my downgrade. However, when I used the command "fastboot boot xxx", I noticed the Marshmallow boot screen, indicating that the old bootloader was indeed intact and it hasn't changed.
It also happens that I kept the original firmware file which my phone came out of the box with. So I fired up RSDLite, put the entire .zip file in it (including GPT and bootloader) and flashed it right away. After it was done and I did a hasty setup, I left the phone alone to see if it would do so. Over an hour passed, and the phone never rebooted by itself, and would only do so if I was the one doing it.
So, there was light at the end of this very dark tunnel. Fired up ADB yet again and flashed the NPL25.86-30 firmware using the method that does not upgrade the bootloader. I also flashed TWRP and erfanoabdi's TurboZ kernel to disable forced-encryption and dm-verity, along with phh's Superuser for root access as SuperSU somehow does not install right even though the recovery says otherwise.
Booted up and it hasn't rebooted by itself until now. The only time it has rebooted is when I did it. It did necessitate a full data reset, but so far, it has been running well, with the OTA service fully disabled and the processor clocked to its Droid Edition levels.
Only issue I had with it is that the battery drain is a wee-bit high. Though this may be due to the process of installing and optimizing apps over time. If it all goes well, the battery drain should calm itself soon. As of right now, I've downclocked the processor and changed the governor to be as efficient as possible to reduce that battery drain until the phone is fully-set up. The other issue is that after a while, CPU-Z and AIDA64 fails to find the big cores, saying that they're either inactive or "sleeping", but Kernel Adiutor said otherwise. Other than that, I am enjoying it.
Also goes to show that if you have the MM bootloader, you should definitely keep it as it provides a very safe method of returning to a previous build with all your system files intact if anything breaks. It has proved to be extremely useful in this case.

As to the why it all happened,
Did you run the OTA with twrp installed, and/or any other system partition alterations?
Just curious, so others know why this happened to you and Van avoid it themselves. And with either of those things above, the OTA will fail, or worse like in your case.
OTA's are for stock systems, with stock recovery only.
Glad you got it sorted out though! :good:

Darth said:
As to the why it all happened,
Did you run the OTA with twrp installed, and/or any other system partition alterations?
Just curious, so others know why this happened to you and Van avoid it themselves. And with either of those things above, the OTA will fail, or worse like in your case.
OTA's are for stock systems, with stock recovery only.
Glad you got it sorted out though! :good:
Click to expand...
Click to collapse
Stock recovery.
I presume it's either because the build I ran was designed for a different region (same model code, though) or that the Marshmallow bootloader was incompatible with the OTA.
Regardless, it's been working fine for a bit, although one Busybox installer gave me a small scare when it said it was cleaning system/bin, although a later check found that it didn't actually do anything.
Just wanted to share my predicament.

(FIXED) Bootloader Locked but Device Won't Boot

I recently ran into the issue during custom rom work. I reflash the stock android ZIP, it starts booting, then I hard reset it with the power button and try to reach bootloader again. This, as it turns out, is terrible to do if you want a fast setup. The moment it starts and you reboot it, the boot image is corrupted (that's my guess) because escaping the boot screen during a clean flash bricks your phone. If you're reading this, it happened to you as well.
The answer is so flipping obvious and it took me an hour to figure it out - nowhere on the internet is there a "solution" for this problem, no matter how frequent it is. But there are lots of people who deal with this, whether still on their factory images (like the Pixel 3 EDL issue) or like me bouncing from custom to stock. So here's the answer:
ALL YOU HAVE TO DO IS SIDELOAD THE CURRENT SOFTWARE OTA OR A BETA OTA FROM ANOTHER FUTURE VERSION.
It doesn't recognize timestamps before your current software, so you'll need to assume you're on the latest of whatever you're on and do that. Future versions work as well, so if you wanted to reach 12 in one shot, your phone's bootloader would fully accept it as long as the file isn't corrupted. If you need a sideloading or flashing guide, here you go.
For me, I flashed the latest build of Android 11 (August patch) and rebooted during the boot up. What I did was download the OTA of the same exact file to my laptop, and entered adb sideload coral.xxx.x.zip. (The name of the file) It ran all the way through and it started up perfectly normal.
I hope this helps someone!
P.S. I don't have any pictures or tutorials, I only wrote this to help others understand what happened and how to fix it. Probably wouldn't have needed to say it if the forum for it existed.

Question Occasionally crash to "waiting to flash full ramdump"

Hi, sorry if this question was asked before by another user but my phone occasionally crashes to the waiting to flash full ramdump (or something of that sort) out of nowhere. After crashing, I could just force shut down the device using the volume keys and boot up normally again.
This only happens once or twice a week - my phone is unlocked and is sporting the latest kirasakura kernel.
Do you guys have any ideas on how to fix it?
Thanks in advance

Hello, I had same issue, it is caused by custom kernel, on .176 firmware both kernels listed on XDA are quite unstable. Just restore stock kernel by using payload dumper on firmware file and flashing boot.img, dtbo.img and vendor_boot.img using fastboot.
To keep root, patch boot.img with magisk before flashing.

vinotux said:
Hi, sorry if this question was asked before by another user but my phone occasionally crashes to the waiting to flash full ramdump (or something of that sort) out of nowhere. After crashing, I could just force shut down the device using the volume keys and boot up normally again.
This only happens once or twice a week - my phone is unlocked and is sporting the latest kirasakura kernel.
Do you guys have any ideas on how to fix it?
Thanks in advance
Click to expand...
Click to collapse
Did you flash the DLKM module?

MarekPietrzak said:
Hello, I had same issue, it is caused by custom kernel, on .176 firmware both kernels listed on XDA are quite unstable. Just restore stock kernel by using payload dumper on firmware file and flashing boot.img, dtbo.img and vendor_boot.img using fastboot.
To keep root, patch boot.img with magisk before flashing.
Click to expand...
Click to collapse
You probably shouldn't be starting rumors like that, especially without any legitimate proof. The reports are few and far between, but also addressed promptly. Neither of the kernels is "quite unstable" and the issue has happened on stock.

twistedumbrella said:
You probably shouldn't be starting rumors like that, especially without any legitimate proof. The reports are few and far between, but also addressed promptly. Neither of the kernels is "quite unstable" and the issue has happened on stock.
Click to expand...
Click to collapse
I don't intend to insult anyone, I just shared my personal experience, on previous firmware version both kernels worked fine and stable, but on .176 I had constant crashes with "waiting for flashing full ramdump" message. When I restored stock kernel, this issue no longer persisted. I will for sure try again custom kernel, but in two weeks or longer, as ROG phone 5 is my primary device and I need to stay in contact. I will try to reproduce this issue and grab logs. Now I can share my observation, that those crashes occurred when device was idle, and usually on charger.

JazonX said:
Did you flash the DLKM module?
Click to expand...
Click to collapse
Thanks for your response, do I need to? I flashed using FKM and not TWRP

vinotux said:
Thanks for your response, do I need to? I flashed using FKM and not TWRP
Click to expand...
Click to collapse
You honestly shouldn't need it at all anymore. I believe AnyKernel took the lead and fixed the issue, but it was only TWRP that needed it.
MarekPietrzak said:
I don't intend to insult anyone, I just shared my personal experience, on previous firmware version both kernels worked fine and stable, but on .176 I had constant crashes with "waiting for flashing full ramdump" message.
Click to expand...
Click to collapse
No worries. I was only making sure it was clear this was a recent issue and not an ongoing problem. Kirisakura spans a lot of devices and got the reports much later, so a slight delay in the fix should be expected.

twistedumbrella said:
You honestly shouldn't need it at all anymore. I believe AnyKernel took the lead and fixed the issue, but it was only TWRP that needed it.
No worries. I was only making sure it was clear this was a recent issue and not an ongoing problem. Kirisakura spans a lot of devices and got the reports much later, so a slight delay in the fix should be expected.
Click to expand...
Click to collapse
Great, I'll just reevaluate when the new update rolls out, thank you .

vinotux said:
Great, I'll just reevaluate when the new update rolls out, thank you .
Click to expand...
Click to collapse
Make sure to perform a backup of anything important, even if you are staying with stock. It appears the issue may go beyond something as simple as installing a custom kernel, assuming the issues reported on both are related.
Finding the common denominator, as they say, might find the root cause, but that is a pretty big task. It would also require more than one report and I only have the one.

twistedumbrella said:
Make sure to perform a backup of anything important, even if you are staying with stock. It appears the issue may go beyond something as simple as installing a custom kernel, assuming the issues reported on both are related.
Finding the common denominator, as they say, might find the root cause, but that is a pretty big task. It would also require more than one report and I only have the one.
Click to expand...
Click to collapse
Actually I flashed your kernel and it's been smooth sailing since then. I'm a little too busy to diagnose the root cause of the problem .

vinotux said:
Actually I flashed your kernel and it's been smooth sailing since then. I'm a little too busy to diagnose the root cause of the problem .
Click to expand...
Click to collapse
Fair enough. It shouldn't be on you to do it anyway. With any luck, i'll have debugging sorted out before the end of the weekend with proper instructions to avoid all the guesswork.
Asus Proprietary Logs
In trying to debug kernels, I realized that Asus has rerouted the location of some of the more important logs to make them "easily" accessible. Disclaimer: This is not a complete list of every file included, but lists the more "useful"...
forum.xda-developers.com

An error happens, the kernel logs the issue, the device reboots. This is how things are supposed to work. When disabling debugging, an error happens and the device reboots. The logging step is skipped, but life continues.
The problem is when debugging is partially disabled, but still attempting to write. This is basically why there is a "waiting for ramdump" message. It is waiting for the logging to complete to proceed to the next step.
Asus Power Debug: guard debugging so it can be disabled · freak07/[email protected]
Contribute to freak07/Kirisakura_ANAKIN_ROG5 development by creating an account on GitHub.
github.com
This commit set the stage for a future break, which happened in the .176 update when printk_buffer_rebase replaced get_last_shutdown_log.

Hi, just a quick update.
I had been experiencing major issues and the waiting to flash full ramdump debacle had gotten extremely frightening. The phone wouldn't recognize the IMEI of the device, wifi wouldn't work, etc. The error happened multiple times a day. I took it to ASUS and they basically told me to f off due to my phone being unlocked.
As a last resort, I flashed the .151 RAW firmware and I swear all of the problems vanished. If I was a betting man, I'd say that the .176 update caused all of the problems since I've used the device for a week now without any problems thus far.
Major thanks to @twistedumbrella and others for replying to this thread.

I don't doubt you are right about that. 188 improves things a bit, but they definitely broke something significant in 176. I have never crashed as much as on that build.

Question "Your device is corrupt" error before successful boot (Android 13 May update rooted with Magisk)

Hey all, I'm not new to this, but I'm looking for some guidance and explanation of the root cause so I don't break my phone worse than it is.
I bought a Pixel 6a last fall, and I have been using it non-rooted since. I have accepted each OTA update since Android 13 was released and as of today I am running on TQ2A.230505.002.
I took the OTA update for May 2023 as soon as it was released before rooting. After it successfully installed, I downloaded the matching factory image zip and extracted the boot.img from the ROM, patched it with Magisk, and then flashed by doing fastboot flash boot magiskboot.img.
It was working fine for a few days, until today when my phone reboot and I was greeted with the "Your device is corrupt" message. If I continue, the phone boots successfully and it works like normal. Magisk says it is loaded and modules are active.
I have reboot my phone several times since I rooted it, and I never received this error. However, the last time I reboot before I received this error was Sunday night. I have not installed any apps since then.
Looking around on this forum and others, I have seen posts from other users who got this error, but their situations are different. In those cases, they received the message only after accepting an OTA on a rooted device or got stuck in a boot loop, but neither of those scenarios apply to me. The solutions in other threads also seem to be a mixed bag of results, so I'm hesitant to do anything until I understand the root cause and ask for guidance.
Since I am unlocked and booting, my hope is that it should be easily recoverable. However, what could cause it to suddenly become "corrupt", and how would I diagnose or remediate the issue with minimal disruption or risk to data? My main concerns at this point are not knowing how it got into this state, and how to quickly recover from it if it happens again.
---- Edit below with more info ----
I found another user with a very similar issue from a month ago. While the issue seems to have been inflicted differently, their symptoms are very similar. The suggested solution is linked here: https://forum.xda-developers.com/t/your-device-is-corrupted-message-on-bootup.4578141/#post-88446647
The other post states the issue is caused by "the bootloader is looking for a new/updated OS without corruption errors so it will go back to restart mode rather than being stuck in the RED eio mode which displays that message."
Since my phone was working, what corruption could I have experienced over the past two days of regular usage? I did not install any updates or make any changes that failed.
Also, what would be the recommended solution in my case? Should I try flashing an older boot.img and then reflash the newest? Or should I do "fastboot --disable verity flash vbmeta vbmeta.img"? Are there any risks with either approach?

Your bootloader is unlocked, hence the message.

dexlemaffo said:
Your bootloader is unlocked, hence the message.
Click to expand...
Click to collapse
This is not the "your bootloader is unlocked" warning. This is the eio message saying the system is corrupt and requires manual intervention to boot.
After doing a bit more research and learning more about the "eio" mode that it was stuck in, I decided to take a stab at it.
Since I have the May update installed, I downloaded the April factory image. I also downloaded platform-tools r33.0.3 because I read there was mixed results with the latest version.
I extracted the boot.img from the bluejay-tq2a.230405.003.e1 April image and flashed it to my phone with fastboot. I then reboot the device. It failed to boot, as expected. However, I immediately noticed the error was gone and I only had the regular unlocked bootloader warning.
I boot into fastboot again and flashed the boot.img from the bluejay-tq2a.230505.002 May image matching my system version. After it flashed successfully, I reboot and the error did not return.
Edit:
I proceeded with rooting again. This time, I did "fastboot boot boot-magisk.img" and flashed from Magisk instead of from fastboot, though I doubt there is any difference.
It reboot successfully. I am back to being rooted without any error message and without any factory reset.
I still don't know what would have caused the bootloader to think there was corruption after it was working for several days. Can anyone reading this can provide some insight?
This whole issue has me very uneasy. I'm worried something else could be wrong - whether it's a bug with Android, or a hardware fault, or a bug in Magisk.

I'm wondering if I should be concerned.
Today, when my phone reboot, it was sudden. I did not initiate the reboot. I thought it was a benign crash as I have experienced many times before. However that was when I saw the "your device is corrupt" message.
I'm reading up on dm-verity and the dm-verity driver here: https://source.android.com/docs/security/features/verifiedboot/dm-verity
I suspect the dm-verity driver is used to hash and verify the system partitions on the fly? If so, could it be that when I was using my phone, it was trying to access some data and the hash failed, the signature mismatched, and it triggered the bootloader to mark the system as corrupt?
If that is what happened, is that cause for concern? Would that be the result of actual system file corruption or bad NAND? Or is it some bizarre Android glitch when running rooted?

Youll likely need to do a factory reset to get rid of that message.

That is incorrect. Based on the other reports of users with the same issue, this is a bootloader message and a factory reset has nothing to do with it. Additionally installing a factory image and wiping the phone would not get rid of the image either. Only an upgrade can supposedly remove the message, unless it is caused by something else.

He said it's the device is corrupt message, not the normal unlocked bootloader one.

afaik thats a bug in Android Verified Boot.
what you did is exactly the "normal" method to solve it, e.g. flash boot.img of the prior version, try to reboot and then flash the correct version again.