Database Develop

Phone won't boot after flashing latest November NBD91P image

Phone happily running 7.0.0 (NBD90Z, Oct 2016)
Running system less super su SR3 and Franco #57
Downloaded and fast boot flashed the latest November update from PC.
Only flashed updated bootloader and system image from 7.0.0 (NBD91P, Nov 2016)
Restarted Phone and it loops at boot animation, left for twenty minutes, no progress, so rebooted back to recovery and tried wiping, cache, dalvik and art cache, and restarted again still no difference, looped at boot animation again for twenty minutes.
So rebooted to recovery and restored October backup.
Was anyone else and to fast boot flash latest factory system image and boot their phone without any issues?
Is a full wipe really necessary?
Any one?
Sent from my Shamu using Tapatalk

ben_pyett said:
Phone happily running 7.0.0 (NBD90Z, Oct 2016)
Running system less super su SR3 and Franco #57
Downloaded and fast boot flashed the latest November update from PC.
Only flashed updated bootloader and system image from 7.0.0 (NBD91P, Nov 2016)
Restarted Phone and it loops at boot animation, left for twenty minutes, no progress, so rebooted back to recovery and tried wiping, cache, dalvik and art cache, and restarted again still no difference, looped at boot animation again for twenty minutes.
So rebooted to recovery and restored October backup.
Was anyone else and to fast boot flash latest factory system image and boot their phone without any issues?
Is a full wipe really necessary?
Any one?
Sent from my Shamu using Tapatalk
Click to expand...
Click to collapse
I flashed NBD91P without a full wipe and my phone booted without any issues. However I have not been able to get su SR2 or su SR3 to work with either NBD90Z or NBD91P. SR1 works without any issues.

I flashed bootloader, boot and system without a problem. Also using FK, but have magisk+phh root.
I've seen a few people mentioning having problems with SuperSU 2.78 SR2 and SR3 and the latest update (NBD91P)

"Only flashed updated bootloader and system image"
I'm genuinely puzzled as to why people aren't using the OTA sideload method, which is incredibly simple and leaves your data and settings totally intact.
The quote above makes me think "You did half a job and now wonder why your phone won't work...?"

dahawthorne said:
I'm genuinely puzzled as to why people aren't using the OTA sideload method, which is incredibly simple and leaves your data and settings totally intact.
The quote above makes me think "You did half a job and now wonder why your phone won't work...?"
Click to expand...
Click to collapse
You didn't read the post completely, as my phone is working as I always make the precaution of taking a backup and simply restored to it.
I didn't think ota method was possible if you had custom recovery?
Using the method I've described also leaves data and settings in tact.
I didn't run the flash all scripts.
Thanks
Sent from my Shamu using Tapatalk

No offence intended. I have never (touch wood) had any serious problems with my many upgrades on many devices. As you did, I always have a backup in case it goes wrong. In fact I even have multiple backups on my laptop in case the latest one doesn't work.
I've use the OTA sideload method a dozen times now on all my rooted Nexus devices. All of them as standard have TWRP & root (either doitright's or Chainfire's), and the OTA just slides right in there regardless. No problems at all. When it's installed (which takes about five minutes) I have to reroot - I can't remember if I've had to reinstall TWRP, though on a number of occasions I've just reinstalled it anyway without bothering to check if it was already still there.
So in summary the OTA sideload works for rooted/TWRPed devices, doesn't lose anything, and is far simpler and safer than running separate partition flashes. Give it a go and I guarantee you'll never do it the old way again.

dahawthorne said:
No offence intended. I have never (touch wood) had any serious problems with my many upgrades on many devices. As you did, I always have a backup in case it goes wrong. In fact I even have multiple backups on my laptop in case the latest one doesn't work.
I've use the OTA sideload method a dozen times now on all my rooted Nexus devices. All of them as standard have TWRP & root (either doitright's or Chainfire's), and the OTA just slides right in there regardless. No problems at all. When it's installed (which takes about five minutes) I have to reroot - I can't remember if I've had to reinstall TWRP, though on a number of occasions I've just reinstalled it anyway without bothering to check if it was already still there.
So in summary the OTA sideload works for rooted/TWRPed devices, doesn't lose anything, and is far simpler and safer than running separate partition flashes. Give it a go and I guarantee you'll never do it the old way again.
Click to expand...
Click to collapse
Do you change, or alter you system partition, ie remove application or add some.
I'm asking if an ota will apply over the top of an altered system?
If so I'll try it once I've finished work.
Although will also rule out the version of super su first.
Sent from my Shamu using Tapatalk

I change nothing. My N6 is rooted and TWRPed and I just connect to the computer and use ADB to sideload the OTA. It says "flashing unconditionally" so I'm guessing (I'm just an end-user, not a dev) that the OTA just wipes the old ROM and overwrites it, but doesn't touch the data partition. Since the system partition is replaced, root disappears with it, but I'm not sure if it touches TWRP - as I said, I just reinstall it anyway each time and then use it to flash SuperSU.
Give it a go - you'll like it...
P.S. I understand that the OTA has some sort of internal checksum to verify the package integrity, but I always double-check my download with Checksum Utility:
https://raylin.wordpress.com/downloads/md5-sha-1-checksum-utility/

dahawthorne said:
I change nothing. My N6 is rooted and TWRPed and I just connect to the computer and use ADB to sideload the OTA. It says "flashing unconditionally" so I'm guessing (I'm just an end-user, not a dev) that the OTA just wipes the old ROM and overwrites it, but doesn't touch the data partition. Since the system partition is replaced, root disappears with it, but I'm not sure if it touches TWRP - as I said, I just reinstall it anyway each time and then use it to flash SuperSU.
Give it a go - you'll like it...
P.S. I understand that the OTA has some sort of internal checksum to verify the package integrity, but I always double-check my download with Checksum Utility:
https://raylin.wordpress.com/downloads/md5-sha-1-checksum-utility/
Click to expand...
Click to collapse
So flashed, ota through flash fire, worked as described.
As expected phone booted, with stock kernel, recovery and no root.
So rebooted to bootloader and had to re fast boot flash twrp recovery.
But then flashed systemless super su and Franco kernel, phone no longer boots.
Restored backup as ran out of time.
Will try again tonight with our systemless, which root version and methods are you using?
I'll try just kernel and then just root to see which it is that's causing the problem
Progress.
Although to be honest, I'm still of the opinion that flashing just system partition is a far simpler, process then ota.
This is the first time in a a good few years and multiple nexus/android versions, where I've ever had an issue with this process. (And I've had N4, N5 and N6)
Anyone?
Thanks
Sent from my Shamu using Tapatalk

Maybe you're trying too much all at once? I installed the OTA, TWRP and SuperSU 2.78 R3 with no problems - I have tried a couple of custom kernels but saw no appreciable difference, so decided that I'd avoid the risk of tinkering with stuff I don't understand.
Maybe there's some incompatibility with the Franco kernel? I know that SuperSU performs some processing on the kernel - it shows in the installation dialogue.

The more Google locks down android the harder it will be so people need to make a choice and live with it. Either you want the pointless OTA or you are gonna use a custom set up. Not flashing an update properly and then posting a thread about it only makes developers laugh.

