Messing Around with the 2nd-Bootloader - 7" Kindle Fire HD Q&A, Help & Troubleshooting

Hey guys, I've been wondering a few things, and I'm hoping to start some educational discussion going.
If the 2nd-bootloader simply bypasses the first locked one, doesn't that mean we can treat it as if it was the first? In other words, we can update the bootloader and such. Also, here's to the recoveries. Along with the 2nd-bootloader came TWRP. If I happen to find another recovery suitable for the KFHD7, can't I just flash that in TWRP?
It's not that I have problems with the defaults, it's just I'm a huge customization guy, and I like CWM Touch on my Android devices, running CyanogenMod. I know both of these are just not available for the KFHD7 just yet, but in case they do, will these be possible? I do know that if you try to update TWRP, the KFHD7 will end up in a bootloop, but for what reason, I have no clue. Can we go through the same process to install the 2nd-bootloader, but substituting the outdated TWRP with the updated TWRP?
For that matter, here's yet another thing: is the TWRP in the 2nd-bootloader specifically-designed for the KFHD7? If so, that probably explains why the recovery will not work if you try to update; the newer versions need to be ported in order to work. Anything you find interesting?

It seems like I recall due to the placement of the boot loader hack, the boot loader has to be modified (because it's sitting in the wrong spot). I would assume any are possible, but needs modified, and this is also why you get your boot loop
Sent from my GT-P3110 using xda app-developers app

Aside from the KF HDs having completely different partition tables from what the current custom recoveries are made for, the version of TWRP we use is slightly different from those made for the original KF.
The version of TWRP used for the 2nd generation KFs, uses the command 'rm -rf *' to wipe the partitions rather than doing a complete format as with most other versions. When ROMs are built, they are to include the stack override that hijacks the boot process and makes it possible to install unsigned boot and recovery images to their respective partitions. Without the stack override in place, there is no protection from the OMAP HS checking the signed headers of those partitions and halting the boot process, thus resulting in a major brick.
The sectors of the system partition that hold the stack override are supposed to be marked as protected, which should theoretically prevent the stack override from being wiped out by 'rm -rf *' when the system partition is wiped and the user decides to do something stupid like rebooting the device without installing a ROM (and in effect, the stack override) first.
I am told, of course, that this level of protection is entirely untested, but it goes to show you that custom recoveries need to made specifically for the 2nd generation devices with this in mind. And if the original KFs are any indication of how often people will try to reboot their device without a ROM in place, we'll know that protection of this sort (whether tested or not) is absolutely necessary to protect the average user from their own stupidity/ignorance.
As far as updating the 2nd bootloader, I'm not sure what would really need to be updated about it. It already does what it needs to do and I'm not sure what added functionality could be included with it since it's not an actual "bootloader" other than the fact that it might load and start the kernel. There are probably no hardware inits done because the first bootloader would have taken care of that, and there is no fastboot functionality added because fastboot still works with the first bootloader. I think that covers pretty much everything you would expect from an actual bootloader so other than changing the splash screen, there isn't really much you can change about it.

soupmagnet said:
Aside from the KF HDs having completely different partition tables from what the current custom recoveries are made for, the version of TWRP we use is slightly different from those made for the original KF.
The version of TWRP used for the 2nd generation KFs, uses the command 'rm -rf *' to wipe the partitions rather than doing a complete format as with most other versions. When ROMs are built, they are to include the stack override that hijacks the boot process and makes it possible to install unsigned boot and recovery images to their respective partitions. Without the stack override in place, there is no protection from the OMAP HS checking the signed headers of those partitions and halting the boot process, thus resulting in a major brick.
The sectors of the system partition that hold the stack override are supposed to be marked as protected, which should theoretically prevent the stack override from being wiped out by 'rm -rf *' when the system partition is wiped and the user decides to do something stupid like rebooting the device without installing a ROM (and in effect, the stack override) first.
I am told, of course, that this level of protection is entirely untested, but it goes to show you that custom recoveries need to made specifically for the 2nd generation devices with this in mind. And if the original KFs are any indication of how often people will try to reboot their device without a ROM in place, we'll know that protection of this sort (whether tested or not) is absolutely necessary to protect the average user from their own stupidity/ignorance.
As far as updating the 2nd bootloader, I'm not sure what would really need to be updated about it. It already does what it needs to do and I'm not sure what added functionality could be included with it since it's not an actual "bootloader" other than the fact that it might load and start the kernel. There are probably no hardware inits done because the first bootloader would have taken care of that, and there is no fastboot functionality added because fastboot still works with the first bootloader. I think that covers pretty much everything you would expect from an actual bootloader so other than changing the splash screen, there isn't really much you can change about it.
Click to expand...
Click to collapse
Very nice response, thank you!
In regards to updating the bootloader, I've seen devices like the Nexus 7 that updates the bootloader in order to flash new kernels and ROMs. I'm wondering if that same process applies to the Kindle line, if at all. That was never the case for me, because whenever I try to flash a new bootloader version (say 4.13 to 4.18) using a flashable zip, it would show as successful but my bootloader version remain unchanges. That brings up a question: can I flash literally anything that can be flashed through fastboot using the custom recoveries?
In other words, if I have an boot image, and someone theoretically converted that into a flashable .zip file, wouldn't I be able to flash the .zip through recovery, and have the same result as if I flashed using fastboot? This applies to newer custom recovery images, also. If I find another custom recovery specifically-designed for the Kindle (say a ported version of CWM Touch, similar to Hashcode's ports), do I have to flash the image through fastboot or simply create a flashable .zip and flash through TWRP?
mrkhigh said:
It seems like I recall due to the placement of the boot loader hack, the boot loader has to be modified (because it's sitting in the wrong spot). I would assume any are possible, but needs modified, and this is also why you get your boot loop
Sent from my GT-P3110 using xda app-developers app
Click to expand...
Click to collapse
Yes, I believe that's correct. I just read that Hashcode needed to port the specifically-designed recoveries, because otherwise the normal downloads on TWRP's websites are for unlocked devices only.

Related

[Q] Seeking Amazon Stock OS for Kindle Fire HD 7" 7.4.6-7 for TWRP

Need Amazon Stock OS for Kindle Fire HD 7" 7.4.6 or 7.4.7, for TWRP (zip). It would be wonderful if the firmware will be with root access and Fix wallpaper. Tnx. :good:
Well the latest version hasn't been released for twrp yet, by new I mean 7.4.7. I can see a reason why 7.4.6 went released,, but its doable atleast. The boot loader has to be updated on every amazon update or it will boot loop into recovery. There happens to be a 7.4.6 freedom boot IMG available in kinology's zip for flashing, but the latest official update hasn't been zipped for twrp with that freedom boot. You could update your is manually, reroot it, apply wallpaper fix, and disable ota's and dd and image and upload it somewhere and I could put together a system update for that or someone else could, but other wise you have to use an older version.
Sent from my Amazon Kindle Fire HD running CM10.1 Tablet UI using xda-developers app
Amazon 7.4.6 OS.zip
stunts513 said:
Well the latest version hasn't been released for twrp yet, by new I mean 7.4.7. I can see a reason why 7.4.6 went released,, but its doable atleast. The boot loader has to be updated on every amazon update or it will boot loop into recovery. There happens to be a 7.4.6 freedom boot IMG available in kinology's zip for flashing, but the latest official update hasn't been zipped for twrp with that freedom boot. You could update your is manually, reroot it, apply wallpaper fix, and disable ota's and dd and image and upload it somewhere and I could put together a system update for that or someone else could, but other wise you have to use an older version.
Sent from my Amazon Kindle Fire HD running CM10.1 Tablet UI using xda-developers app
Click to expand...
Click to collapse
Stunts: What do you need to create a zipped 7.4.6 or 8.4.6 OS.zip file that is pre-rooted, OTA block applied that does not flash the bootloader,anr or recovery just like the Hashcode X.4.3 versions?
It might be handy to be able to flash back to the Kindle OS and be at the latest version rather than a couple of versions behind.
I received a tablet from Amazon last week that was 8.4.5 so, there appears to be more than just 8.4.3 and 8.4.6.
I can upload the images that are needed to you and or, you could post how to do this?
I am presuming you need the X.46 freedom boot.img, bootloader, and, system.img files?
Questions: Don't feel obligated to answer...
I have always been confused about how 2nd bootloader works.
Once 2nd boot loader is installed, you can then install a custom ROM which replaces much of what was done to get 2nd boot?
When you install a custom ROM, what images from the 2ndboot install are left on the tablet or included with the custom ROM?
For the 2nd boot install, TWRP recovery, old bootloader and, modified boot image is installed then stack override is pushed to the system image ( read from an old Hashcode post).
However, once the custom ROM is installed, the boot image and the system image at least have been replaced so what happened to the original boot image and stack override?
Does the stack override stay in the ROM system image?
Does the boot image included in the custom ROM include the freedom boot modifications?
It does not look like the bootloader image is part of a custom ROM?
Regards
galearned said:
Stunts: What do you need to create a zipped 7.4.6 or 8.4.6 OS.zip file that is pre-rooted, OTA block applied that does not flash the bootloader,anr or recovery just like the Hashcode X.4.3 versions?
It might be handy to be able to flash back to the Kindle OS and be at the latest version rather than a couple of versions behind.
I received a tablet from Amazon last week that was 8.4.5 so, there appears to be more than just 8.4.3 and 8.4.6.
I can upload the images that are needed to you and or, you could post how to do this?
I am presuming you need the X.46 freedom boot.img, bootloader, and, system.img files?
Questions: Don't feel obligated to answer...
I have always been confused about how 2nd bootloader works.
Once 2nd boot loader is installed, you can then install a custom ROM which replaces much of what was done to get 2nd boot?
When you install a custom ROM, what images from the 2ndboot install are left on the tablet or included with the custom ROM?
For the 2nd boot install, TWRP recovery, old bootloader and, modified boot image is installed then stack override is pushed to the system image ( read from an old Hashcode post).
However, once the custom ROM is installed, the boot image and the system image at least have been replaced so what happened to the original boot image and stack override?
Does the stack override stay in the ROM system image?
Does the boot image included in the custom ROM include the freedom boot modifications?
It does not look like the bootloader image is part of a custom ROM?
Regards
Click to expand...
Click to collapse
I started pre-rooting the update file for 7.4.6, as well as adding some essential features such as voice search, live wallpapers picker, the stock Android browser, OTA disabled, etc, but I could never get it to properly boot. It would just send me back into TWRP no matter how I adjusted it or recompiled it.
>>>Sent from my homebuilt TARDIS running Android 4.4... or maybe it's a rooted Kindle Fire HD running CyanogenMod 11<<<
galearned said:
Stunts: What do you need to create a zipped 7.4.6 or 8.4.6 OS.zip file that is pre-rooted, OTA block applied that does not flash the bootloader,anr or recovery just like the Hashcode X.4.3 versions?
It might be handy to be able to flash back to the Kindle OS and be at the latest version rather than a couple of versions behind.
I received a tablet from Amazon last week that was 8.4.5 so, there appears to be more than just 8.4.3 and 8.4.6.
I can upload the images that are needed to you and or, you could post how to do this?
I am presuming you need the X.46 freedom boot.img, bootloader, and, system.img files?
Questions: Don't feel obligated to answer...
I have always been confused about how 2nd bootloader works.
Once 2nd boot loader is installed, you can then install a custom ROM which replaces much of what was done to get 2nd boot?
When you install a custom ROM, what images from the 2ndboot install are left on the tablet or included with the custom ROM?
For the 2nd boot install, TWRP recovery, old bootloader and, modified boot image is installed then stack override is pushed to the system image ( read from an old Hashcode post).
However, once the custom ROM is installed, the boot image and the system image at least have been replaced so what happened to the original boot image and stack override?
Does the stack override stay in the ROM system image?
Does the boot image included in the custom ROM include the freedom boot modifications?
It does not look like the bootloader image is part of a custom ROM?
Regards
Click to expand...
Click to collapse
Long story short the custom recovery, and the old bootloader stay the same, technically while the stack override looks like it does, it doesnt, the stack override is reapplied everytime a rom is flashed, its in the update-tools script in the rom, i found this out the hardway while porting b2g. As far as i know the 2nd bootloader is basically added to the kernel, so when we reflash a new rom with its own boot.img it would have to have 2nd bootloader in it, least thats how i'm seeing it if i remember right.
Now for the first part of the question, normally i would dd it, but since your making a rom i guess you would prefer the standard flashing format thats a pita to do... I think titanium backup has a flashable zip generator that makes a zip out of your own system image, though i think its in the paid version. If thats the case you could simply modify the os how you want it with root and such and such system apps and disable OTAs, then make a flashable zip, but you will need to make sure to add the stack overide part to the script so it doesnt hang on the bootloader. If you understand update-tools scripting style you should be able to pick the section out you need, if not i can just post it. Just look at the update-tools script in a cm11 zip file and you should ge tthe idea. its in the meta/google/android folder if i remeber right.
stunts513 said:
Long story short the custom recovery, and the old bootloader stay the same, technically while the stack override looks like it does, it doesnt, the stack override is reapplied everytime a rom is flashed, its in the update-tools script in the rom, i found this out the hardway while porting b2g. As far as i know the 2nd bootloader is basically added to the kernel, so when we reflash a new rom with its own boot.img it would have to have 2nd bootloader in it, least thats how i'm seeing it if i remember right.
Now for the first part of the question, normally i would dd it, but since your making a rom i guess you would prefer the standard flashing format thats a pita to do... I think titanium backup has a flashable zip generator that makes a zip out of your own system image, though i think its in the paid version. If thats the case you could simply modify the os how you want it with root and such and such system apps and disable OTAs, then make a flashable zip, but you will need to make sure to add the stack overide part to the script so it doesnt hang on the bootloader. If you understand update-tools scripting style you should be able to pick the section out you need, if not i can just post it. Just look at the update-tools script in a cm11 zip file and you should ge tthe idea. its in the meta/google/android folder if i remember right.
Click to expand...
Click to collapse
Thanks Stunts: I will look at the tools and cm11.zip for some details. I should learn how to remake these things but, not knowing fully about the signed partition pitfalls, I really would be hesitant to try it. It seems that unzipping, modifying and then rezipping would be risky when there has been so much said about the Kindle images being signed? How do they get resigned if not by Amazon?
I am not actually making a rom.
I do a lot of converting tablets back and forth between Kindle OS and other custom ROMs (mostly CM roms) and to do that, I often need to flash the Kindle OS to get back. If for instance I want to change a tablet back to Kindle, I need to flash X.743, then do an update to get to X.46.
If the X.46 was done up as a zip, my work would be cut in half.
Additionally, I need to be aware of which Freedom boot is running when I am flashing partitions.
If I could stay at X.46, it would avoid a lot of hassles.
I was asking for the X.46 zip as much for the xda audience at large as myself.
If you are running the Kindle OS with root and 2nd boot loader and happen to mess up the tablet, it would be nice to flash it back but, you end up a version or two behind and still need to then do an update. The alternative is to flash individual partitions using fastboot but, flashing in recovery is much quicker and safer.
Regards
galearned said:
Thanks Stunts: I will look at the tools and cm11.zip for some details. I should learn how to remake these things but, not knowing fully about the signed partition pitfalls, I really would be hesitant to try it. It seems that unzipping, modifying and then rezipping would be risky when there has been so much said about the Kindle images being signed? How do they get resigned if not by Amazon?
I am not actually making a rom.
I do a lot of converting tablets back and forth between Kindle OS and other custom ROMs (mostly CM roms) and to do that, I often need to flash the Kindle OS to get back. If for instance I want to change a tablet back to Kindle, I need to flash X.743, then do an update to get to X.46.
If the X.46 was done up as a zip, my work would be cut in half.
Additionally, I need to be aware of which Freedom boot is running when I am flashing partitions.
If I could stay at X.46, it would avoid a lot of hassles.
I was asking for the X.46 zip as much for the xda audience at large as myself.
If you are running the Kindle OS with root and 2nd boot loader and happen to mess up the tablet, it would be nice to flash it back but, you end up a version or two behind and still need to then do an update. The alternative is to flash individual partitions using fastboot but, flashing in recovery is much quicker and safer.
Regards
Click to expand...
Click to collapse
I would disregard the signing in this instance, the signature on the zip file is only really used for checking its integrity as untampered with by otas and such, the only thing that has to be signed is the bootloader and technically the boot.img but thats only when you don't have 2nd bootloader installed. If you are unaware of what fredomboot you have just flash the latest one on top of it i suppose, or one equivelent to that verison of the os. All in all if you mess up any signing in the rom the worst thats going to happen is twrp erroring out telling you the signature isnt valid, might only be a warning though, and theres a way to bypass it in twrp if i remeber right. Thats why i always resign my builds of b2g manually after adding the data folder.

[Custom Recovery] CARLIV CTR Recovery

Code:
/*
* I am not responsible for bricked devices, dead SD cards, thermonuclear war,
* or you getting fired because the alarm app failed.
* Please do some research if you have any concerns about features included
* in the products you find here before flashing it!
* YOU are choosing to make these modifications.
*/
Hello people.
Due to the fact that I have a tablet built around the MTK8127 SOC I decided to adapt some stuff for the Amazon Fire 2015
I need to mention that I don`t own the tablet so I don`t have the means to test the recovery.
The recovery is built from source using CM 12.1 and is based on the classic CWM with further additions designed for MTK devices like backup of important partitions (uboot. tee1, tee2 and so on)
What could be wrong:
-mounting points, as I used the default ones that are being used for twrp
-resolution (the recovery might not fit properly on the screen.
-other random stuff
Features
-full touch recovery
- all cwm functionalities (adb, sideload, backup, restore, install, mass storage...).
-in Carliv menu there is now a new section for flashing boot and recovery images.
-a special menu from where you can restore specific partitions
-multizip flashing function
The main sources used are here:
https://bitbucket.org/amazonfire2015/cm_device_amazon_ford/src
I have not uploaded yet the device tree that I am using as I don`t know if the build is actually working (it should), Will do when I have some days off from work .
If someone is willing to flash and tell me what are the flaws, I will address the issues.
Credits to @carliv aka @bluefirebird for his efforts in continuing the CWM project in his new form as CTR.
globula_neagra said:
Hello people.
Due to the fact that I have a tablet built around the MTK8127 SOC I decided to adapt some stuff for the Amazon Fire 2015
I need to mention that I don`t own the tablet so I don`t have the means to test the recovery.
The recovery is built from source using CM 12.1 and is based on the classic CWM with further additions designed for MTK devices like backup of important partitions (uboot. tee1, tee2 and so on)
What could be wrong:
-mounting points, as I used the default ones that are being used for twrp
-resolution (the recovery might not fit properly on the screen.
-other random stuff
Features
-full touch recovery
- all cwm functionalities (adb, sideload, backup, restore, install, mass storage...).
-in Carliv menu there is now a new section for flashing boot and recovery images.
-a special menu from where you can restore specific partitions
-multizip flashing function
The main sources used are here:
https://bitbucket.org/amazonfire2015/cm_device_amazon_ford/src
I have not uploaded yet the device tree that I am using as I don`t know if the build is actually working (it should), Will do when I have some days off from work .
If someone is willing to flash and tell me what are the flaws, I will address the issues.
Credits to @carliv aka @bluefirebird for his efforts in continuing the CWM project in his new form as CTR.
Click to expand...
Click to collapse
For awareness:
- this (any) custom recovery can only be started from fastboot on devices with 5.0.x bootloaders (rather rare)
- no custom recovery can be flashed (installed) on this device as bootloader remains locked.
globula_neagra said:
If someone is willing to flash and tell me what are the flaws, I will address the issues.
Click to expand...
Click to collapse
Thanks for your work but... no one will flash this because it's impossible on Fire due to the locked bootloader. People with the 5.0.1-based fastboot implementation will be able to boot it but not to flash it. I will try it and report back as I use this recovery on my MTK-base Asus and I love it.
A bootloader downgrade should be achievable with SP flash tools.
Are there any bootloaders uploaded somewhere ?
globula_neagra said:
A bootloader downgrade should be achievable with SP flash tools.
Are there any bootloaders uploaded somewhere ?
Click to expand...
Click to collapse
Have a look at the various threads in the different sections of the "Amazon Fire" forum. There are some downgrade protections from Amazon on these devices and hard bricks are unfortunately not so difficult.
I will get one on BF just to see if I can sort something out regarding the bootloader.
The SP flash tools have access to the lowest level of flashing, from where you can literally re-write the flash from top to bottom so I can`t see how it can go wrong unless they are changing the partitions sizes during firmware upgrades.
But I don`t understand a thing, how come TWRP is working and the one that I compiled is not working. Does the recovery partition get`s re-flashed after boot ?
I will get one on BF just to see if I can sort something out regarding the bootloader.
The SP flash tools have access to the lowest level of flashing, from where you can literally re-write the flash from top to bottom so I can`t see how it can go wrong unless they are changing the partitions sizes during firmware upgrades.
But I don`t understand a thing, how come TWRP is working and the one that I compiled is not working. Does the recovery partition get`s re-flashed after boot ?
globula_neagra said:
I will get one on BF just to see if I can sort something out regarding the bootloader.
The SP flash tools have access to the lowest level of flashing, from where you can literally re-write the flash from top to bottom so I can`t see how it can go wrong unless they are changing the partitions sizes during firmware upgrades.
But I don`t understand a thing, how come TWRP is working and the one that I compiled is not working. Does the recovery partition get`s re-flashed after boot ?
Click to expand...
Click to collapse
Partial responses:
- no one has successfully flashed twrp or any other custom recovery
- a custom recovery could be booted from fastboot on early devices; the 'vulnerability' was closed with bootloader 5.1.x and above
- bootloaders 5.1.x+ can not be rolled back to 5.0.x; hard brick
- Amazon rollback efuse has proven to be fairly robust; was never cracked on 3rd/4th gen devices that enjoyed a 2+ year run (albeit on a different chipset)
globula_neagra said:
I will get one on BF just to see if I can sort something out regarding the bootloader.
The SP flash tools have access to the lowest level of flashing, from where you can literally re-write the flash from top to bottom so I can`t see how it can go wrong unless they are changing the partitions sizes during firmware upgrades.
But I don`t understand a thing, how come TWRP is working and the one that I compiled is not working. Does the recovery partition get`s re-flashed after boot ?
Click to expand...
Click to collapse
We don't have .auth file for authentication. SP Flash tool useless without it (we can't even readback). We have secured chip.
*delete thread*
Please...?
?
quick review:
recovery boot fine
resolution seems to be off
buttons don't work
touch screen is off
sd_shadow said:
quick review:
recovery boot fine
resolution seems to be off
buttons don't work
touch screen is off
Click to expand...
Click to collapse
Sounds like a home run

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

How (not) to loose OTA? - Experiences and Discussion

Ok, as discussed in the other thread, I want to document when you loose OTA, how to avoid it, and how to fix it.
From what I know, OTA is lost when modifying the system. This means flashing a new kernel, rooting the device and modifying the build.prop or other root level stuff (mostly) will do it. The easiest way to recover from it would be to flash the stock boot.img and everything should be fine, right?
The reason this is in the Q&A is because I need real world examples what happened to you and how you've managed to get it back as well as what have you done and not lost OTA?
Thanks in advance!
You can use OTA with magisk quite easily, without even using computer( worst case, magisk wont find the stock boot.img and you need to reflash it, not such a big deal)
If you mount system for any operation(Cam2Api, or any other modification) , you need to reflash system as well.
You can always reflash stock system(or whole fastboot image), or even wait and flash a whole stock image from scratch
This tool is incredably helpful as well
https://forum.xda-developers.com/mi-a2/how-to/mi-a2-toolkit-unlock-bootloader-root-t3834585
for perfoming these operations ( Also, i have used the cam2 enabler from this tool this time, i have to see if that broke OTA next time there's an update)
I applaud the question, it's a good one, and a good basic place to start re discussing Cam2api enabling.
But, you did mean to say flash stock 'system' image, not "flash the stock boot.img"? Because the reason OTA stops working is probably both images. But for sure the system image being modified will stop them.
I can say for certain that enabling cam2api with the 'adb shell setprop persist... etc) commands will enable the API and ALSO allow you to continue to get OTA updates. I'd suggest doing some research on the setprop persist type commands to know why and exactly how it works, but it DOES NOT modify the 'system' partition, that's why OTA's continue.
A word of warning to the noobs, there are a kazillion 'Tools' in the A2 forums (no, I mean software tools, not the other kind ). Be aware, if that 'Tool' mounts 'System' as Read Write (which I know at least one of them does), 'System' is then considered modified! NO More OTA!
Reptant said:
You can use OTA with magisk quite easily, without even using computer( worst case, magisk wont find the stock boot.img and you need to reflash it, not such a big deal)
If you mount system for any operation(Cam2Api, or any other modification) , you need to reflash system as well.
You can always reflash stock system(or whole fastboot image), or even wait and flash a whole stock image from scratch
This tool is incredably helpful as well
https://forum.xda-developers.com/mi-a2/how-to/mi-a2-toolkit-unlock-bootloader-root-t3834585
for perfoming these operations ( Also, i have used the cam2 enabler from this tool this time, i have to see if that broke OTA next time there's an update)
Click to expand...
Click to collapse
Noted, and will be added to the "documentation" when I write it. Thanks for the Magisk tips.
As for the tool, looking at the other comment, OTA should now be broken because the tool should've mounted the system, but I'll wait a couple of weeks before posting that step in the documentation, and do let me know how it went for you.
AsItLies said:
I applaud the question, it's a good one, and a good basic place to start re discussing Cam2api enabling.
But, you did mean to say flash stock 'system' image, not "flash the stock boot.img"? Because the reason OTA stops working is probably both images. But for sure the system image being modified will stop them.
I can say for certain that enabling cam2api with the 'adb shell setprop persist... etc) commands will enable the API and ALSO allow you to continue to get OTA updates. I'd suggest doing some research on the setprop persist type commands to know why and exactly how it works, but it DOES NOT modify the 'system' partition, that's why OTA's continue.
A word of warning to the noobs, there are a kazillion 'Tools' in the A2 forums (no, I mean software tools, not the other kind ). Be aware, if that 'Tool' mounts 'System' as Read Write (which I know at least one of them does), 'System' is then considered modified! NO More OTA!
Click to expand...
Click to collapse
Yup, my mistake. I ment system. Thanks for the sugestion, I'll have to look at setprop persist type commands.
Now looking back at the new info I have, would that mean that flashing a custom kernel would not stop OTA from working and after the OTA update is applied, a new stock kernel would just be flashed along with the OTA?
@ILA "Now looking back at the new info I have, would that mean that flashing a custom kernel would not stop OTA from working and after the OTA update is applied, a new stock kernel would just be flashed along with the OTA?"
I've never flashed a custom kernel, but I highly doubt doing that WOULD NOT stop OTA? If that's not modifying the phone, what is? I mean, that seems to me to be an obvious modification Xiaomi would be unhappy about and try to prevent, would be my bet.
AsItLies said:
I've never flashed a custom kernel, but I highly doubt doing that WOULD NOT stop OTA? If that's not modifying the phone, what is? I mean, that seems to me to be an obvious modification Xiaomi would be unhappy about and try to prevent, would be my bet.
Click to expand...
Click to collapse
I would have to agree, and that would be highly illogical to me as well, but as far as we've seen so far is that it's only triggered by system modification. On the other hand, we haven't really had custom kernels up until recently so, not really a way to check that until someone tries it with the next OTA, but my bet's on it breaking OTA as well. If noone faces it until December, I'll try it with that update. With the November one, I want to have a sanity check if everything passes. If I have time, maybe I'll rollback updates and try it sooner, but I doubt anything from my side on this front will happen before December.
@ILA, if you do not test with another OTA, the next one will be pie update, well, at least that is what we all expect
minnuss said:
@ILA, if you do not test with another OTA, the next one will be pie update, well, at least that is what we all expect
Click to expand...
Click to collapse
Hope you are correct
But until Pie, I can always test this with rolling back to the previous OTA.
To keep OTA you need:
Stock unmodified boot image
Stock, unmodified and never mounted as writable system partition and vendor partition
Systemless root (such as Magisk), custom kernel and custom recovery all install to the boot image, if you only did one of those, flashing the stock boot image will be enough, or if you allowed Magisk to backup the stock boot image, doing this would be the easiest solution https://github.com/topjohnwu/Magisk/blob/master/docs/tutorials.md
Simply mounting System or Vendor as writable will be enough for you to lose OTA (it's normal to mount them read only, don't panic when magisk does that)
so a modified build.prop will break OTA, but using setprop or resetprop will not, because those only affect /data (therefore you can't have a locked bootloader with camera2 enabled, because locking will wipe /data)
If you modified system or vendor and want to OTA, simply flash the stock image of the partition you modified via fastboot and it will work, but only if it comes from the same build you're currently running, if you're on September patch, you'll need to flash system.img from 9.6,13, and only that will work
it's always a good idea to keep the latest fastboot rom on your pc in case you needed it, but if it's not yet available, you can use TWRP to backup system, vendor and stock boot image before modifying them, and restore them before OTA, but make sure to select Backup System image and Vendor image Not backup system/vendor, because normal backup will just copy the files while an image backup will take the whole partition as it is, if you just restore the files then the image will have a different hash and you'll still fail to OTA
Also, as long as Anti Rollback is not active on A2 (it's not yet), you can always just roll back to the latest available fastboot image and OTA from there
Nebrassy said:
To keep OTA you need:
Stock unmodified boot image
Stock, unmodified and never mounted as writable system partition and vendor partition
Systemless root (such as Magisk), custom kernel and custom recovery all install to the boot image, if you only did one of those, flashing the stock boot image will be enough, or if you allowed Magisk to backup the stock boot image, doing this would be the easiest solution https://github.com/topjohnwu/Magisk/blob/master/docs/tutorials.md
Simply mounting System or Vendor as writable will be enough for you to lose OTA (it's normal to mount them read only, don't panic when magisk does that)
so a modified build.prop will break OTA, but using setprop or resetprop will not, because those only affect /data (therefore you can't have a locked bootloader with camera2 enabled, because locking will wipe /data)
If you modified system or vendor and want to OTA, simply flash the stock image of the partition you modified via fastboot and it will work, but only if it comes from the same build you're currently running, if you're on September patch, you'll need to flash system.img from 9.6,13, and only that will work
it's always a good idea to keep the latest fastboot rom on your pc in case you needed it, but if it's not yet available, you can use TWRP to backup system, vendor and stock boot image before modifying them, and restore them before OTA, but make sure to select Backup System image and Vendor image Not backup system/vendor, because normal backup will just copy the files while an image backup will take the whole partition as it is, if you just restore the files then the image will have a different hash and you'll still fail to OTA
Also, as long as Anti Rollback is not active on A2 (it's not yet), you can always just roll back to the latest available fastboot image and OTA from there
Click to expand...
Click to collapse
Thank you for a very comprehensive answer! That pretty much covers everything that I wanted to know in this thread. This will be the main part of the new thread, but I'll write it in a week or so just to leave enough time if anyone remembers any more examples.

corrupt to the core

heya people! my razer 2 is screwed. I had trinity kernel originally, and i saw arter's was updated to april and trinity was march so i flashed arter's, someone else did it with no issue.
K so i flash arter, go to system, reboot, someone in tg group told me arter is sketchy and known to brick phones, so i wanted to go back to trinity, before tho, someone said i should clean flash my stock, so i tried. The thing is, the file comes from razer, and is a flash_all.bat the only problem was i couldnt use fastboot, so after talking to them i tried to just flash the boot.img to boot slot in twrp. Big mistake. Twrp no longer is a thing, fastboot doesnt work, cant go into download mode, when i boot up my phone it tells me my phone is corrupted and may not function, after that it takes me to default android recovery screen.
if i hit apply via adb, i get sys errors and **** and according to nfs group, my partition is completely corrupted (device not found) or something like that
so i called a repair place and explained it to him and he said hed have to look at it, so im gonna probably have to drive down there for him to tell me its screwed.
I tried applying via sd card, but when i insert the sdcard to my pc and try to write files, it says its write protected, and i dont see anything in properties about making it r/w so im really at a loss.
Is there ANYTHING i can do or am i gonna have to pray that this guy knows something?
dont thikn i can send to razer since i broke my warranty unlocking bootloader and rooting.
anything would help guys, i dont wanna have to go back to my razer 1 ;_;
ok well i didnt get any replies so i took it to a repair place, he said his tech guy wasnt in but he'd call me with updates as to whats happening. Shouldnt cost more than $75 so thats great.
if you have any ideas on what could be wrong id love to hear, maybe i can learn from my mistakes and be able to recover next time.
I'm not sure about the comments in the telegram group, but I don't think it was necessary to flash all the stock stuffs. Factory images may contain stuffs that you should never flash on a device that has already left factory and packaged. Usually you should only be flashing boot, system and vendor (plus userdata, if you want to wipe existing data as well). You may also consider flashing modem, dsp, bluetooth if baseband/firmware update on certain parts are needed.
Recovery is now part of the kernel image, so flashing stock kernel means you have stock recovery. Stock recovery is only useful if you accidentally issued Factory Reset from system, or pressed "Wipe user data" from bootloader (which happened when I was preparing the device for unlock/rooting for the first time), and got into an endless loop after that (since TWRP may not properly handle /misc stuffs).
Again, **NEVER** use Factory Reset from system, or Wipe user data from bootloader, if you use TWRP. Always wipe data from TWRP if you intend to do so.
At one point (r13) arter97's kernel had some issues which is supposed to have been fixed in r14. I haven't updated my kernel yet since last Trinity nightly (it's working great even after flashing MR3 vendor stuffs).
LSS4181 said:
I'm not sure about the comments in the telegram group, but I don't think it was necessary to flash all the stock stuffs. Factory images may contain stuffs that you should never flash on a device that has already left factory and packaged. Usually you should only be flashing boot, system and vendor (plus userdata, if you want to wipe existing data as well). You may also consider flashing modem, dsp, bluetooth if baseband/firmware update on certain parts are needed.
Recovery is now part of the kernel image, so flashing stock kernel means you have stock recovery. Stock recovery is only useful if you accidentally issued Factory Reset from system, or pressed "Wipe user data" from bootloader (which happened when I was preparing the device for unlock/rooting for the first time), and got into an endless loop after that (since TWRP may not properly handle /misc stuffs).
Again, **NEVER** use Factory Reset from system, or Wipe user data from bootloader, if you use TWRP. Always wipe data from TWRP if you intend to do so.
At one point (r13) arter97's kernel had some issues which is supposed to have been fixed in r14. I haven't updated my kernel yet since last Trinity nightly (it's working great even after flashing MR3 vendor stuffs).
Click to expand...
Click to collapse
hmm, im not understanding how flashing stock boot.img to boot partition would make recovery part of the kernel image? boot.img is the literal only thing i got to flash in twrp before it just died.
Like i said fastboot didnt work, and oddly enough, it doesnt work on my old razer 1 either, i tried rooting it the other day and it wont go to fastboot
Edit: according to an admin in magnetar group, dm-verity could be the reason, and he said i should've flashed something called "lazy flasher" after flashing the boot img. Never heard of it and never used it.
hadtosignuptoreply said:
hmm, im not understanding how flashing stock boot.img to boot partition would make recovery part of the kernel image? boot.img is the literal only thing i got to flash in twrp before it just died.
Like i said fastboot didnt work, and oddly enough, it doesnt work on my old razer 1 either, i tried rooting it the other day and it wont go to fastboot
Edit: according to an admin in magnetar group, dm-verity could be the reason, and he said i should've flashed something called "lazy flasher" after flashing the boot img. Never heard of it and never used it.
Click to expand...
Click to collapse
Recovery is built into the kernel (which is common for recent devices). arter97 (or Trinity) kernel image includes TWRP in place of the stock recovery, so you get TWRP when you flashed the kernel. Stock boot.img comes with stock recovery, so if you flash stock kernel you lose TWRP.
Also, keep track of your reboot count and your current active slot. If your system fails to boot multiple times in a row, the bootloader may consider it damaged and switching to another slot (which usually contains the previous version of system/vendor/modem etc.) and may cause some issues if you're unlocked (or you were previously on a GSI).
As for fastboot issues, I once had a time that I could only conduct flash commands within a very tiny time window right after the phone booted to bootloader, although the problem has been lessened after reboot and I could now flash properly again. It's unknown when the problem would resurface that I'd need another reboot (given the distro I use, Manjaro, is constantly updating, I'd just update the system and reboot anyway if that happens).
Some fastboot versions may be buggy, or maybe USB interactions under Linux can be problematic in general (especially in handling plugs and unplugs). This is more apparent if a system is running constantly for a long time and a lot of devices has been properly (or improperly) plugged or unplugged over the course of its uptime. Maybe it's better if one conducts fastboot using rear USB ports (as front USB ports tend to have less voltage).
I never bothered with dm-verity and hardly ever had problems with it.
vnb
LSS4181 said:
Recovery is built into the kernel (which is common for recent devices). arter97 (or Trinity) kernel image includes TWRP in place of the stock recovery, so you get TWRP when you flashed the kernel. Stock boot.img comes with stock recovery, so if you flash stock kernel you lose TWRP.
Also, keep track of your reboot count and your current active slot. If your system fails to boot multiple times in a row, the bootloader may consider it damaged and switching to another slot (which usually contains the previous version of system/vendor/modem etc.) and may cause some issues if you're unlocked (or you were previously on a GSI).
As for fastboot issues, I once had a time that I could only conduct flash commands within a very tiny time window right after the phone booted to bootloader, although the problem has been lessened after reboot and I could now flash properly again. It's unknown when the problem would resurface that I'd need another reboot (given the distro I use, Manjaro, is constantly updating, I'd just update the system and reboot anyway if that happens).
Some fastboot versions may be buggy, or maybe USB interactions under Linux can be problematic in general (especially in handling plugs and unplugs). This is more apparent if a system is running constantly for a long time and a lot of devices has been properly (or improperly) plugged or unplugged over the course of its uptime. Maybe it's better if one conducts fastboot using rear USB ports (as front USB ports tend to have less voltage).
I never bothered with dm-verity and hardly ever had problems with it.
Click to expand...
Click to collapse
ah ok. Well the repair guy called and said they didnt know what was wrong or how to fix it, i know i can at least get to bootloader, and to root my razer 1 again, i went to bootloader and fastboot worked. Before work tomorrow im gonna get that phone from the place and hope that i can flash what i need to get it working again. Assuming it will actually be able to read the device. Thanks for your input

Categories

Resources