Hello,
I have a px5 head unit.
I was trying to get root access on this unit, the kignoroot or whatever its name was didn't work. Using recovery.img which I exteracted from a working update.img, I preformed offline patch using Magisk. Magisk recognized the recovery.img and patched it. When I flashed the image my recovery is gone. There is black screen instead. I know it is working and the options are there.. but I can't see them to be able to use them.
With recovery gone, thanks to Magisk, I think the only hope now is to be able to use adb to restore recovery partition, try booting from sd card, or be able to access the bootloader to flash recovery partition.
so far I tried the commands:
setprop persist.adb.tcp.port 5555
setprop sys.rkadb.root 1
but when I try to connect I get "device unauthorized"!
I am unable to update the unit anymore..!
thanks for your help.
why the heck you patch the recovery.img in the first place?
the manual patch is only got boot.img aka kernel, not recovery.
this is clearly your fault!
no need to thanks Magisk for destroying your recovery, you destroyed it yourself.
Sent from my MI 5s Plus using Tapatalk
zohair_ said:
Hello,
I was trying to get root access on this unit, the kignoroot or whatever its name was didn't work. Using recovery.img which I exteracted from a working update.img, I preformed offline patch using Magisk. Magisk recognized the recovery.img and patched it. When I flashed the image my recovery is gone. There is black screen instead. I know it is working and the options are there.. but I can't see them to be able to use them.
With recovery gone, thanks to Magisk.
Click to expand...
Click to collapse
Well, about all I can say as a noob is READ, READ, READ. Everything you need is pretty well right here if you take the time to investigate your options. Nobody is going to hold your hand if you choose to follow through. Trashing the developer for your error isn't going to win you any friends either.
I came here some time ago looking for a way in to an SM-J320W a friend had picked up at an auction and I've probably spent close to 70+ hours reading about the various exploits, anomolies, file structures, device security, risks, and potential operational impacts, and indeed the distinct possibility I could even brick the device.
Like you I tried KingoRoot, Kingroot, and SU as relatively easy and benign attacks to no avail.
That led to longer investigation of more intensive attempts like CF-Auto-Root, Magisk, Rooted Boot Images, Custom Recovery ....
Right now I am looking at my Magisk App screen with 4 green checkmarks and a pass by Root Checker. ROOTED!
So, for all the other noobs out there:
Do your RESEARCH
Evaluate your OPTIONS
Understand the potential RISKS
Proceed only if you are PREPARED FOR THE CONSEQUENCES
It ain't rocket science, but it is science and you need to understand what you're doing.
Thanks for your responses. I would like to agree with your that it was my fault but can you explain how did Magisk was able to:
1. Unpack the recovery. Img
2. Recognize that the file was in the correct arm64 processor format and the correct one to patch.
3. Patch the file it recognized and unpacked.
4. Made a backup copy of the file before patching it.
5. Repacked the file.
6. Produce a log file affirming that the patching process was Successful!
All of this while it was the wrong file in the first place? It is hard to believe that it was my fault because recovery. Img was the only file accepted by Magisk. I tried all the other firmware files like boot. Img and kernel. Img and others, the only file that was accepted and recognized by Magisk was recovery. Img. Between us Magisk was not able to determine that the file it already patched was actually patched, no matter how many times you repatch that file.
Sorry to prove you wrong sir...!
I'm going to assume that your device is simply too far removed from a vanilla Android experience for it to be compatible with Magisk. The fact that it recognised and patched the recovery.img when Magisk is designed to alter the boot.img is a big hint... It would have been interesting to see the log from when you patched the file.
zohair_ said:
Thanks for your responses. I would like to agree with your that it was my fault but can you explain how did Magisk was able to:
1. Unpack the recovery. Img
2. Recognize that the file was in the correct arm64 processor format and the correct one to patch.
3. Patch the file it recognized and unpacked.
4. Made a backup copy of the file before patching it.
5. Repacked the file.
6. Produce a log file affirming that the patching process was Successful!
All of this while it was the wrong file in the first place? It is hard to believe that it was my fault because recovery. Img was the only file accepted by Magisk. I tried all the other firmware files like boot. Img and kernel. Img and others, the only file that was accepted and recognized by Magisk was recovery. Img. Between us Magisk was not able to determine that the file it already patched was actually patched, no matter how many times you repatch that file.
Sorry to prove you wrong sir...!
Click to expand...
Click to collapse
Even if the software trashes your whole system, it comes "as is", meaning that you get all the features and all possible bugs too without any kind of warranty. Nobody forced you to install it, so is the user's responsability to take all necessary steps to be able to recover the system to their prior state or assuming the risks involved in not doing so.
What you should and can do is provide as much information about your hardware and software so you may help others in the same situation and maybe make the developer take a look at it.
Understand that with that kind of attitude will not get you far here. As mentioned by others, educate yourself properly before taking any action that might brick your device, if something goes wrong is your sole responsability, but there are a lot of people here willing to help if you treat them with respect.
contents of the log file (magisk_install_log_20181204_054200.log) :
- Copying image to cache
- Device platform: arm64-v8a
- Existing zip found
- Extracting files
- Unpacking boot image
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/data/user/0/com.topjohnwu.magisk/install/boot.img]
KERNEL [15104080]
RAMDISK [20858336]
SECOND [0]
EXTRA [0]
PAGESIZE [16384]
NAME []
CMDLINE []
CHECKSUM [7415a67292764b19e4067d67731d81ecc63a557b]
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
- Checking ramdisk status
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
Loading cpio: [ramdisk.cpio]
- Stock boot image detected
- Backing up stock boot image
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
Compressing to [stock_boot_334712fd9ff58aa61ae0734b157fc1261e8a616f.img.gz]
- Patching ramdisk
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
Loading cpio: [ramdisk.cpio]
Add entry [init] (0750)
Patch with flag KEEPVERITY=[false] KEEPFORCEENCRYPT=[false]
Remove pattern [,verify]
Remove pattern [,verify]
Save SHA1: [334712fd9ff58aa61ae0734b157fc1261e8a616f] -> [.backup/.sha1]
Loading cpio: [ramdisk.cpio.orig]
Backup mismatch entry: [fstab.rk30board.bootmode.emmc] -> [.backup/fstab.rk30board.bootmode.emmc]
Backup mismatch entry: [fstab.rk30board.bootmode.unknown] -> [.backup/fstab.rk30board.bootmode.unknown]
Backup mismatch entry: [init] -> [.backup/init]
Dump cpio: [ramdisk.cpio]
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
Patch @ 00CA4257 [736B69705F696E697472616D6673]->[77616E745F696E697472616D6673]
- Repacking boot image
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/data/user/0/com.topjohnwu.magisk/install/boot.img]
KERNEL [15104080]
RAMDISK [20858336]
SECOND [0]
EXTRA [0]
PAGESIZE [16384]
NAME []
CMDLINE []
CHECKSUM [7415a67292764b19e4067d67731d81ecc63a557b]
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
Repack to boot image: [new-boot.img]
KERNEL [15104080]
RAMDISK [21090778]
SECOND [0]
EXTRA [0]
PAGESIZE [16384]
NAME []
CMDLINE []
CHECKSUM [f8b4e9f25b0c488e9a96a66263730d46737766b8]
MagiskBoot v17.1(17100) (by topjohnwu) - Boot Image Modification Tool
Cleaning up...
****************************
Patched image is placed in
/storage/emulated/0/Download/patched_boot.img
****************************
- All done!
EOF
=========================================
The Name of the firmware file is update. Img extracted from kgl_px5_6.0(20171102).rar (the link to download this file is posted somewhere here on the forum)
Version of Magisk: 5. 9.1
I think a reproduction of the same log is possible using the recovery. Img extracted from that firmware.
Why do I have this feeling that I am the one who is being treated with disrespect here..?
Device details? Android version? Are you using Magisk 17.1 for some particular reason? (At the time of this post, Magisk 18.0 was the latest stable release). You should also attach or link boot.img that you're trying to patch (saying is "somewhere in the forum" is not really helpful).
zohair_ said:
Why do I have this feeling that I am the one who is being treated with disrespect here..?
Click to expand...
Click to collapse
First: You blamed Magisk for what's clearly your fault.
Second: Of course Magisk will be able to patch stock recovery.img since it's essentially a SECONDARY OS in your phone albeit minimal, to recover your phone to working state.
It got it's own kernel and such, like an almost complete OS. Of course Magisk will be able to patch it & recognized it as a correct file to patch (it got untouched kernel which is compatible in it).
But if you patch it, you'll get what you get now: broken recovery, since it's not designed to patch recovery and no one crazy enough to attempt to patch a recovery with Magisk.
So, about disrespect: research before blaming. As anyone says: no one forced you to use Magisk. It's free & power come with great responsibility.
Magisk will give you degree of freedom to tinker with your phone, like root & xposed. But if you use them wrong, well, don't blame it if your phone's broken.
Just flash your phone with complete stock firmware and start over.
No hard feeling.
J_M_V_S said:
Device details? Android version? Are you using Magisk 17.1 for some particular reason? (At the time of this post, Magisk 18.0 was the latest stable release). You should also attach or link boot.img that you're trying to patch (saying is "somewhere in the forum" is not really helpful).
Click to expand...
Click to collapse
The device is a rockchip sdk3026. This head unit is popular on your forum as px5.
Android version is 6 Marshmallow.
I wasn't using Magisk 17.1 directly, I was using Magisk GUI and the "Boot Image Modification Tool" version 17.1 was used by the main program.
I downloaded the firmware from here. I cannot access that link anymore.
I will provide you with an ftp link soon where you can down load all the needed files.
Thanks for tying to help.
1.
Crescendo Xenomorph said:
why the heck you patch the recovery.img in the first place?
the manual patch is only got boot.img aka kernel, not recovery.
this is clearly your fault!
Click to expand...
Click to collapse
2.
Crescendo Xenomorph said:
Second: Of course Magisk will be able to patch stock recovery.img since it's essentially a SECONDARY OS in your phone albeit minimal, to recover your phone to working state.
Click to expand...
Click to collapse
3. no comment...!
zohair_ said:
The device is a rockchip sdk3026. This head unit is popular on your forum as px5.
Android version is 6 Marshmallow.
I wasn't using Magisk 17.1 directly, I was using Magisk GUI and the "Boot Image Modification Tool" version 17.1 was used by the main program.
I downloaded the firmware from here. I cannot access that link anymore.
I will provide you with an ftp link soon where you can down load all the needed files.
Thanks for tying to help.
Click to expand...
Click to collapse
head here: https://forum.xda-developers.com/an...eneral/mtcd-px5-headunits-repository-t3619906
there's a link for the firmware you need.
as for the instruction of how to flash it, better search in those subforum as I don't have the head unit myself.
as for root info: https://forum.xda-developers.com/android-auto/mtcd-software-development/root-oreo-t3779605
you're welcome
Well, about all I can say as a noob is READ, READ, READ. Everything you need is pretty well right here if you take the time to investigate your options. Nobody is going to hold your hand if you choose to follow through. Trashing the developer for your error isn't going to win you any friends either.
I came here some time ago looking for a way in to an SM-J320W a friend had picked up at an auction and I've probably spent close to 70+ hours reading about the various exploits, anomolies, file structures, device security, risks, and potential operational impacts, and indeed the distinct possibility I could even brick the device.
Like you I tried KingoRoot, Kingroot, and SU as relatively easy and benign attacks to no avail.
That led to longer investigation of more intensive attempts like CF-Auto-Root, Magisk, Rooted Boot Images, Custom Recovery ....
Right now I am looking at my Magisk App screen with 4 green checkmarks and a pass by Root Checker. ROOTED!
So, for all the other noobs out there:
Do your RESEARCH
Evaluate your OPTIONS
Understand the potential RISKS
Proceed only if you are PREPARED FOR THE CONSEQUENCES
It ain't rocket science, but it is science and you need to understand what you're doing.
Click to expand...
Click to collapse
Hi, for the J320W, did you root it at 7.1 ? If so, do you mind sharing the steps ? I only found one rooting approach but only for 6.0.1 . Many thanks in advance !
Related
NOTE: Unfortunately I've had to remove links from this post because I'm a new user. I'll add them back in once I have enough posts.
I've been trying to edit a file in boot.img from the CyanogenMod 12.1 (huashan) nightlies but I'm experiencing some issues finding the right tools/methods for the job.
Most scripts I've found expect an Android Magic number at the beginning of the file but this simply isn't there. It seems there is no header at all that matches the specification from bootimg.h (missing link) though I did discover the cmdline argument at the end of the file with a hex editor.
After searching and experimenting for hours I found a script here (missing link) which enabled me to extract the kernel and ramdisk images despite the missing header but now I don't know how to repack the files into a boot.img of the same structure.
I've tried the following but it results in a boot.img that is about 40% larger than the orginal (despite me only adding one line of code) and has an entirely different structure (with an Android Magic number, etc.).
Code:
mkbootimg --base 0x00200000 --pagesize 2048 --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
I found this resource (TWRP, missing link) which mentions that Xperia devices have special boot images (or something like that, I didn't understand all of it) - this might explain why the boot.img structure is so different - but I can't find any further documentation on this or instructions on how to deal with the format.
The Xperia devices have a recovery-in-boot arrangement. This means that the recovery is booted using the regular kernel / boot image in the device. Team Win has worked with the FreeXperia device maintainers to come up with a way to extract the ramdisk from the FOTAKernel partition and use the ramdisk from that partition instead of the recovery that is included in the boot image of your device. This means that if you install current CM nightlies and flash TWRP to the FOTAKernel partition, you will be able to use TWRP instead of the CWM or CM recovery that normally comes in a CM boot image. Other boot images including stock kernels can be repacked to include this extraction utility to allow you to use TWRP from the FOTAKernel partition. This setup allows you to choose what recovery you want to have installed and allows you to update your recovery more easily. Unfortunately this setup requires that the boot image that you have installed include the ramdisk extraction utility.
Click to expand...
Click to collapse
So now I'm at a loss at how to continue. I would much appreciate any pointers, ideas or help in general.
@infernalpostcard , hopefully this tool made by @Adrian DC will help you out.
https://github.com/AdrianDC/android_huashan_bootimg_editor
Raienryu said:
@infernalpostcard , hopefully this tool made by @Adrian DC will help you out.
https://github.com/AdrianDC/android_huashan_bootimg_editor
Click to expand...
Click to collapse
Thanks. This looks really promising. I'm trying it out now...
EDIT: It worked! This is exactly what I needed. Unfortunately what I was actually trying to achieve (apply a fix to break a boot-loop my phone gets in, due to an encrypted filesystem) didn't work so I'll have to come up with new ideas.
Some of you might face the next error during systemless SuperSU install:
...
- Decompressing ramdisk
failed
--- Failure, aborting
*************************
IMPORTANT NOTICES
*************************
First reboot may take a
few minutes. It can also
...
This means that the ramdisk of your boot image was compressed in a non gzip format.
Unfortunately SuperSU can only decompress and tweak gzip compressed ramdisks up to now.
However i tried to make a little script that will uncompress your boot image/ramdisk and recompress it to gzip then after flashing SuperSU it recompresses the ramdisk to the original format.
This way one can achieve systemless root temporarily on such devices by installing SuperSU.
Idk maybe it can also be used for Magisk???
Download v1.1 (rce_univ.zip):
http://viid.me/qoESak
in case you face any proglems with the above version, try the old one v1.0 (rce_univ_1.0):
http://viid.me/qir1u5
How to:
Boot into TWRP 3.0.0 or above (never tested below) and install rce_univ.zip before and after SuperSU.zip!
Video: http://viid.me/quIbOi
Consider flashing Chainfire's Boot image signer (in case you get soft bricked after the above steps):
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
Detailed description in comment nr.3 (https://forum.xda-developers.com/showpost.php?p=70428981&postcount=3)
Supported ramdisk compressions:
bzip2, lz4, lzo, lzma, xz
Requirements:
Unlocked bootloader on most newer (marshmallow and lollipop) devices
Don't expect it to be working on every device!
The script is basically fool proof. I mean if anything goes wrong it will promt you and quit.
Then you can simply restore your boot partition (if you didn't forget to back it up) and boot up normally and deal with the non rooted idea...
Also it's not supposed to mess up anything that would cost you a hard brick. Soft brick is only possible if you forget to make backup of your boot image or if you get SuperSU intalled and rec_univ.zip cannot recompress your ramdisk (this is pretty much impossible anyways)
Naturally there are those Samsung and Sony devices with some tricky boot images... idk. Never tested but most likely not gonna work.
Probably there will be many devices on which there are not enough space to decompress and recompress ramdisks/boot images in TWRP.
In comment nr. 2 i will collect the devices that are compatible with this script and the method itself.
If you can't find your device there as i said it's fool proof but you better be careful! You can simply test it by backing up your boot images between each install and with the mount mtp function you put it on PC (you can't quit TWRP during the whole process - i mean during step 2) and with carliv image kitchen (https://forum.xda-developers.com/android/development/tool-cika-carliv-image-kitchen-android-t3013658) you check if you can unpack them normally.
Or if you don't care so much you just try and the worst case you reflash your framework...
If you are about to post any errors or complains do it the right way:
- attach recovery.log
- describe your device (model name, firmware version, ...)
- attach your boot image you backed up (upload it somewhere and link it)
If you are about to post a succesful attempt of a not yet added device:
- describe your device (model name, firmware version, ...)
- maybe link to its thread
No promises... and no responsibility i take... !!!
Please don't upload it anywhere else just use link to this thread!
I have to say thanks jcadduono for LazyFlasher boot image patcher script i used for the ramdisk compression exchanger and also thanks goes to Chainfire for SuperSU (especially for the boot image finder srcipt which is took from the SuperSU installer).
The xz archiver was used from XZ Utility For Android by Tukaani http://tukaani.org/xz/ - i hope he doesn't mind. Let me know if he does!
Supported devices until now:
Lg K8 - https://forum.xda-developers.com/lg-k10/how-to/friendly-root-method-lg-k8-k10-t3531223
Lg K10 - https://forum.xda-developers.com/lg-k10/how-to/friendly-root-method-lg-k8-k10-t3531223
Note 4 n910v (7.1.1 rom) https://forum.xda-developers.com/showpost.php?p=72491391&postcount=18
Detailed description
Systemless root with SuperSU on devices with non gzip compressed ramdisk bootimage
0. Download rce_univ.zip from here: http://viid.me/qir1u5 and download SuperSU (latest or there are some cases that requires earlier versions): https://forum.xda-developers.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703 and put them on your sd card (external sd card is usually necessary since sometimes TWRP cannot decrypt your data partition/internal sd).
1. Unlock your bootloader
1.1. Additional step for those who has no "...device corrupt..." message during every boot up after unlocking bootloader on Marshmallow and some Lollipop devices(*)
- Boot into TWRP
- on the keep system read only? screen of the TWRP let it allow modifications (swipe!)
- reboot to System
- from now on you should have the message at every boot up
2. Boot into TWRP
- cancel decrypt data
- keep system read only
- go to Backup -> Backup your boot image! Maybe it comes handy later.
- go back from backup to install and install rce_univ.zip right after install SuperSUxxx.zip and then rce_univ.zip again.
- do not wipe anything during and after this step, just reboot! (this might take a while and a few bootloops...)
Video guide: http://viid.me/quIbOi
(3.) Verified boot?
In case of soft brick (or if you're sure you need the proper signature in the end of your boot partition - cos your device has verified boot) try flashing Chainfire's Boot image signer as a very last step before rebooting from TWRP:
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
(*) on some devices if there is no "device corrupt" message at every boot up after bootloader unlock then anything you do or change in your boot image or system partition your device will not boot up anymore but turning off right after showing you that device corrupt message.
but if you do that trick as written in step 1.1 and that message appears at every boot up then most likely you're goot to go...
You can find some video guides on my thread for the above steps: https://forum.xda-developers.com/lg-k10/how-to/friendly-root-method-lg-k8-k10-t3531223
Pricniple of the installer - rce_univ.zip
What the script does:
Install rce_univ.zip before SuperSU:
1. Finds the boot partition (same way as SuperSU)
2. Dumps the boot image and unpacks it
3. Determines the format the ramdisk was compressed in
4. Uncomresses it then recompresses to gzip (so SuperSU can handle it).
5. Repacks the boot image and flashes it back on boot partition
Here is where you install SuperSU
Install rce_univ.zip after SuperSU:
1. Finds the boot partition
2. Dumps the boot image and unpacks it
3. Reads back the original format of the ramdisk compression
4. Uncomresses it then recompresses the ramdisk with the original compression method(so now the device can handle it).
5. Repacks the boot image and flashes it back on boot partition
As about me:
I was not a complete noob when i started it however it took a lot of effort and time. If you care to understand a bit more what it's about and you want to follow my struggling this is where it started (you can click through the threads):
https://forum.xda-developers.com/apps/supersu/supersu-v2-66-installed-lz4-compressed-t3296508
didn't work at samsung galaxy S2, it only have 8Mb space at boot partition. any solution ?
edit i use LineageOS 14.1 (cm 14.1) android 7.1.1
haris1976 said:
didn't work at samsung galaxy S2, it only have 8Mb space at boot partition. any solution ?
edit i use LineageOS 14.1 (cm 14.1) android 7.1.1
Click to expand...
Click to collapse
Can attach recovery log? And maybe boot image that you backed up in TWRP
this recovery log
haris1976 said:
this recovery log
Click to expand...
Click to collapse
I can not fully open it (no editor can fully load it). Could you zip it and attach compressed or just attach again?
gottlasz said:
Can attach recovery log? And maybe boot image that you backed up in TWRP
Click to expand...
Click to collapse
back up boot from twrp
---------- Post added at 03:23 PM ---------- Previous post was at 03:05 PM ----------
gottlasz said:
I can not fully open it (no editor can fully load it). Could you zip it and attach compressed or just attach again?
Click to expand...
Click to collapse
maybe tommorow i have bad connection when upload recovery & boot with the zip
haris1976 said:
back up boot from twrp
---------- Post added at 03:23 PM ---------- Previous post was at 03:05 PM ----------
maybe tommorow i have bad connection when upload recovery & boot with the zip
Click to expand...
Click to collapse
Okay, you can send it in PM if you want...
gottlasz said:
Okay, you can send it in PM if you want...
Click to expand...
Click to collapse
recovery & boot
haris1976 said:
this recovery log
Click to expand...
Click to collapse
Now i could open the recovery log.
Unfortunately this part means that even if it's a 3.0.2 TWRP something is missing:
"- Found boot partition at: /dev/block/mmcblk0p5- Dumping & unpacking original boot image...WARNING: linker: /tmp/boot_repack/tools/armv7/unpackbootimg: unused DT entry: type 0x6ffffef5 arg 0x560"
Maybe you should try with a newer version of TWRP if there is one.
Or if you follow my older guide which was a manual unpacking and repaking with carliv image kitchen, that could work.
Check my old guide: https://forum.xda-developers.com/lg-k10/how-to/twrp-root-lg-k8-k350n-t3475807
Anyways give me until tomorrow, ill take a look at the script maybe i can avoid this error.
gottlasz said:
Now i could open the recovery log.
Unfortunately this part means that even if it's a 3.0.2 TWRP something is missing:
"- Found boot partition at: /dev/block/mmcblk0p5- Dumping & unpacking original boot image...WARNING: linker: /tmp/boot_repack/tools/armv7/unpackbootimg: unused DT entry: type 0x6ffffef5 arg 0x560"
Maybe you should try with a newer version of TWRP if there is one.
Or if you follow my older guide which was a manual unpacking and repaking with carliv image kitchen, that could work.
Check my old guide: https://forum.xda-developers.com/lg-k10/how-to/twrp-root-lg-k8-k350n-t3475807
Anyways give me until tomorrow, ill take a look at the script maybe i can avoid this error.
Click to expand...
Click to collapse
Same error for me on LG K8 4G Vodafone Spain (LGK350n, build MRA58K, MT6735, Android 6.0), i fix it change booting the TWRP image to k350n10f (k8_10f_twrp.img, https://forum.xda-developers.com/lg-k10/development/recovery-twrp-3-0-2-lg-k8-k350-mtk-t3517894). It avoid for me" Error: Unpacking boot image failed!- Aborting..."
Works like a charm!!! thanks to gottlasz and XDA group!
sorry for my english
You should recompile all the used binaries as static, that should avoid a lot of issues.
Also, don't bother with older Samsung (everything before S3) and older Sony devices (not really sure until when). These use non-standard boot images that are very tricky to patch without outright recompiling. It can be done - I have done it in the past - but it is a major hassle and very errorprone.
Chainfire said:
You should recompile all the used binaries as static, that should avoid a lot of issues.
Also, don't bother with older Samsung (everything before S3) and older Sony devices (not really sure until when). These use non-standard boot images that are very tricky to patch without outright recompiling. It can be done - I have done it in the past - but it is a major hassle and very errorprone.
Click to expand...
Click to collapse
Thank you Master!
I know about the compiling situation, however the problem is that i did not compile anything since the whole stuff is based on jcadduono's LazyFlasher. He compiled the binaries I only tweaked the script and added some stuff... i don't have the resources to compile. Now i'm collecting static binaries to exchange them in the installer in order to solve these compatibility issues.
Basically i just wanted to help some of those unfortunate as me who has lz4 or other compressed ramdisks and unable to intall SuperSU. Well..., at least a handful of them.
New version is up. A few TWRP related compatibility issues are solved.
gottlasz said:
New version is up. A few TWRP related compatibility issues are solved.
Click to expand...
Click to collapse
i test the new version but no luck
this is the recovery log
haris1976 said:
i test the new version but no luck
this is the recovery log
Click to expand...
Click to collapse
How far does supersu intaller goes?
I mean can it unpack your boot image?
Install only supersu and make a recovery log please.
I tried to unpack your boot image with carliv image kitchen and no luck...
I think supersu can't even unpack your boot image and then there is no chance to install it. Even if we could change the ramdisk compression...
Are you sure supersu intaller gives you the same error message as it is stated in the OP?
I believe you have a non standard boot image as chainfire talked about.
It works great on 7.1.1 roms on Note 4 n910v. Thanks!
Hi,
my Samsung GT-I9001 runs with LineageOS 14.1 (Nougat 7.1.2):
https://forum.xda-developers.com/ga...opment/i9001-lineageos-galaxy-s-plus-t3793783
As recovery TWRP 2.8.1.0 (F2FS-support) is installed.
Wenn trying to install Magisk 19.3 using magisk-v19.3.zip via TWRP it does not work: Error message ""Error execute updater binary in zip" and no flash is done.
Any idea what is the reason? The TWRP 2.8.1.0 is the latest version I found for the I9001.
The I tried patching the stock-bootloader via the Magisk-Manager. The bootloader-file is a .tar-file, e.g. in
https://forum.xda-developers.com/showpost.php?p=24831012&postcount=1330.
Magisk works with .tar, too, but seems to exspect an .img-file inside. But inside the I9001-"Boot_loader.tar" is no .img-file but 3 .mbn-files and 1 .bin-file.
So I am asking for help. Is there no way using Magisk with the I9001 (and LineageOS 14.1/TWRP)?
You're not supposed to use the bootloader, but the boot image. Two very different parts of the system setup...
And since you have such an old TWRP you're going to have to use the patching method, but it is very far from certain that your device is compatible. Only way to know is to try though.
Oops. Sorry, my mistake. I am a newbie with this and until I was not aware of boot.img ... I supposed it as the "real" filename of the bootloader. And again learning something new. Thank a lot for teaching.
Fortunately I have made a backup of the stock-ROM with TWRP before flashing the ROM. In the backup I find the file boot.emmc.win. This seems to be the stock-boot.img. Is it corrcect that I only have to rename the file to boot.img?
If the I9001 is not compatible with Magisk, means patching of the boot.img would result in a not working code/boot.img (the patching-procedure itself worked w/o errors, but does thos mean, that the result is o.k.?) - is the real risk bricking the device?
That should be the boot image and it should work fine by just renaming it. But, if it's the boot image from the stock Samsung system it won't work with LineageOS. You'll find the boot image for the ROM inside the ROM zip.
If the boot image is incompatible the Manager will let you know by an error message. Save the installation log if that happens and it could possibly tell you in more detail what went wrong.
If everything goes smoothly and the Manager manages to patch the file without issue and you still end up not being able to boot your device after flashing it you can simply restore the unpatched boot image and everything will be back to normal again.
Thanks for the further explanations. But I am not sure understanding correct.
In my understanding of the Magisk-installation manual I have to use the original boot.img always, in every case.
Do I understand correct that this understanding is wrong and that I have to use for patching with the Magisk-Manager the specific boot.img of the actual running OS? So I have to extract the boot.img of the lineageos-14.1-.tar-file (or rename the boot.emmc.win from one of my later backups of the lineagos-14.1-system)?
I have tested patching meanwhile with the "original" boot.img from the old ("original") backup and also with a boot.img extracted from a complete stock-ROM I have found in the web. Magisk Manager patched both fles w/o problems.
btw: Need the patched file the name "boot.img" or doesn´t matter the ame of the patched file (when flashing with fastboot or Odin)?
Unfortunately - or fortunately - I was not able to flash the patched boot.img to the i9001:
adb can communicate with the i9001 when it is running normal (USB debug enabled) and attached via USB. But although Odin is realizing the i9001 attached in download-mode (what means that the USB-cable is working and the driver are installed) fastboot does not realize the i9001 attached in download-mode. I have tested a lot of cables, ports and USB-drivers - no success.
So I tried to flash the boot.img with Odin. For this the boot.img must be converted to a .tar- (or .tar.md5-)file. When searching for converting-tools I found the explanation how to change the output-format of the patched boot.img in Magisk-Manager to .tar. Unfortunately I do not find this option in the current/latest version of Magisk-Manager. What is wrong - is there a secret, a hidden way to activate this option or is this option available in older versions of Magisk Manager only - and if so can I use an older version only for patching and getting a .tar-boot-image-file?
What the documentation is talking about is indeed the untouched boot image of your currently running OS. Don't mix and match.
When flashing with Odin the image indeed need to be in tar-format. With the current Manager there is no option to change the output format because the Manager will take care of that itself. Feed it a tar file and it'll output a tar file. Unfortunately you'll likely get plain image files from the TWRP backups, so those files will be no good unless you convert them before patching.
But, you might not have to use Odin since you have TWRP. It can flash the patched boot image for you. No computer required...
Again thanks a lot for this teaching. I am a newbie in modifying, tuning, flashing smartphones, and although I have learned a lot in the last weeks there are yet a lot of thing I do not know.
I know that I can flash new OS as .zip-file with TWRP (and other files if the manual says that I have/can do it with TWRP ) but I did not know that I can flash with TWRP a boot.img-file. So I would like to ask for a brief guide how to do this. Or is this the same procedure as flashing any .zip-file?
Addition 1: TWRP 2.8.1.0 does not see/list the .img-Files ....
O.k., found in the web: Directly flashing .img: Version 2.8.4.0 and above ....
So I am back again where I started ... fastboot does not see the i9001 and Odin needs a .tar ...
Addition 2: In reg. of the boot.img of the actual used OS:
I have looked into the "original" flashed lineage-14.1-20180523-UNOFFICIAL-ariesve.zip and found the boot.img. But this boot.img is smaller (4.670 byte) than the boot.emmc.win of it´s backup (5.120 byte). In fact every boot.emmc.win of every TWRP-backup (doesn´t matter what OS I have tested) ist 5.120 bytes and larger than the boot.img of the .tar/.zip-file for flashing (different sizes). So if the files are not identical - how can just simply renaming the boot.emmc.win in boot.img result in a valid boot.img?
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Didgeridoohan said:
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Click to expand...
Click to collapse
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
MarkFalk said:
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
Click to expand...
Click to collapse
Yes. I'm going to forcefully introduce my palm to my face for a moment... Forgot about that tiny but crucial detail.
Just use the boot image file from the LineageOS zip. Patch it and flash the patched image to your device. If you can't get that working I'm going to have to hand this over to someone else, because I have practically zero knowledge on working with Samsung devices and their shenanigans.
Thanks. The small detail of "flashing" into the i9001 is the remaining problem.
As said fastboot does not see the i9001 in it´s download-mode although Odin sees the device and can flash e.g. the bootloader. Odin on the other hand needs a .tar-file and I do not find a way how to converting the (patched) boot.img into a .tar-file that Odin would accept as valid file.
In these cases I usually ask someone like @jenslody or @ianmacd. They usually have a lot more knowledge about Samsung stuff...
I have found a workaround:
1. Make a pure boot-backup with TWRP
2. Copy the backup-folder into/with a new name
3. Copy boot.emmc.win and boot.emmc.win.md5 from the backup to pc or root
4. Rename boot.emmc.win to boot.img
5. Patch boot.img with Magisk-Manager
6. Rename the result to boot.emmc.win
7. Copy boot.emmc.win to the new backup-folder
8. Make a RD5-hash of boot.emmc.win
9. Replace the hash in boot.emmc.win.rd5 with the new hash
10. Copy boot.emmc.win.rd5 to the new backup-folder
11. Boot into TWRP and restore boot from the new folder
It works with the i9001 and lineageOS14.1 and TWRP 2.8.1.0 and the newest Magisk, but it should work with all devices.
I just found out my Dad is still running Magisk 17.1, wich is
a) totally out of date
b) not supported by up-to-date Managers
So obviously i want to upgrade the whole setup, but i run into the following problem:
The installed magisk manager 6.0.1 only offers me to update the manager - but the new Manager Version not compatible with Magisk-Versions below 18, so the update breaks the setup and i need to manually downgrade the Manager-Version to get the setup working again.
I need to first update Magisk and then update the Manager.
Is there any way to do this via the Manager?
(Due to the lack of a proper recovery for his model, i can't just flash an up-to-date version of magisk. It has to be done using the working System with Magisk 17.1 and Manager 6.0.1 - or any MagiskManager Version that is compatible with Magisk 17.1)
Download the Magisk zip and then install it from the Modules section of the Magisk Manager (press the "+" button and then select the zip).
Thanks for the answer, unfortunately, the installation via your suggestion fail with the error "Unable to detect target image"
In that case the device might not be compatible with the current Magisk releases... Unfortunately.
What version did you try to install? Give the Canary release a try (use this link as the custom update channel: https://raw.githubusercontent.com/topjohnwu/magisk_files/master/canary_builds/canary.json).
You can also try patching the boot image with the Magisk Manager and then install the patched image manually. More details on that here:
https://topjohnwu.github.io/Magisk/install.html#boot-image-patching
If you can't get things working, make sure to save the installation log and post it here. Might give some answers...
I tried to install all Magisk release Versions from 17.2 up to 19.3, all brought up the same error.
At first i didn't want to flash anything because the bootloader was locked and i didn't want to loose the data, but fortunately the stock-recovery provides a pretty good backup solution for user-data,
So i gave it a try:
When i fastboot-flash a patched boot image (Stock boot image patched with Magisk 19.3 by Manager 7.3.2 on a different mobile), it seems to work, but during the first (re)boot, the system somehow overwrites the patched boot-partition with the original(At least, judging by the screen flicker, he kind of reboots twice), and i end up without root...
I know that, e.g TWRP patches the system during first boot, to prevent being overwritten this, but i don't know what exactly they do - and more important, since the first flash, i completely lost the root-access, so i probably wouldn't have sufficient right's to do so.
The only time i might have root access is in the unlocked bootloader, which afaik does not provide a USB-remote Shell or something like that to manipulate the system
Additionally i wasn't able to find any working curstom recovery (neither TWRP nor CWM, nor any other) i could use...
(Since i lost root access, i can't retry the installation via Manager and so i can't provide the installation logs)
If you had the bootloader locked when trying to update to a newer release that might have contributed to the issues you had, but that's not really my area of knowledge so don't quote me on that...
It's really hard to say what it could be. There are a few more things you can try, like using the Canary build I talked about and linked earlier (currently at v19.4, build 19307), saving the log when you patch the boot image (this can be done directly from the Manager, doesn't matter what device you do it on), etc.
How did you root the device in the first place, and what device and setup are we talking about?
It's a Wiko Pulp (presumably also called Wiko Pulp 3G) with Android 5.1 (and very little Wiko-Bloatware)
Unfortunately i can't remember how i managed to root it in the first place - that was around two years ago, though i still have the Stock and patched boot images from back then.
I will give that a try, when i can spare some time during the next few days...
As i said, currently, without root, i can't try to install it via the Manager...
Sorontik said:
As i said, currently, without root, i can't try to install it via the Manager...
Click to expand...
Click to collapse
Yes you can... I'm talking about the "Patch boot image" option. That is always available.
Ok, funny thing:
I installed the new Magisk-Manager 7.3.2 and patched the Stock boot.img again (find the log below). I then bootet into bootloader, flashed the patched boot.img, just as i did before. After booting into the normal system again, i was horrified to find it working...
However, after connecting to my Wifi and installing the full Manager, it offered me an Update to Magisk19.4 which failed with "unable to detect target image".
I rebootet the phone and started Magisk Manager again, only to be greeted with a request to update the MagiskManager, which i did.
And now i still have a Magisk-manager 7.3.2 installed, that now states the installed Magisk-Version 19.3 as up-to-date and does no longer offer an update to 19.4.
When i now try to Install Magisk via the app (should do any harm to install the same version again, should it?) i again get the Error message
! Unable to detect target image
! Installation failed
Click to expand...
Click to collapse
which is the only content of the magisk_install_log
So now i have a up-and-running installation of up-to-date Magisk and Manager, but I'm afraid that i will run into the same problems again the next time i want to update Magisk
Btw: I really don't like to flash a new boot.img every time since that leads to a complete data wipe
magisk install log of the successful image-patching:
- Device platform: armeabi-v7a
- Downloading zip
... 0%
- Copying image to cache
1022+1 records in
1022+1 records out
1047368 bytes transferred in 0.028 secs (37406000 bytes/sec)
- Unpacking boot image
Parsing boot image: [/data/data/com.topjohnwu.magisk/install/boot.img]
HEADER_VER [0]
KERNEL_SZ [5701056]
RAMDISK_SZ [842982]
SECOND_SZ [0]
EXTRA_SZ [0]
RECOV_DTBO_SZ [0]
DTB [0]
PAGESIZE [2048]
NAME [WIKO]
CMDLINE []
CHECKSUM [0e654fea06ed05244b9b6e7f0d90bf]
MTK_KERNEL_HDR
KERNEL [5700544]
NAME [KERNEL]
MTK_RAMDISK_HDR
RAMDISK [842470]
NAME [ROOTFS]
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
Kernel is uncompressed or not a supported compressed type!
- Checking ramdisk status
Loading cpio: [ramdisk.cpio]
- Stock boot image detected
- Backing up stock boot image
- Patching ramdisk
Loading cpio: [ramdisk.cpio]
Add entry [init] (0750)
Patch with flag KEEPVERITY=[false] KEEPFORCEENCRYPT=[false]
Loading cpio: [ramdisk.cpio.orig]
Backup mismatch entry: [init] -> [.backup/init]
Create directory [.backup] (0000)
Add entry [.backup/.magisk] (0000)
Dump cpio: [ramdisk.cpio]
- Repacking boot image
Parsing boot image: [/data/data/com.topjohnwu.magisk/install/boot.img]
HEADER_VER [0]
KERNEL_SZ [5701056]
RAMDISK_SZ [842982]
SECOND_SZ [0]
EXTRA_SZ [0]
RECOV_DTBO_SZ [0]
DTB [0]
PAGESIZE [2048]
NAME [WIKO]
CMDLINE []
CHECKSUM [0e654fea06ed05244b9b6e7f0d90bf]
MTK_KERNEL_HDR
KERNEL [5700544]
NAME [KERNEL]
MTK_RAMDISK_HDR
RAMDISK [842470]
NAME [ROOTFS]
KERNEL_FMT [raw]
RAMDISK_FMT [gzip]
Repack to boot image: [new-boot.img]
HEADER_VER [0]
KERNEL_SZ [5701056]
RAMDISK_SZ [1070689]
SECOND_SZ [0]
EXTRA_SZ [0]
RECOV_DTBO_SZ [0]
DTB [0]
PAGESIZE [2048]
NAME [WIKO]
CMDLINE []
CHECKSUM [82d96388233c95f59faebde95033159c5e7ca98f]
****************************
Output file is placed in
/storage/sdcard0/Download/magisk_patched.img
****************************
- All done!
As it looks right now you are going to have to do the patched image approach, since Magisk doesn't know where to find your boot image. I don't even know where to start fixing that (not my area of knowledge)... You'd need to know the proper location, open a GitHub issue and hope that it's trivial enough for it to be worth it for @topjohnwu to fix it. There are plenty of weird edge case devices that just aren't worth the effort to try to support fully...
The v19.3 vs v19.4 version misch-masch has to do with stable and Canary releases. Somehow your update channel must have been set to the Canary release and that's why it was offering v19.4 (which is the current Canary). Later it got reset to the stable channel and now you see v19.3.
Thank you for your help and patience!
I just opened a github-ticket with all the information i could find by now, hopefully John can make it work.
Sometimes manager shows suggestion to upgrade itself to newer version. You do it and you have unstable system, because it did not upgrade magisk (magisk has new version to but manager does not inform about when suggests to upgrade manager). System is enough unstable and you will not be able to upgrade magisk from inside.
The only way, ALWAYS ignore hints to upgrade manager because you will have big work to fix it. aALWAYS!
Hi, i tried many times to use MAGISK app on a tablet ASUS FONEPAD 7 (model K00E) with Lollipop in order to patch the BOOT.IMG.
Always failed during the patching, with the messages:
DEVICE PLATFORM: x86
COPYING IMAGE TO CACHE
UNPACKING BOOT IMAGE
CHECKING RAMDISK STATUS
STOCK BOOT IMAGE DETECTED
PATCHING RAMDISK
REPACKING BOOT IMAGEUNABLE TO REPACK BOOT IMAGE!
INSTALLATION FAILED
I have searched for all the possible articles etc, without success.
I have tried many different versione of MAGISK, the last 20.4 and MANAGER 8.0.2 (i have used MAGISK install >> go >> method select and file update >> boot.img)
Obviously i have the original BOOT.IMG file, loaded on internal memory.
Please, may you help me?
Thanks in advance
Marco G
That's a pretty old device, and since Asus has been known to not quite follow Android standards I wouldn't be surprised if it's simply not compatible...
Since you say that you used Magisk v20.4 it might be worth it to try the Canary build (just in case there's been some kind of improvement upstream). You can find the Canary Manager on GitHub:
https://github.com/topjohnwu/Magisk
And providing the actual installation log is always a good idea (there's a disc icon in the flashing window).