Related
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.
I have a rare phone running Android 6.0 on a MT6750 with an unlocked bootloader (might be MT6750T since it is 1920x1080, but the only things I have found say MT6750)
I have been unable to get TWRP working on this phone after trying several porting guides and TWRP images. Almost all port attempts result in the boot image (logo.bin - android logo), followed by a black screen for a few seconds, then it reboots into Android.
Is it possible to manually patch the boot.img to gain root? If so, can someone point me to a guide for it? I found https://forum.xda-developers.com/android/software-hacking/systemless-root-mediatek-t3309909 but PATH doesnt seem to be set anywhere in my boot image (grep -nrw 'boot.img-ramdisk' -e "PATH"). I tried adding "export PATH $PATH:/data/bin" or "export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin::/data/bin" to init.environ.rc with other exports, but I get a boot loop
try recompile the decompiled boot.img without doing any changes and flash the compiled boot.img to see that there is no problem with respect to compilation of boot.img
shankar_vl said:
try recompile the decompiled boot.img without doing any changes and flash the compiled boot.img to see that there is no problem with respect to compilation of boot.img
Click to expand...
Click to collapse
i decompiled and recompiled without any changes using kitchen tools and flashed back ... but its showing error.
same with recovery.img also
btw im using oppo f3 mt6750t
rajeshca911 said:
i decompiled and recompiled without any changes using kitchen tools and flashed back ... but its showing error.
same with recovery.img also
btw im using oppo f3 mt6750t
Click to expand...
Click to collapse
Then its a compilation error. Its not being compiled correctly.
Btw, systemless root by supersu and magisk do a lot things like starting sudaemon, injecting supolicy changes, mounting su.img, etc. Its better to port a custom recovery and let supersu or magisk zip do all the required things to root your device.
Or if you want to be ambitious, dirty your hands with hackings, unzip these zip files and try to implement manually what is programmed there.
My suggestion is go for porting recovery from devices matching your device specs ( need not be 100%). There are several threads on this forum helping you out on this. I think chances of porting a workable custom recovery are brighter than manually compiling su compatible boot.img.
There's the problem..
I did port custom recovery.
But when I flash it back to device it's showin error.
I understand that I need to dirt my hands more to get root my device
So I decided to compile revovery.. But oppO f3 source files r not available. I tried with omni Tom source. But it failed
rajeshca911 said:
i decompiled and recompiled without any changes using kitchen tools and flashed back ... but its showing error.
same with recovery.img also
btw im using oppo f3 mt6750t
Click to expand...
Click to collapse
rajeshca911 said:
There's the problem..
I did port custom recovery.
But when I flash it back to device it's showin error.
I understand that I need to dirt my hands more to get root my device
So I decided to compile revovery.. But oppO f3 source files r not available. I tried with omni Tom source. But it failed
Click to expand...
Click to collapse
You said that even the imgs just compiled without any changes made to decompiled files are not able to boot. Then there must be something wrong with compiling. Your tools for compiling may not be correctly working.
There are carlive image kitchen tools. get them here https://forum.xda-developers.com/android/development/tool-cika-carliv-image-kitchen-android-t3013658. They are known for flawless working.
What is more important now is that you have right tools for compiling imgs. Then you can think of further.
shankar_vl said:
You said that even the imgs just compiled without any changes made to decompiled files are not able to boot. Then there must be something wrong with compiling. Your tools for compiling may not be correctly working.
There are carlive image kitchen tools. get them here https://forum.xda-developers.com/android/development/tool-cika-carliv-image-kitchen-android-t3013658. They are known for flawless working.
What is more important now is that you have right tools for compiling imgs. Then you can think of further.
Click to expand...
Click to collapse
Thanks bro. But im using carliv kitchen tools only.
I didn't tried with other kitchen tools yet.. So i give a try other tools
rajeshca911 said:
Thanks bro. But im using carliv kitchen tools only.
I didn't tried with other kitchen tools yet.. So i give a try other tools
Click to expand...
Click to collapse
no need. carliv tools are perfect. stick with them.
are you able to successfully flash imgs with sp flash tools? no matter whether you are able to boot with them.
as for porting, use twrp or any other custom recovery of SoC as yours, mt6750t and of OS version similar to yours as well.
shankar_vl said:
no need. carliv tools are perfect. stick with them.
are you able to successfully flash imgs with sp flash tools? no matter whether you are able to boot with them.
as for porting, use twrp or any other custom recovery of SoC as yours, mt6750t.
Click to expand...
Click to collapse
Ok.. I stick with carliv as u suggested. And... Yes... Im able to flash img files to phone but not with sp flash tools. Im using professional tools ( uni tools from volcano) and also flashing using a cracked download tool meant for oppo devices. ( the download tool was created on base of sp flash tools only)
Then...
I just tried twrp porting only ( same soc mt6750t quitel k6000 plus i think.. Which chipset is mt6750t)
Also tried with oppo f1s twrp which chipset is mt6750.. ( not 6750t.. ) both went wrong..
seniors and xda developrs ( zackie& a guy from Indonesia unfortunately i forgot his name) also tried to. Port twrp for me. I also tried flashing their img files ..everything went not well.. There i have understood that either compiling or flashing causing error in my device
Thats y im trying to find other wayz.. There i found ur thread .& fetching useful checklist:good:
rajeshca911 said:
Ok.. I stick with carliv as u suggested. And... Yes... Im able to flash img files to phone but not with sp flash tools. Im using professional tools ( uni tools from volcano) and also flashing using a cracked download tool meant for oppo devices. ( the download tool was created on base of sp flash tools only)
Then...
I just tried twrp porting only ( same soc mt6750t quitel k6000 plus i think.. Which chipset is mt6750t)
Also tried with oppo f1s twrp which chipset is mt6750.. ( not 6750t.. ) both went wrong..
seniors and xda developrs ( zackie& a guy from Indonesia unfortunately i forgot his name) also tried to. Port twrp for me. I also tried flashing their img files ..everything went not well.. There i have understood that either compiling or flashing causing error in my device
Thats y im trying to find other wayz.. There i found ur thread .& fetching useful checklist:good:
Click to expand...
Click to collapse
As you tried various flashing methods, you might have already known all the related intricasies of flashing. still I just want to mention that I presume you might have then known vcom drivers, creating scatter file with mtkdroid tools, loading scatter file and, most importantly switching off phone and plugging phone to PC just after clicking on flash button in sp flash tool.
And about the other tools of flashing you mentioned, sorry I will not be helpful.
A thing to mention regarding porting is taking care of mount points in fstab file and a similar file if any at /etc folder in ramdisk of decompiled port recovery. mount points should be same as fstab of your boot.img.
Besides, ensure kernel (Imaze) of port recovery is replaced with that of boot.img.
shankar_vl said:
As you tried various flashing methods, you might have already known all the related intricasies of flashing. still I just want to mention that I presume you might have then known vcom drivers, creating scatter file with mtkdroid tools, loading scatter file and, most importantly switching off phone and plugging phone to PC just after clicking on flash button in sp flash tool.
And about the other tools of flashing you mentioned, sorry I will not be helpful.
A thing to mention regarding porting is taking care of mount points in fstab file and a similar file if any at /etc folder in ramdisk of decompiled port recovery. mount points should be same as fstab of your boot.img.
Besides, ensure kernel (Imaze) of port recovery is replaced with that of boot.img.
Click to expand...
Click to collapse
Your not helpfull??.. I don't agree with that. May be im Not in the position to catch your mind.
However.. Im not going to miss single chance to upgrade myself ( yes ofcourse from devs n seniors like u)
As you said
1) i have installed vcom drivers & fetched scatter file. ( again not from mtk droid tools) . I heard mtkdroid tools nOt fully supporting mt67xx Series. Even i tried modified mtkdroid tools developed by dev havoc.. And droid tool showed some info like cpu info.. Etc. But right hand side there was an error which saying that its usable to fetch info. . I presume the error may b causing by oppo. Own OS ( Color OS based on android 6.0).. And my last try was 2 months ago. So i dont know if there is any improvements in droid tools or not. Please privide me links if they updated/ supported 67xx series
2)yes i agree with mount points you mentioned. I was just replacing fstab file from stock to. Port. I didnt edit any. . I will check again and update u.
3) Actually im in dilemma to blame on cimpiling or flashing.. The device is not booting even i didn't modify any item after repack. I need solution for that. If that resolved... Automatically everything will b set up by themselves.. Pls share any views regarding this..
I know its difficult to u to guide until u have hands on it or personally seen d procedures & results
I may upload videos / pictures/ share Team viewer etc.. if u want to see it personally.. So.. U can better understand my problem , my flaws where i need to b improved ( onlynif u wish) however i need a mentor to guide n judge methods im following
rajeshca911 said:
Your not helpfull??.. I don't agree with that. May be im Not in the position to catch your mind.
However.. Im not going to miss single chance to upgrade myself ( yes ofcourse from devs n seniors like u)
As you said
1) i have installed vcom drivers & fetched scatter file. ( again not from mtk droid tools) . I heard mtkdroid tools nOt fully supporting mt67xx Series. Even i tried modified mtkdroid tools developed by dev havoc.. And droid tool showed some info like cpu info.. Etc. But right hand side there was an error which saying that its usable to fetch info. . I presume the error may b causing by oppo. Own OS ( Color OS based on android 6.0).. And my last try was 2 months ago. So i dont know if there is any improvements in droid tools or not. Please privide me links if they updated/ supported 67xx series
2)yes i agree with mount points you mentioned. I was just replacing fstab file from stock to. Port. I didnt edit any. . I will check again and update u.
3) Actually im in dilemma to blame on cimpiling or flashing.. The device is not booting even i didn't modify any item after repack. I need solution for that. If that resolved... Automatically everything will b set up by themselves.. Pls share any views regarding this..
I know its difficult to u to guide until u have hands on it or personally seen d procedures & results
I may upload videos / pictures/ share Team viewer etc.. if u want to see it personally.. So.. U can better understand my problem , my flaws where i need to b improved ( onlynif u wish) however i need a mentor to guide n judge methods im following
Click to expand...
Click to collapse
I empathize with your frustration.
Truth is that with the devices which have not caught the fancy of developers, not having proven root methods, custom recovery, etc only, we take initiatives ourselves and learn the things the hard way which is essentially a true way learning. With popular devices having already so many developments, there is no scope for adventurism and fun as well.
Just see back what are all you gained in doing the things you did with your device for gaining root. Could it have been possible with the so called popular devices?
Now let's come to the issue. In all times of failed booting on compiled imgs, how did you restore them? flashing again stock boot and recovery imgs? and with tools you mentioned?
If you could flash stock boot and recovery with the tools you mentioned, then there is no problem with those flashing tools. Then it comes to the decompiling and recompiling of imgs.
If it could be possible, can you share here stock boot.img, and custom recovery you have selected for porting (also mention the device name, recovery pertained). Let me try.
Yup.. Bro.
What have you said all true.. during this journey i have learned so manythings like porting custom recovery , read back firmware etc and i cant forget what i have learned.. so many trail and errors
below link is the stock and custom recovery i tried to port
https://drive.google.com/file/d/0B6wWbhnrRZ_-V2RZQXByYjc4QVU/view?usp=drive_web
and a developer also tried to to port recovery for me .. below is the link which he modified for me
https://www.androidfilehost.com/?fid=745425885120760137
Im also enclosing stock boot.img
https://mega.nz/#!MF1ySQ4D!ku6RWfOP8QTkm75sNq_1_n-_Af0y843J0I0tiCHRa8k
My Device Details are
Manufacture : Oppo
Device name : Oppo f3
Model No : CPH1609
chipset : MT6750T , 4gb Ram , 64 Gb storage
[ I Really praying Inside ....:angel: god may give result for our endless efforts }
@rajeshca911 can you give details for the custom recovery you have given links, like name of the device, its os ( lollipop, marshmallow, like), and chipset if possible, it pertained to.
shankar_vl said:
@rajeshca911 can you give details for the custom recovery you have given links, like name of the device, its os ( lollipop, marshmallow, like), and chipset if possible, it pertained to.
Click to expand...
Click to collapse
Aquired custom recovery from
Device : qukitel K6000 plus, chipset MT6750T
android version 6.0 (from below)
https://www.google.co.in/amp/s/foru...al/oukitel-k6000-plus-twrp-root-t3620241/amp/
rajeshca911 said:
Aquired custom recovery from
Device : qukitel K6000 plus, chipset MT6750T
android version 6.0 (from below)
https://www.google.co.in/amp/s/foru...al/oukitel-k6000-plus-twrp-root-t3620241/amp/
Click to expand...
Click to collapse
I think the signature of the boot.img gets changed. Try to sign it after decompiling and recompiling by AVB patcher from here: https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
anandverma458 said:
I think the signature of the boot.img gets changed. Try to sign it after decompiling and recompiling by AVB patcher from here: https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
Click to expand...
Click to collapse
Shall i sign both boot.img and recovery.img as well?? or is it enough to sign compiled recovery.img ?
---------- Post added at 07:57 AM ---------- Previous post was at 07:44 AM ----------
i generated public and private keys also signed and generated
boot_signed.img
recovery_signed.img
first i flashed both the images... result was soft brick and i had to flash original boot.img
second i flashed only signed recovery.img and same was repeated.
rajeshca911 said:
Shall i sign both boot.img and recovery.img as well?? or is it enough to sign compiled recovery.img ?
---------- Post added at 07:57 AM ---------- Previous post was at 07:44 AM ----------
i generated public and private keys also signed and generated
boot_signed.img
recovery_signed.img
first i flashed both the images... result was soft brick and i had to flash original boot.img
second i flashed only signed recovery.img and same was repeated.
Click to expand...
Click to collapse
Actually, I had the same problem (I have vivo 1603). When I flashed boot.img after decompiling and recompiling,it bootlooped. I had twrp installed, so I first restored the backup of stock boot.img, and then installed the recompiled boot.img without rebooting. That worked for me
As you don't have custom recovery, I suggest that you first flash stock boot.img, and after the process completes, flash the recompiled boot.img without rebooting your device.
Hey bro, I decompiled the stock boot.img to see that if 'verify' flag was preventing booting the system with other than stock recovery. Dm-verity is a recent security control for preventing booting with changed/modified kernel/system. But I could not find any such flags, but found verity_key, so I just deleted it and decompiled the boot.img. I am not sure whether it can solve your booting problem. Let's see will this now allow to boot with custom kernel. Here is the modified stock boot.img. http://www.mediafire.com/file/tc1k1ghmy76nfqd/modified_oppo_boot.img
Flash first this boot.img and then flash the custom recovery.imgs (you can try your recoveries also)
I have also ported two recovery.imgs. Both are ported from the twrps for the same device, K6000 plus. However, what I found for this k6000 plus was different in size. So I ported two twrp recovery imgs. Here are two twrp ported recoveries, one is from you have given links to and another is from what I found on this forum.
http://www.mediafire.com/file/4als7qmpwdz1iv4/oppo_port_twrpv1.img
http://www.mediafire.com/file/5xz7387at6rr0dy/oppo_port_twrpv2.img
Once again, I reiterate that first flash the modified boot.img and then try flashing the recoveries.
Best of luck
anandverma458 said:
Actually, I had the same problem (I have vivo 1603). When I flashed boot.img after decompiling and recompiling,it bootlooped. I had twrp installed, so I first restored the backup of stock boot.img, and then installed the recompiled boot.img without rebooting. That worked for me
As you don't have custom recovery, I suggest that you first flash stock boot.img, and after the process completes, flash the recompiled boot.img without rebooting your device.
Click to expand...
Click to collapse
Bro thanks for your advice.. and i did same what you have said.. i flashed stock boot.img with out rebooting flashed recompiled boot.img the device didnt boot up.. i think culprit is something else .. that prevets booting custom images
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
I've tried to install Magisk onto my Samsung J3. First, I tried it using the TWRP method (getting TWRP in the first place is a pain) but flashing the zip file that way just caused an integrity check failure and the phone would boot no further.
I then tried using the Magisk manager to patch the stock bootloader but the "Flashing" screen fails after about nine lines, with "Unable to repack boot image". However, looking at the log, it seems actually to fail a bit earlier
CMDLINE [usted boot]: SEAndroid MAGIC failure (recovery.img)
Should I post the whole log ?
The stock bootloader that I am using is this, from SamMobile:
BL_J330FNXXU3ARC1_CL12611565_QB17142515_REV00_user_low_ship.tar.md5
When installed on its own, that bootloader works fine.
I'm also not sure what to enter for the 'force encryption' and 'verity' tick boxes; aren't these mutually exclusive ?
You're supposed to patch the boot image, not the bootloader. They're two quite different things...
Indeed. That was my error. So where do I get a stock boot image ? All I have is an archive with the CSC,AP,BL,CP parts.
I am confused though. Doesn't the patching process check that it's actually got the right sort of file - it can't just patch blind, surely ?
DontLikeCaptcha said:
Indeed. That was my error. So where do I get a stock boot image ? All I have is an archive with the CSC,AP,BL,CP parts.
I am confused though. Doesn't the patching process check that it's actually got the right sort of file - it can't just patch blind, surely ?
Click to expand...
Click to collapse
Sorry... I'm no help there. I don't do Samsung...
Without the installation log it's hard to say anything about what happened during the patching process. But, it does do some checks and will fail if it can't patch the image properly (as in if it's the wrong sort of image).
I believe the boot image is in the AP archive!
I made the mistake of reading that the firmware is the same for all three 10S models, and accidentally flashed the wrong magisk-patched boot.img.
Now, to fix my phone i Need to flash the original boot.img, but I can't find online the ROM for the Maltose variant.
Anyone can help?
I was able to find a dump of the file from here. And though that fixed my boot issue (note: the dump says it's for MIUI V12.5.14.0, whereas my phone has version V12.5.13), I still can't get root because when I patch that file with Magisk, and flash it via fastboot, it doesn't boot, and goes to FastBoot until I reflash the original.
So, the question now is, where can I find a patched boot.img for [Maltose]?
Since there's nearly no threads regarding Maltose, it might be best to leave this thread here for future reference of other users.
armaldon said:
I was able to find a dump of the file from here. And though that fixed my boot issue (note: the dump says it's for MIUI V12.5.14.0, whereas my phone has version V12.5.13), I still can't get root because when I patch that file with Magisk, and flash it via fastboot, it doesn't boot, and goes to FastBoot until I reflash the original.
So, the question now is, where can I find a patched boot.img for [Maltose]?
Since there's nearly no threads regarding Maltose, it might be best to leave this thread here for future reference of other users.
Click to expand...
Click to collapse
maltose is rosemary
Okay, that seems correct. I downloaded the RoseMary IMG version 12.5.13.0 and extracted the boot.img file, after flashing it on my device's boot A & B partitions, it does boot correctly.
I am still having issues rooting my phone, but I guess that's a different issue and requires it's own topic.