zelendel said:
The more Google locks down android the harder it will be so people need to make a choice and live with it. Either you want the pointless OTA or you are gonna use a custom set up. Not flashing an update properly and then posting a thread about it only makes developers laugh.
Click to expand...
Click to collapse
Why do you say he didn't flash the update properly? I thought the only difference between NBD90Z and NBD91P was the bootloader and system images. There was no new recovery, radio, etc... included in that release. So what's the harm in only updating the bootloader/system partitions?
If you did it the "right way" I guess that would be running the flash-all.bat file in the folder. All that does is flash all the partitions (which is dumb because you're overwriting the same partitions which is completely unnecessary if you already have them) and wipe userdata. With his method userdata would've stayed intact.
Please note I never do this method, I'm a custom ROM man thru and thru. Whether it's Dirty Unicorns, AOSiP, OctOS, etc... I never run factory system images because even though with GravityBox you can get a lot of customization, I still prefer CMTE over Substratum/OMS. No way to get CMTE in stock firmware.

dahawthorne said:
Maybe you're trying too much all at once? I installed the OTA, TWRP and SuperSU 2.78 R3 with no problems - I have tried a couple of custom kernels but saw no appreciable difference, so decided that I'd avoid the risk of tinkering with stuff I don't understand.
Maybe there's some incompatibility with the Franco kernel? I know that SuperSU performs some processing on the kernel - it shows in the installation dialogue.
Click to expand...
Click to collapse
Finally managed it.
Fastboot Flashed system
Fastboot Flashed stock boot
Went in to recovery
Flashed Franco
Booted rom
Went back to recovery
Flashed update-unSU (unsure is this stage is needed, but was taking no chances)
Flashed super su
Was finally able to boot rom
Seems combination of super su and Franco wouldn't work in single flash for me. Needed clean reboot between each.
Although I still believe that fast boot flash system is easiest method rather than ota, as doesn't affect recovery or boot partitions and you stay in control, each to their own.
This is the first time I've encountered any issues with this method.
Comments suggesting I didn't do it properly without highlighting what, if anything I did wrong or without adding any positive feedback are worthless.
Thanks for input and suggestions.
Sent from my Nexus 6 using Tapatalk

I had very similar issues. I've been updating this phone monthly since day 1 without issue but with the NBD91P update, I got the same boot loop even with the stock kernel. My device is also encrypted.
After I booted back to the bootloader I noticed that TWRP was gone. I found that very odd. It was like the system image was trying to write over it. Not sure though, but I do know that I had to re-flash TWRP (I've had the same version, which is also the latest one, for months) after every boot loop.
I kept re-flashing and trying different versions of the systemless versions of SuperSU but none of them worked. Got stuck in the same boot loop everytime.
I finally re-flashed everything except for SuperSU and stock NBD91P booted up fine without root.

I'm also having the same issue. I can't even flash SR1. Any update on this?

I can't not boot the NBD91P factory image if I have any layers installed. Removing that overlay folder via TWRP is the only way to make it boot again.

LordDeath said:
I can't not boot the NBD91P factory image if I have any layers installed. Removing that overlay folder via TWRP is the only way to make it boot again.
Click to expand...
Click to collapse
There is a bug in this update which causes a bootloop if the system is themed. Restore to NBD90Z.

msaitta said:
I had very similar issues. I've been updating this phone monthly since day 1 without issue but with the NBD91P update, I got the same boot loop even with the stock kernel. My device is also encrypted.
After I booted back to the bootloader I noticed that TWRP was gone. I found that very odd. It was like the system image was trying to write over it. Not sure though, but I do know that I had to re-flash TWRP (I've had the same version, which is also the latest one, for months) after every boot loop.
I kept re-flashing and trying different versions of the systemless versions of SuperSU but none of them worked. Got stuck in the same boot loop everytime.
I finally re-flashed everything except for SuperSU and stock NBD91P booted up fine without root.
Click to expand...
Click to collapse
collinjames said:
I'm also having the same issue. I can't even flash SR1. Any update on this?
Click to expand...
Click to collapse
LordDeath said:
I can't not boot the NBD91P factory image if I have any layers installed. Removing that overlay folder via TWRP is the only way to make it boot again.
Click to expand...
Click to collapse
I was able to get over my own original problem using the process listed a few posts above, in my previous comment.
Even though it took several attempts to determine a working sequence. Did you try the process which worked for me on your devices?
Strephon Alkhalikoi said:
There is a bug in this update which causes a bootloop if the system is themed. Restore to NBD90Z.
Click to expand...
Click to collapse
Can't comment as my system wasn't themed.
Does the boot loop occur, if you, remove your themes then upgrade to latest image, reboot it and finally reapply your layers?
Sent from my Nexus 6 using Tapatalk

Dopamin3 said:
Why do you say he didn't flash the update properly? I thought the only difference between NBD90Z and NBD91P was the bootloader and system images. There was no new recovery, radio, etc... included in that release. So what's the harm in only updating the bootloader/system partitions?
Click to expand...
Click to collapse
He said, quote:
Only flashed updated bootloader and system image from 7.0.0 (NBD91P, Nov 2016)
Click to expand...
Click to collapse
Unless you have the diffs from the Android git, you can't decide if flashing boot necessary or not. And even then you can decide wrong.
The whole package is: bootloader, radio, boot, system, (vendor in case of the 6P), recovery, and the clutter.
You should skip data, and shouldn't bother with the cache partition, but it's a good idea clearing it after flashing a new system. You can always check if the bootloader and radio have changed, you can diff them if you don't believe the version numbers.
That leaves boot and system, you should always flash both, even if it goes by the nuisance of re-rooting.
Also if you're unencypted, as I am, then after flashing boot, you should not reboot without flashing a root that deals with it.
(But making an unencrypted and verity-less boot is five minutes tops, by the way)

Strephon Alkhalikoi said:
There is a bug in this update which causes a bootloop if the system is themed. Restore to NBD90Z.
Click to expand...
Click to collapse
Having the lastest security fixes is more important than themes.

Bootable(only) TWRP development

Our phone needs a bootable only TWRP, this is a fact.
This is because of the a/b partitioning but, more, since of the "new" recovery-in-boot.IMG design which links kernel & recovery presence in an unwanted way...
And a bootable TWRP is the "official solution" developed by TWRP Team for Pixel 2/2 XL - the more similar device up to date - to overcome this issue in better way. I fully agree with their solution and I had thought of it even before of their official release...
A LOT of development has been done on this phone during only last month, better installable TWRP, better kernels, better installation methods developed for them, both for first install and for upgrade too, BUT the lack of a boot-only TWRP, something easily (& ever...) accessible with a simple fastboot boot twrpboot.img command is every day more evident...
For some reasons this has been achieved (even if still with limitations...) on Pixels (with available sources obviously...) but, to date, not for our device...
I would like this thread will become the reference thread to all which would want to contribute on this development, a place to report achieved results and faced issues so that others could try to help & overcome them...
We still have a restricted team of developers, but most of them are *great* on their work... I'm sure that only with a bit more teamed up work, this is a result we could achieve in weeks... probably before Christmas!
So, just to start, everyone which has tried to develop (or study...) this, could report what type of issues has faced to date...

I will still have twrp on my boot image. When I was testing kernels without twrp and I got a horrid kernel panic, stock recovery just wiped the device rebooted, wiped, repeat. When I had a bad kernel panic alpha testing on twrp, it would just boot to twrp in tact then I could flash the old kernel. If everything was too messed up, just reflash twrp. All kernels I have made besides the ones that gave those issues work perfect in twrp. Even the ones where bogoMIPS freq was used instead of our frequencies. (38.0 MHz). I like the idea of not having to hook my device up to a computer to boot into recovery.

Uzephi said:
I will still have twrp on my boot image. When I was testing kernels without twrp and I got a horrid kernel panic, stock recovery just wiped the device rebooted, wiped, repeat. When I had a bad kernel panic alpha testing on twrp, it would just boot to twrp in tact then I could flash the old kernel. If everything was too messed up, just reflash twrp. All kernels I have made besides the ones that gave those issues work perfect in twrp. Even the ones where bogoMIPS freq was used instead of our frequencies. (38.0 MHz). I like the idea of not having to hook my device up to a computer to boot into recovery.
Click to expand...
Click to collapse
Yes, I understand this, BUT there are a lot of other scenarios where having a bootable TWRP could save the day and/or at least make things simpler....
On the other hand, you are the first developer I know who is quite ever going without root!
(So you can't be taken as the "average user"... )

enetec said:
Yes, I understand this, BUT there are a lot of other scenarios where having a bootable TWRP could save the day and/or at least make things simpler....
On the other hand, you are the first developer I know who is quite ever going without root!
(So you can't be taken as the "average user"... )
Click to expand...
Click to collapse
I am confused...(I am I am long time enthusiast, pls forgive my naivety!)
I can reboot into twrp without issue using current method in this forum. Is "bootable twrp" referencing where / how twrp is implemented on this device? What are we missing as users and fans of all the great room devs out there by using our current method?
Ty for any insights in advance.

3's&7's said:
I am confused...(I am I am long time enthusiast, pls forgive my naivety!)
I can reboot into twrp without issue using current method in this forum. Is "bootable twrp" referencing where / how twrp is implemented on this device? What are we missing as users and fans of all the great room devs out there by using our current method?
Ty for any insights in advance.
Click to expand...
Click to collapse
The bootable refers to the command fastboot boot boot_a your-filename.img or fastboot boot boot_b your-filename.img . For the Moto Z2 Force, it has to be compiled differently than a boot image intended to be flashed as with the command fastboot flash boot_a your-filename.img , or fastboot flash boot_b your-filename.img . The reason it now has to be compiled differently is that our boot image is combined with recovery. If you try to fastboot boot a fastboot flash type, it would boot normally into Android OS--if all went OK. If you fastboot flash flashed a fastboot boot type, the device would boot into recovery instead of normal Android OS. Both fastboot boot and normal boot result in the kernel and ramdisk being written to RAM--to volatile memory; the difference is whether the data originally came from the device's non-volatile storage or external PC via USB-C cable.
Alternatively, there are two main forms of zip installers for a combined boot image, which are intended to be flashed inside TWRP or an apk like FlashFire (FlashFire does not play nice with already Magisk rooted Z2 Force, in my experience): a zip flash that flashes the entire boot.img (ramdisk + kernel), or a zip flash that only replaces half of the boot image (the ramdisk). For combined boot images, the ramdisk-only type that does not replace kernel is the more common of the two flash zip types on the site TWRP.me . In fact, I have never seen an official installer that also replaced boot image kernel on the official site.
As mentioned above, the fastboot boot type is not meant to be fastboot flash flashed; rather, it is primarily meant to be a platform utilized to flash the TWRP zip installer. You will see some devices on TWRP.me that have both fastboot boot type and zip flash type, and the aforementioned technique is why both are provided. Take a look at Pixel 2 XL (codenamed Taimen) on TWRP.me, and you'll see this method supported.

@jhofseth .... I could never explain it in a better way! :silly::good:

To come back IT... @jhofseth I know you have studied a lot this thing in these weeks, so I have a question for you...
If you take a boot.img containing a TWRP recovery like one we already have, and try a fastboot boot TWRP.IMG it should boot to its included kernel and then to system (if possible...), right?
This way we can test a new kernel without flashing it but it isn't our goal...
Well, when already flashed on phone we can choose between reboot to kernel/system or TWRP by adb commands or by extensions like Gravity Box...
Is it so hard/possible/thinkable to modify one of our boot.img so that it is in some way "forced" to boot to its TWRP in any case?
(and so even when loaded with a fastboot boot command...)

enetec said:
To come back IT... @jhofseth I know you have studied a lot this thing in these weeks, so I have a question for you...
If you take a boot.img containing a TWRP recovery like one we already have, and try a fastboot boot TWRP.IMG it should boot to its included kernel and then to system (if possible...), right?
This way we can test a new kernel without flashing it but it isn't our goal...
Well, when already flashed on phone we can choose between reboot to kernel/system or TWRP by adb commands or by extensions like Gravity Box...
Is it so hard/possible/thinkable to modify one of our boot.img so that it is in some way "forced" to boot to its TWRP in any case?
(and so even when loaded with a fastboot boot command...)
Click to expand...
Click to collapse
I would work on this if someone explains in detail why our current setup is an issue. I have ran into plenty of kernel issues when building bad kernels and twrp as recovery was better than stock recovery (as stated above). Please, I want this if there is a real reason for it. Our stock recovery just factory resets the device, so a recovery with other options is kinda nice.
Temp booting a kernel: use AIK and inject kernel into a boot image.
New TWRP update, just flash the boot image (which might have new boot image as well) and just reflash kernel. It is better than needing to hook the phone up to a PC every time you want to boot TWRP...

enetec said:
To come back IT... @jhofseth I know you have studied a lot this thing in these weeks, so I have a question for you...
If you take a boot.img containing a TWRP recovery like one we already have, and try a fastboot boot TWRP.IMG it should boot to its included kernel and then to system (if possible...), right?
This way we can test a new kernel without flashing it but it isn't our goal...
Well, when already flashed on phone we can choose between reboot to kernel/system or TWRP by adb commands or by extensions like Gravity Box...
Is it so hard/possible/thinkable to modify one of our boot.img so that it is in some way "forced" to boot to its TWRP in any case?
(and so even when loaded with a fastboot boot command...)
Click to expand...
Click to collapse
Yeah, that is one way to test, but sometimes that will fail even when the kernel works. For example, sometimes if you fastboot flash, sometimes you also have to flash latest Magisk again right away in TWRP, or it won't boot into Android OS. That would be impossible with fastboot boot (i.e., unless you patched boot image first with Magisk manager apk, or some other tool), because you would be unable to flash latest Magisk (or SuperSU 2.82 beta SR5). So, sometimes fastboot boot would fail to normally boot into Android OS--even though the kernel may be completely OK.

Uzephi said:
I would work on this if someone explains in detail why our current setup is an issue. I have ran into plenty of kernel issues when building bad kernels and twrp as recovery was better than stock recovery (as stated above). Please, I want this if there is a real reason for it. Our stock recovery just factory resets the device, so a recovery with other options is kinda nice.
Click to expand...
Click to collapse
There are plenty of scenarios where a bootable TWRP could be hassle saving / needed BUT you ask for a single one and I'll give you one... Or two! :laugh:
I want to be free to install the kernel I want with TWRP version I want.
Now this is not possible (if not with weird/tricking installations! ).
E.g.: let's imagine to want to install latest *stock* kernel with latest TWRP.
I have kernel, I have TWRP flashable zips ( @jhofseth made some which are fantastic...) BUT no (simple) way to merge them.
More: as you like to have tweaked kernel BUT without root, there is plenty of people who like to not have TWRP flashed on their systems BUT still being able to make backups and/or flash zips... (e.g. we have already seen some incompatibility between CF-Root and TWRP in past...) and/or remain free to take OTAs... & so on...
I could continue for hours, but these are already valid reasons IMHO...
Pixel 2 developers are not stupid... they have choosed this solution for valid reasons...

enetec said:
There are plenty of scenarios where a bootable TWRP could be hassle saving / needed BUT you ask for a single one and I'll give you one... Or two! :laugh:
I want to be free to install the kernel I want with TWRP version I want.
Now this is not possible (if not with weird/tricking installations! ).
E.g.: let's imagine to want to install latest *stock* kernel with latest TWRP.
I have kernel, I have TWRP flashable zips (@jhofseth made some which are fantastic...) BUT no (simple) way to merge them.
More: as you like to have tweaked kernel BUT without root, there is plenty of people who like to not have TWRP flashed on their systems BUT still being able to make backups and/or flash zips... (e.g. we have already seen some incompatibility between CF-Root and TWRP in past...) and/or remain free to take OTAs... & so on...
I could continue for hours, but these are already valid reasons IMHO...
Pixel 2 developers are not stupid... they have choosed this solution for valid reasons...
Click to expand...
Click to collapse
Answer (I have done this before I flashed TWRP and it worked wonders): root a boot image, go into system, adb shell, su, dd if=/dev/block/sde17(sdf17 for slot B) of=/sdcard/boot.img You now have a rooted bootable image, return to stock image. now you can use Flash Fire to make backups and flash stuff....
You can flash any kernel to TWRP. you want the stock kernel to flash? I can make a flashable zip with the stock kernel by Motorola if needed. It isn't hard tbh...

jhofseth said:
Yeah, that is one way to test, but sometimes that will fail even when the kernel works. For example, sometimes if you fastboot flash, sometimes you also have to flash latest Magisk again right away in TWRP, or it won't boot into Android OS. That would be impossible with fastboot boot, because you would be unable to flash latest Magisk (or SuperSU 2.82 beta SR5).
Click to expand...
Click to collapse
Why do you think a "booted" TWRP wouldn't be able to correctly flash zips?
I don't see reasons for this...
jhofseth said:
...
So, sometimes fastboot boot would fail to normally boot into Android OS--even though the kernel may be completely OK.
Click to expand...
Click to collapse
In fact I wrote "if possible"... BUT anyway this is of no interest. We *only* need to boot to TWRP, we are not interested in boot to an "unflashed kernel" if you understand what I mean...
We have only to force it to boot *ever* in TWRP. Kernel parts not used by TWRP (if some are needed on our phone, like some Mediatek devices need...) could be omitted at all (as done on bootable TWRP for Pixels2 if I don't go wrong...).

Uzephi said:
Answer (I have done this before I flashed TWRP and it worked wonders): root a boot image, go into system, adb shell, su, dd if=/dev/block/sde17(sdf17 for slot B) of=/sdcard/boot.img You now have a rooted bootable image, return to stock image. now you can use Flash Fire to make backups and flash stuff....
You can flash any kernel to TWRP. you want the stock kernel to flash? I can make a flashable zip with the stock kernel by Motorola if needed. It isn't hard tbh...
Click to expand...
Click to collapse
This are exactly the *weird/tricking* solutions I was talkin'about...
(Edit: let me add I don't like this a bit... Root how? Command could be mistyped & flashfire for backups is an orrible & unsafe solution... Just imagine do all this with valuable data in danger... )
All is possible. BUT these are NOT solutions for average user. And every single one requires a different solution/set of commands.
This is not for average user. I repeat it.
You & @johfseth are *NOT* average users... you are fu**ing good developers* and can't evaluate all scenarios with your (advanced) skills & capabilities...

enetec said:
All is possible. BUT these are NOT solutions for average user. And every single one requires a different solution/set of commands.
Click to expand...
Click to collapse
I have offered to give a bootable rooted image to other people in my kernel thread. The thing is, if ANYTHING is edited, OTA won't work, so bootable TWRP won't be feasible, unless you just backup your system and not edit anything.
If the average user can't follow a dd if/of command, would you want them to have to "fastboot boot (image)?" they might flash it, then their boot image needs to be flashed back or it won't boot. There are downsides for bootable TWRP as well. Because we don't know the decryption keys, you still have to wipe data. If you don't decrypt with the zip or SU, you can't update, etc. Decrypting modifies system which in turn makes you not able to get OTAs. It's a vicious cycle. The keys as per DeesTroy change with each boot image, so we would have to make a TWRP that has all keys, then comes to what devices do we support. Currently, the two who are actively developing and have worked on TWRP or assisted with it's boot kernel have only two devices, Sprint and T-Mobile. We wouldn't be able to debug any other model for it's decryption key.
To reiterate: to have working bootable TWRP with all the idiosyncracies you are asking for, we'd have to go through the java code like DeesTroy did and get it working. I am not fluent in java. I can make a bootable TWRP, but you'll have to be decrypted, because I know C and Python which is what kernels and most ROMs use. I don't know much about Java to find the decryption keys for each device.
Edit: for easy analogy: let's say computer languages are like human languages. I know two languages that are anglo-saxan in heritage, but you are asking me to read something latin based. I might know some things in it, but it's all greek to me still... XD
Edit 2: Looking at the TWRP for Pixel 2, the only reason they have a bootable image is to flash TWRP to both boots per their OP. It wasn't suggested to temp boot it for flashing purposes or backup purposes. It was implemented to have it in both boot partitions per the TWRP OP linked here

enetec said:
Why do you think a "booted" TWRP wouldn't be able to correctly flash zips?
I don't see reasons for this...
In fact I wrote "if possible"... BUT anyway this is of no interest. We *only* need to boot to TWRP, we are not interested in boot to an "unflashed kernel" if you understand what I mean...
We have only to force it to boot *ever* in TWRP. Kernel parts not used by TWRP (if some are needed on our phone, like some Mediatek devices need...) could be omitted at all (as done on bootable TWRP for Pixels2 if I don't go wrong...).
Click to expand...
Click to collapse
I understand, I was mainly referring to fastboot stuff, not within TWRP. Any within TWRP stuff was related to Magisk, not the inability of TWRP to flash once TWRP was loaded, but the importance of re-flashing Magisk and the consequences of not re-flashing Magisk. It was really just centered on the importance of re-flashing Magisk. Anything related to kernels stemmed from someone's question about testing kernels. Just minor stuff, but someone asked.

Uzephi said:
...
Edit 2: Looking at the TWRP for Pixel 2, the only reason they have a bootable image is to flash TWRP to both boots per their OP. It wasn't suggested to temp boot it for flashing purposes or backup purposes. It was implemented to have it in both boot partitions per the TWRP OP linked here
Click to expand...
Click to collapse
And this is *ALL* we need IMHO!!!
Is this doable in your (or others...) opinion?
EDIT: and anyway it probably will work fine to flash something and/or to fully backup a system *including* stock boot.img highfive & only excluding encrypted /data (the same encrypted /data our flashed TWRP is unable to manage too... so, what's the point on it? )

Anyway, we are really going OT here... this is not "Could a bootable TWRP be useful?" thread (it's *obvious* it is... ) this is a "What are the issues we have to face & fix to get a working bootable TWRP?" …
So my questions are basically two:
- is there a method to modify (read: force...) a boot.img with TWRP inside like ones we already have so that it boots to TWRP and not to system?
- can Pixels2/2XL bootable-only official TWRP (sources should be available...) be modified to make it work on our (similar...) device?

I would like to keep OTA (at least until there is a lineage os) and must encrypt my z2. Will the bootable TWRP decrypt the system password and allow backup? If I go with a modified boot.img with TWRP, then can I get OTA updates? or must I wait until someone modifies the OTA boot and publishes it? Can I keep one partition with the OTA and the other with a custom rom image?

kendallgreen said:
I would like to keep OTA (at least until there is a lineage os) and must encrypt my z2. Will the bootable TWRP decrypt the system password and allow backup? If I go with a modified boot.img with TWRP, then can I get OTA updates? or must I wait until someone modifies the OTA boot and publishes it? Can I keep one partition with the OTA and the other with a custom rom image?
Click to expand...
Click to collapse
To get OTA, both slots have to have an unmodified boot image, oem image and system. If anything got modified, OTA will fail

Just to link some very useful info(s) posted elsewhere...
https://forum.xda-developers.com/showpost.php?p=74665682&postcount=347
https://forum.xda-developers.com/showpost.php?p=74667790&postcount=350

ZUK Z2 Pro persist.img files flashable by twrp / adb

Hi mates,
here we go with the persists.img for Lenovo ZUK Z2 Pro.
So if you deleted them by accident you can try to reflash these:
new added file host for all files: https://www.androidfilehost.com/?w=files&flid=243937
persist.img ZUI 1.9.104:
https://mega.nz/#!0dxzwRrD!0DjKphWCRU-vv4yb1clTqrppVPGzbdaLEc4P7ItX6Ek
persist.img ZUI 2.3.044:
https://mega.nz/#!9QAE3J4I!wMNuXJ9430ihNKUgAmfJJqaB7a13v8qHtTGhCb-3hOE
persist.img ZUI 2.5.462:
https://mega.nz/#!MVZEnQCb!KvKYcHFdxvQEjlRC3zKsvQH316YY3iyNJEV3HE63cDU
persist.img ZUI 3.1.194:
https://mega.nz/#!oURh0ARA!JvliKwO6-bvdobG1qZoXg9CrH1u0zmtLsjFuoCIBoFk
persist.zip FLASHABLE zip ZUI 4.0.233 ST:
https://mega.nz/#!8RJ3hCpS!8cjVHyoOoa6yg9uvgTht71WB1CVCNoQi07GEZMxUR6M
All credits to @crisps
WARNING: these files are not tested. All use to your own risk.
Anyway if you accidentially deleted your persist partition it is worth a try
Flashable by fastboot or twrp. Note: Twrp 3.2.0.0 is not giving you the option to flash persist img. Use a previous Twrp version or flash by adb/fastboot.
TWRP 3.1.0.0 for Z2 Pro:
https://mega.nz/#!ABACiBKD!jPpLuguCoPU58Wq667D3H-YnsoyyXQ505ih0sapAOUY
Enjoy
_______________________________________
HowTo flash with fastboot:
- Download correct adb and fastboot drivers
(look into sticked thread "how to flash stock rom")
- put Persist.img in same folder like your adb/fastboot installation
- reboot your phone into fastboot mode
(hit volume when phone starts, select fastboot)
- open command line in the folder where your drivers / ADB-Fastboot installation is located.
- enter command:
fastboot.exe flash persist Persist.img
- you can reboot phone by select via volume buttons(not recommended) or type command:
fastboot reboot
!!! Dont / never ever / at no time ever select "reboot to ffbm"
Dont touch that!!!!
So my suggest is to enter command:
Fastboot reboot
(avoid missclick to that ffbm mode)
_____________________________________
experiences:
persist.img of 3.1.194 is not good with AEX 5.0. Produces black screen / blue led freeze.
persist.img of 2.3.044 is good with AEX 5.0
_____________________________________
experiences by crisps:
persist.img of 3.1.194 no problem with LineageOS by cosme 20171125

OP link added to 1.9.104 and 2.5.462 persist.img.
Added link to Twrp 3.1.0.0 where you can flash persist.img to persist partition.
With twrp newer than 3.1.0.0 the option to flash to persist partition is no longer available.

added new file host in post #1

What are those containing?
Is there any benefit to upgrade the image?

These are containing core drivers for sensors (correct me if im wrong).
No real benefit, flash only if you screw up your phone by formatting persist partition.

yep, use these persist partitions only if you deleted them by accident or experience problems with sensors.
Not necessary to use them if there is no problem.

Jb boin said:
What are those containing?
Is there any benefit to upgrade the image?
Click to expand...
Click to collapse
I have a problem with AEX, getting BLODs since 5.0. I've never used qpst and went straight from ZUI 2.5.462 to AEX. Tried all the basebands with no result(well I'm on the latrest 3.5.444 now for a couple hours still no BLODs). The recommended baseband doesn't allow me to unlock the phone as if UI restarts right after pattern entering and then asks me to draw it again. I wonder whether flashing 3.1 could help and aren't there newer persis images?

dimitar.petrunov said:
I have a problem with AEX, getting BLODs since 5.0. I've never used qpst and went straight from ZUI 2.5.462 to AEX. Tried all the basebands with no result(well I'm on the latrest 3.5.444 now for a couple hours still no BLODs). The recommended baseband doesn't allow me to unlock the phone as if UI restarts right after pattern entering and then asks me to draw it again. I wonder whether flashing 3.1 could help and aren't there newer persis images?
Click to expand...
Click to collapse
So between this post and the one where you asked me about not needing to do QPST/QFIL flashes any more since there's unofficial Treble support in the AEX thread, I get the feeling you're hoping someone will tell you that there's a simple answer that doesn't involve using QFIL to flash a factory ZUI QPST package.
There isn't.
What you're realizing is that you need to update more than just /system, /boot, and /persist... there's a lot of potential partitions that could've been messed up or accidentally wiped or overwritten, depending on which recovery you've been playing with and what the many various custom ROM installer scripts tell it to do... and the best way to make sure that ALL the partitions are healthy and have current, works-well-together data in them is by using QFIL to flash a current ZUI package (3.1.194 as of this writing) then use the factory recovery to install the latest ZUI Oreo OTA. With this phone, it's not an optional step; using QFIL to go back to a standard, factory image is literally step 1 in any of the upgrade or troubleshooting guides.
It's time to make sure you have it installed, USB drivers working, a good USB 3.0 type C cable that works reliably for data transfer, 7-zip installed, and at least 2 gigs of drive space available so you can decompress ZUI 3.1.194 into a folder at the root level of your drive. This isn't a phone you can work on without a computer unless you're ready to only stay on official ZUI releases with a locked bootloader & no root so that you can't accidentally mess anything up trying to get custom ROMs to work. If you want to re-lock your bootloader in that case, be sure you download the ZUI 1.9 QPST package and start from that instead of 3.1.194.
It's not that scary, and I'm happy to answer questions in PM if you need some help.

Terminator.J said:
So between this post and the one where you asked me about not needing to do QPST/QFIL flashes any more since there's unofficial Treble support in the AEX thread, I get the feeling you're hoping someone will tell you that there's a simple answer that doesn't involve using QFIL to flash a factory ZUI QPST package.
There isn't.
What you're realizing is that you need to update more than just /system, /boot, and /persist... there's a lot of potential partitions that could've been messed up or accidentally wiped or overwritten, depending on which recovery you've been playing with and what the many various custom ROM installer scripts tell it to do... and the best way to make sure that ALL the partitions are healthy and have current, works-well-together data in them is by using QFIL to flash a current ZUI package (3.1.194 as of this writing) then use the factory recovery to install the latest ZUI Oreo OTA. With this phone, it's not an optional step; using QFIL to go back to a standard, factory image is literally step 1 in any of the upgrade or troubleshooting guides.
It's time to make sure you have it installed, USB drivers working, a good USB 3.0 type C cable that works reliably for data transfer, 7-zip installed, and at least 2 gigs of drive space available so you can decompress ZUI 3.1.194 into a folder at the root level of your drive. This isn't a phone you can work on without a computer unless you're ready to only stay on official ZUI releases with a locked bootloader & no root so that you can't accidentally mess anything up trying to get custom ROMs to work. If you want to re-lock your bootloader in that case, be sure you download the ZUI 1.9 QPST package and start from that instead of 3.1.194.
It's not that scary, and I'm happy to answer questions in PM if you need some help.
Click to expand...
Click to collapse
It's been over a day without a blod now with latest baseband. I don't want to qfil anything because I'm sceptical of the outcome.

dimitar.petrunov said:
It's been over a day without a blod now with latest baseband. I don't want to qfil anything because I'm sceptical of the outcome.
Click to expand...
Click to collapse
And that's your choice, but if you've been flashing partitions piecemeal since ZUI 2.5.x and AEX 5.0 instead of a clean QFIL flash & bring-up to eliminate potential unknown causes of instability, please don't waste time submitting bug reports or asking for help with blue LED hard crashes since there's no way to know what state your phone is in.

Terminator.J said:
And that's your choice, but if you've been flashing partitions piecemeal since ZUI 2.5.x and AEX 5.0 instead of a clean QFIL flash & bring-up to eliminate potential unknown causes of instability, please don't waste time submitting bug reports or asking for help with blue LED hard crashes since there's no way to know what state your phone is in.
Click to expand...
Click to collapse
Well, I have only reflashed the firmware partition until now, which according to your own criteria makes me eligible for bug reporting. Jokes aside, here's why I believe it doesn't make sense what you recommend. It's been reported that the only way to recover from nonworking device sensors is by going back to zui 1.9 which you don't do. So your partitions have to be in a mixed state since you start from zui 3.1. Since your device works I assume you never ran into sensor problems and respectively reflashing zui 3.1 on your phone just gives you the illusion of a clean slate start( since there is nothing wrong with your phone in the first place)
Having said that, I haven't had a blod since firmware .344 which makes me think I'm right about that.

I'm not trying to attack you by the way, and I still want to help make sure you've got a working QPST/QFIL setup on your computer because I do believe it'll help make sure you have the best experience going forward. But I'm also appreciating the discussion, and I hope some other folks will chime in (and we can take it elsewhere in the forums if needed - I know it's getting a little off-topic).
dimitar.petrunov said:
Well, I have only reflashed the firmware partition until now, which according to your own criteria makes me eligible for bug reporting.
Click to expand...
Click to collapse
You've installed custom roms. Without QFIL in-between. That touches more than just /system, /data, /boot, /dalvik-cache, or /cache. It touches /persist where your device sensor configs live, it means you're modifying NVRAM areas like /modem-st1 and /modem-st2, and now, with the Treble-compatible TWRP fstab mounting /factory as /vendor, you're modifying /factory. There's probably many more. But you're not resetting them to a known-good factory state in-between, which is the entire point of this discussion.
dimitar.petrunov said:
Jokes aside, here's why I believe it doesn't make sense what you recommend.
Click to expand...
Click to collapse
What everyone recommends. Go look at troubleshooting and how-to guides throughout the Z2 Pro forums here and on zukfans.eu. It's all about starting with a QFIL flash which will reset your device's partitions to a known factory state before custom ROM installation. How much time have you spent looking at the files included in a QPST package, or digging into the XML to see what they're flashing? They've got a full GPT blank partition map included; it wipes out and re-loads whatever Lenovo thinks needs to get wiped out to factory flash a phone.
dimitar.petrunov said:
It's been reported that the only way to recover from nonworking device sensors is by going back to zui 1.9 which you don't do.
Click to expand...
Click to collapse
It's been reported that you might be able to flash just a persist.img that corresponds to your last-flashed ZUI version to recover from non-working sensors, but it's safer to just QFIL flash the whole thing. And I literally just flashed 1.9 before 3.1 three nights ago, and re-unlocked my bootloader. So I *DO* do that.
Like I have already said, what I disagree with is the generally proposed troubleshooting/clean flashing advice of starting with 1.9 and then doing OTA updates... more steps = more points of potential failure, especially when you're transferring over the internet from servers in China. I feel like it's superstition that we're passing along because it usually works; it's true that it's a slightly more complete troubleshooting option because it also restores a locked bootloader, which all later factory QPST packages don't touch. But if I have no reason to believe that my bootloader is messed up, as I have no problem getting into & out of it or using fastboot commands, then it's also a big waste of time. My advice continues to be that if you're trying to do super-super clean or need to troubleshoot, you should QFIL flash 1.9 then QFIL flash 3.1, rather than only flashing 1.9 then downloading OTA updates and risk those being corrupted in-transit or wasting the time/download bandwidth to get and apply several updates over & over again. As far as I can tell looking at the QPST installation packages, it's just as thorough (other than bootloader), with fewer opportunities for something to go wrong.
dimitar.petrunov said:
So your partitions have to be in a mixed state since you start from zui 3.1. Since your device works I assume you never ran into sensor problems and respectively reflashing zui 3.1 on your phone just gives you the illusion of a clean slate start( since there is nothing wrong with your phone in the first place)
Click to expand...
Click to collapse
I didn't start from 3.1, I just understand that since it's literally blowing a new GPT partition map over the storage and filling them with the appropriate images, it's not a mixed state and it is a clean state. But since it had been a while since I last touched my bootloader, I decided to start with 1.9 before going to 3.1 before going to 3.5.316 OTA before unlocking bootloader & going to custom ROM + 3.5.344 baseband via TWRP-flashable zip.
dimitar.petrunov said:
Having said that, I haven't had a blod since firmware .344 which makes me think I'm right about that.
Click to expand...
Click to collapse
Good, I'm glad it's working better now, but that shouldn't make you think you're right about avoiding QPST/QFIL. The BLoD could be from the bluetooth radio freaking out, could be from someone using a poorly-configured thermal-engine.conf that has an artificially low temp limit and it thinks it's overheating, could be from using a custom kernel with aggressively low voltages for given clock steppings, could be from failure to change clock states trying to come out of deep sleep at a certain time (like alarm going off, ugh, that one's awful). It's the Z2's general "I think I have a hardware failure and I'm going to hard crash to avoid potential physical damage by trying to continue", and I'm glad you're not getting it now with the latest radio firmwares.
Again, not trying to pick on you, but I think you're doing yourself a disservice AND wasting peoples' troubleshooting efforts if you're not willing to start with a QPST/QFIL flash, and I'm hoping I'm giving a good explanation as to why.

Actually I suffered from non-working sensors and full wipe (or you can say total factory reset) by QFIL of ZUI 1.9 solved it. I softbricked my phone between these two states trying to solve it without QFIL btw.

@Terminator.J thanks for the input. Still I'm coming from the fact that If I've only flashed AEX and AEX is the culprit of my partition problems then reflashing it once again won't solve them. And AEX is the only ROM I've ever flashed on this phone. I haven't understood you correctly about ZUI 1.9, my appologies. I haven't reported BLODS in the ROM's thread only asked if anyone experiences it since I'm aware of my personal setup. Btw If I remeber correctly NYE version was BLOD free on my phone too.
@Oriwen That's exactly what I wonder how is it possible to wipe your persist partition by flashing a custom rom? Since the cure is going to zui 1.9 and then flashing the same ROM how do you not loose your persist partition again? I'm trying to understand why flashing has such side effects or is just because of flashing random partition images like the ones in this thread?

dimitar.petrunov said:
@Oriwen That's exactly what I wonder how is it possible to wipe your persist partition by flashing a custom rom? Since the cure is going to zui 1.9 and then flashing the same ROM how do you not loose your persist partition again? I'm trying to understand why flashing has such side effects or is just because of flashing random partition images like the ones in this thread?
Click to expand...
Click to collapse
I probably flashed recovery partition badly, rewritten wrong partition and boom .... thats only possible culprit for me as far as I know.

dimitar.petrunov said:
@Terminator.J thanks for the input. Still I'm coming from the fact that If I've only flashed AEX and AEX is the culprit of my partition problems then reflashing it once again won't solve them. And AEX is the only ROM I've ever flashed on this phone. I haven't understood you correctly about ZUI 1.9, my appologies. I haven't reported BLODS in the ROM's thread only asked if anyone experiences it since I'm aware of my personal setup. Btw If I remeber correctly NYE version was BLOD free on my phone too.
@Oriwen That's exactly what I wonder how is it possible to wipe your persist partition by flashing a custom rom? Since the cure is going to zui 1.9 and then flashing the same ROM how do you not loose your persist partition again? I'm trying to understand why flashing has such side effects or is just because of flashing random partition images like the ones in this thread?
Click to expand...
Click to collapse
All an installer script (any of them - rom, gapps, magisk, supersu, whatever) has to do is touch something in /persist. And there's legitimate reasons to do that, like survival scrips for things that you want to persist across a system wipe/update (someone correct me if I'm wrong, but I know it's for more than just sensor configs), like google apps install info.
It seems like a number of folks either got too happy with wiping things in TWRP trying to clean their phone (rather than using QFIL to flash a factory QPST image, which does all the partitions!) or otherwise some custom ROM or systemless root or botched flashing attempt put garbage data into /persist. Some of the TWRP versions available, like the LR.Team ones, allow you to wipe a LOT more than just /system, /data, /cache, /dalvik-cache, /boot, and internal storage... the Chinese one will let you mount & wipe /persist, /efs, and a bunch of others you reeeeeally don't want to touch. Or maybe it just gets crusty with several months' worth of various installations (again, not just a ROM, but any installation script could actually touch it) doing different things to it and leaving ultimately incompatible data.
The cure doesn't cure /persist by wiping it, but by making sure that it only has good data in it (particularly the configs for the sensors), and that those config versions match the drivers that depend on those configs. So if you've got configs from an ancient (ZUI 1.9 = Android 6 marshmallow) version in /persist but drivers for that hardware from Oreo (taking the ZUI 3.5 blobs), it's likely that some things aren't going to behave correctly, wouldn't you agree? When someone's having trouble with their setup, QFIL of the latest full factory package (which includes fresh /persist partition images), followed by as few OTA updates as needed, is the fastest way to get good data back in all the places so you can start loading a custom recocovery & ROM from a known-good state.
Yeah, you're right; AEX 5.2 and earlier (including NYE beta and some other non-Treble custom ROMs worked okay with the ZUI nougat basebands (like the ZUI 2.5.462 you had), and they were even recommending coming from 3.1.194 because the early 3.5 DEV basebands were unstable. But in AEX 5.3 & up it REALLY needed an oreo (3.5.x) one in order to work... I was running into that same problem of constant BLOD crashes right after a QFIL flash of ZUI 3.1 and fresh TWRP 3.2.1 & AEX 5.3 install from there. Reflashing ZUI 3.1 via QFIL then updating with the 3.5.316 OTA package via factory recovery, then loading TWRP , wiping, & installing AEX 5.3 again took care of it and 5.3 has been basically solid for me in all the important ways since then (and with the latest 3.5.344 baseband update).
Again, please feel free to PM me if you'd like to compare more notes on things or are having issues... I really do want to be a resource for you & everyone here in making the most of these phones, and avoiding some big headaches. Setting up QPST/QFIL is a little headache, but it helps prevent much bigger ones in the long run.

weimerd said:
Hi mates,
here we go with the persists.img for Lenovo ZUK Z2 Pro.
So if you deleted them by accident you can try to reflash these:
new added file host for all files: https://www.androidfilehost.com/?w=files&flid=243937
persist.img ZUI 1.9.104:
https://mega.nz/#!0dxzwRrD!0DjKphWCRU-vv4yb1clTqrppVPGzbdaLEc4P7ItX6Ek
persist.img ZUI 2.3.044:
https://mega.nz/#!9QAE3J4I!wMNuXJ9430ihNKUgAmfJJqaB7a13v8qHtTGhCb-3hOE
persist.img ZUI 2.5.462:
https://mega.nz/#!MVZEnQCb!KvKYcHFdxvQEjlRC3zKsvQH316YY3iyNJEV3HE63cDU
persist.img ZUI 3.1.194:
https://mega.nz/#!oURh0ARA!JvliKwO6-bvdobG1qZoXg9CrH1u0zmtLsjFuoCIBoFk
All credits to @crisps
WARNING: these files are not tested. All use to your own risk.
Anyway if you accidentially deleted your persist partition it is worth a try
Flashable by fastboot or twrp. Note: Twrp 3.2.0.0 is not giving you the option to flash persist img. Use a previous Twrp version or flash by adb/fastboot.
TWRP 3.1.0.0 for Z2 Pro:
https://mega.nz/#!ABACiBKD!jPpLuguCoPU58Wq667D3H-YnsoyyXQ505ih0sapAOUY
Enjoy
_______________________________________
HowTo flash with fastboot:
- Download correct adb and fastboot drivers
(look into sticked thread "how to flash stock rom")
- put Persist.img in same folder like your adb/fastboot installation
- reboot your phone into fastboot mode
(hit volume when phone starts, select fastboot)
- open command line in the folder where your drivers / ADB-Fastboot installation is located.
- enter command:
fastboot.exe flash persist Persist.img
- you can reboot phone by select via volume buttons(not recommended) or type command:
fastboot reboot
!!! Dont / never ever / at no time ever select "reboot to ffbm"
Dont touch that!!!!
So my suggest is to enter command:
Fastboot reboot
(avoid missclick to that ffbm mode)
_____________________________________
experiences:
persist.img of 3.1.194 is not good with AEX 5.0. Produces black screen / blue led freeze.
persist.img of 2.3.044 is good with AEX 5.0
_____________________________________
experiences by crisps:
persist.img of 3.1.194 no problem with LineageOS by cosme 20171125
Click to expand...
Click to collapse
By flash Twrp:
Witch partition i select?
Boot
Recovery
Système image
Firmware

Read OP

"persist" lenovo z5
Hi everyone, I could get the file persist.img for lenovo z5. I am trying to use twrp but always the error because of the persist folder

new flashable persist sensors zip from ZUI 4.0.233 ST online, see first post.
Enjoy mates, all for Z2 Pro only.
Tested with latest twrp and RedWolf twrp. Tested with Android 8.1 and upcoming versions.
All credits to @crisps who did all the work and let me upload it

How to reset firmware

so i've tried a few roms, and couldn't get gpay working. im going to try a few things mentioned in other threads, but before i start that. i want to properly/fully reset my phone to the stock, to hopefully make sure i don't mess anything up in the future.
my first issue was installing twrp, i tried to `fastboot flash` the recovery, but nothing worked until i followed these steps: https://www.getdroidtips.com/download-and-install-twrp-recovery-for-redmi-k20-pro-latest/
im worried about what might be in the misc.bin in that zip. cuz i couldn't reboot into twrp recovery until i flashed that. does anyone know what that is? i think i just want to flash/reset? everything on my phone back to miui, make sure i update to the latest firmware etc. but, tbh, i find navigating xda difficult and can't seem to find the official firmware anywhere, or steps on how to reset the phone...
thanks for any help

Um, i think ur in the wrong category

thejacer87 said:
my first issue was installing twrp, i tried to `fastboot flash` the recovery, but nothing worked until i followed these steps ...
im worried about what might be in the misc.bin in that zip. cuz i couldn't reboot into twrp recovery until i flashed that. does anyone know what that is?
Click to expand...
Click to collapse
The misc.bin file is basically just a script that tells the Device to directly boot into TWRP, because Xiaomi Devices / MIUI are configured to overwrite TWRP after a reboot. If you still feel uncomfortable having to flash the misc file, try "fastboot *BOOT* TWRP.img" instead of "fastboot *FLASH* TWRP.img".
If you wish to keep MIUI installed instead of an Custom ROM make sure to flash Magisk, as it patches the DM-Verity stuff that causes the Device to either get stuck in a Bootloop or replace TWRP with the Stock Recovery.
If you're planning to run an Custom ROM like LineageOS, AOSiP etc. you don't have to flash Magisk as long as your Device isn't encrypted. Rebooting from TWRP to System without flashing Magisk on an encrypted Device will encrypt your Data Partition and you'll have to format Data to be able to access the Internal Storage again. (Flashing Magisk in that case will prevent your Device from encrypting all your Data again after an ROM Flash.)

Fatal_Scythe said:
The misc.bin file is basically just a script that tells the Device to directly boot into TWRP, because Xiaomi Devices / MIUI are configured to overwrite TWRP after a reboot. If you still feel uncomfortable having to flash the misc file, try "fastboot *BOOT* TWRP.img" instead of "fastboot *FLASH* TWRP.img".
If you wish to keep MIUI installed instead of an Custom ROM make sure to flash Magisk, as it patches the DM-Verity stuff that causes the Device to either get stuck in a Bootloop or replace TWRP with the Stock Recovery.
If you're planning to run an Custom ROM like LineageOS, AOSiP etc. you don't have to flash Magisk as long as your Device isn't encrypted. Rebooting from TWRP to System without flashing Magisk on an encrypted Device will encrypt your Data Partition and you'll have to format Data to be able to access the Internal Storage again. (Flashing Magisk in that case will prevent your Device from encrypting all your Data again after an ROM Flash.)
Click to expand...
Click to collapse
k thanks for the info. what's the difference b/w the boot v flash for twrp?
is the misc.bin from that link i posted safe then? where did it come from? is there a thread here where files like that are posted/talked about?
i definitely plan to stick with either lineage or Pixel experience. i just want to get google pay going. so i think my next attempt will be to relflash magisk and look into that sql fix everyone mentions

thejacer87 said:
so i've tried a few roms, and couldn't get gpay working. im going to try a few things mentioned in other threads, but before i start that. i want to properly/fully reset my phone to the stock, to hopefully make sure i don't mess anything up in the future.
my first issue was installing twrp, i tried to `fastboot flash` the recovery, but nothing worked until i followed these steps: https://www.getdroidtips.com/download-and-install-twrp-recovery-for-redmi-k20-pro-latest/
im worried about what might be in the misc.bin in that zip. cuz i couldn't reboot into twrp recovery until i flashed that. does anyone know what that is? i think i just want to flash/reset? everything on my phone back to miui, make sure i update to the latest firmware etc. but, tbh, i find navigating xda difficult and can't seem to find the official firmware anywhere, or steps on how to reset the phone...
thanks for any help
Click to expand...
Click to collapse
If you're planning to go back to stock MIUI and locked bootloader, I highly recommend using Mi Flash and flashing the original fastboot MIUI ROM which can be found here https://www.xda-developers.com/download-miui-11-xiaomi-redmi-note-7-pro-poco-f1/amp/. All you gotta to do is extract the ROM file which is .tgz to any folder, and in Mi Flash select that folder click on "clean all and lock" in the bottom right corner, and click flash. This should theoretically make your device "out of the box".
Keep in mind that this method requires a PC with all ADB and fastboot drivers, they can be downloaded from here https://forum.xda-developers.com/showthread.php?t=2588979 .

thejacer87 said:
k thanks for the info. what's the difference b/w the boot v flash for twrp?
is the misc.bin from that link i posted safe then? where did it come from? is there a thread here where files like that are posted/talked about?
i definitely plan to stick with either lineage or Pixel experience. i just want to get google pay going. so i think my next attempt will be to relflash magisk and look into that sql fix everyone mentions
Click to expand...
Click to collapse
BOOT will just let the Device temporarily boot into the Recovery (without making changes to the Recovery Partition) FLASH will write the Recovery Image to the Recovery Partition so you can boot to it whenever you want / need to.
I don't know if there's any kind of threads where certain files are talked about sorry, but I could be wrong though.
I don't know much about G Pay, I was gonna try it too but my Bank doesn't support it. I've seen quite a few people reporting success in getting it to work / making payments with it in local stores with the mentioned SQL Fix so if you're lucky it'll work for you too

Fatal_Scythe said:
BOOT will just let the Device temporarily boot into the Recovery (without making changes to the Recovery Partition) FLASH will write the Recovery Image to the Recovery Partition so you can boot to it whenever you want / need to.
I don't know if there's any kind of threads where certain files are talked about sorry, but I could be wrong though.
I don't know much about G Pay, I was gonna try it too but my Bank doesn't support it. I've seen quite a few people reporting success in getting it to work / making payments with it in local stores with the mentioned SQL Fix so if you're lucky it'll work for you too
Click to expand...
Click to collapse
just got gpay to work with the sql fix. thanks for the help

Trouble flashing ROMs, beside stock

Hello everyone,
I have been using custom roms happily for a couple of devices for quite some time now. Now I have the ASUS rog2 and do have some trouble with it.
History:
I bought one a year ago and flashed it with various stuff and got happy with omnirom and it worked fine. I had trouble making TWRP permanent though. However, I did not care much about it, I keep data backups anyway.
At some day the phone software crashed and bricked itself. I could not boot the rom anymore and I formatted every partition and reflashed with TWRP. It failed. Every single time the best I could get was to get the device having a bootloop. I followed what I tend to read here, flash the rom twice on both partitions. I am not sure if that is actually needed If I switch the partition to the one I just flashed.
I then found out about the EDL and flashed the phone with the QPST/QFIL (I forgot which one) and the stock rom. This worked fine and the phone booted. Reflashing again with omnirom via TWRP got me back to bootloops again. So in the end I found myself happy with the stock rom, better than no phone. I used this for some time until I finally hard crashed my phone on the road. I now operate the phone on PC via SCRCPY and I got another ROG2.
Now here is my actual question, TLDR;
I want to flash it and basically went unlocking it, booting TWRP, formatting DATA, internal and caches - Flashed omnirom to both slots via ADB sideload. Now a similar thing happens. It does not even boot past the bootloader.
I flashed the latest stock rom from ASUS, released 27th of April, Android 11 and it boots up fine. I broke it again since I want to try nanodroid and probably did something wrong. No question about it.
What am I doing wrong in flashing a random not-stock-rom?
My experience is that usually it is the users fault, so I expect here I am doing something wrong, missing a stupid step.
I...
- boot TWRP with fastboot.
- flash a rom with ADB sideload, too lazy to copy the ROM to the internal storage. I think these are same anyway.
- reboot the phone, fastboot TWRP.
- flash a rom with ADB sideload to the other slot.
- Boot and fail
Appreciate help and insight on it. I like flashing and trying but I seem to have lost the idea of what I am doing with the A/B partitioning maybe or something with this phone series.

What I found out so far is weird.
Omnirom11 and 12 (just freshly released) can be flashed without error, but when I then look at the directory structure caused by this flash... there is none. As if nothing was written. Stock ROM leaves a directory tree as expected.
So /sdcard/Download, data ... etc. are not present.
Then depends on the TWRP versions: the twrp-3.4.0-0-I001D-Q-mauronofrio.img can be booted normally, it saves its settings on the disk normally. So make changes, reboot, the changes are present.
So far TWRP 3.6 made these changes but did not manage to store them.
When I ADB push a ROM to the phone onto sdcard root, the same funny thing happens. After reboot, the file is gone.

And weirder.... when I copy stuff via adb push to /sdcard/ it is visible over reboots only in the mentioned 3.4 TWRP. If I boot 3.6 then the /sdcard/ is empty. If I reboot back to 3.4, the files are visible.
Is there some problem with some sort of overlay space?

I think I found out why, although this is lazy guesswork.
Found a video by terminal_heat_sink and followed it original; you basically have to install the stock ROM on both slots. Then install omnirom OVER the stock rom. That is maybe how they get the camera, air trigger apps running inside omni (assumption only).

No replies, you are talking to your self.
Thanks for findings

Well, if I spent my time on it understanding it (I do hope so), then maybe it helps someone else and this doesn't end up as a soulless thread that has some xkcd 979 reminisence.