This boot.img, attached, provides a root shell directly over adb. It is a simple modification of the stock XXALJL boot.img and could be useful for ROM developers who need to adb remount frequently, while still using the stock boot/kernel. I do not recommend this method for users in general since it is very insecure (SuperUser gives you more fine-grained permission control).
Flash it with Odin or under Linux:
Code:
heimdall flash --18 XXALJL-rooted.boot.img
WARNING: contrary to the system.img root method, this WILL increase your download count!
EDIT: in fact it would be better to simply dd the img file into mmcblk0p20, should not increase the download count.
Be careful, this also disables auto updates (now it says the device has been modified, and won't allow OTA updating).
xd.bx said:
Be careful, this also disables auto updates (now it says the device has been modified, and won't allow OTA updating).
Click to expand...
Click to collapse
are you tested if work with custom recovery ?
xd.bx said:
This boot.img, attached, provides a root shell directly over adb. It is a simple modification of the stock XXALJL boot.img and could be useful for ROM developers who need to adb remount frequently, while still using the stock boot/kernel. I do not recommend this method for users in general since it is very insecure (SuperUser gives you more fine-grained permission control).
Flash it with Odin or under Linux:
Code:
heimdall flash --18 XXALJL-rooted.boot.img
WARNING: contrary to the system.img root method, this WILL increase your download count!
Click to expand...
Click to collapse
I just dumped your image and....
Forgive for being i bit confused but in order to have a rooted Insecure image don't you need to set ro.secure=0?
This your Default.prop dumped from your image
Code:
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=1
Also why is there no root binarys in the image?
So, as far as i can see the only thing this image will do is increase you binary count, nothing else.
If im wrong i apologize in advance.
faria said:
So, as far as i can see the only thing this image will do is increase you binary count, nothing else.
If im wrong i apologize in advance.
Click to expand...
Click to collapse
I did try setting ro.secure to 0 but it didn't work. So I simply patched the setuid/setgid arm instructions inside adbd so that it never drops its privileges, no matter what. (it's very straightforward to do with objdump+a hex editor).
spawk said:
are you tested if work with custom recovery ?
Click to expand...
Click to collapse
I haven't, no.
xd.bx said:
I did try setting ro.secure to 0 but it didn't work. So I simply patched the setuid/setgid arm instructions inside adbd so that it never drops its privileges, no matter what. (it's very straightforward to do with objdump+a hex editor).
Click to expand...
Click to collapse
I see,
I believe that the best way to achieve what you want is to split the boot image ,then dump the the ram disk, edit its contents then rebuild the image.
I have wrote a linux script that does all of that if you are interested .
faria said:
I see,
I believe that the best way to achieve what you want is to split the boot image ,then dump the the ram disk, edit its contents then rebuild the image.
I have wrote a linux script that does all of that if you are interested .
Click to expand...
Click to collapse
Thanks, indeed I am. BTW I just realized it would be much better to root through system.img and then flash by using dd into mmcblk0p20. This way the download count should stay the same.
xd.bx said:
Thanks, indeed I am. BTW I just realized it would be much better to root through system.img and then flash by using dd into mmcblk0p20. This way the download count should stay the same.
Click to expand...
Click to collapse
Our current method of rooting, using the System image does not increase the binary count.
Here is the script
You will need the abootimg tools installed in linux.
unzip the package ,delete everything inside the folder except the unpack file.
Copy the boot.img to the folder.
double click on the unpack file and launch as terminal
Follow the instructions in terminal window.
Related
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Binary100100 said:
It's possible. In fact I mentioned this about a month ago to a developer.
I would like to see one that has a couple of options such as flashing recovery and flashing boot.img files.
You can easy push the flash_image binary to /system/bin and set the permission to 755. In fact my CWMFaux kernel does just that. Faux stopped using it because it doesn't always work.
In fact I made it so easy that all you need to do is push the boot.img to /system and reboot. Yet... no one uses it. In fact I suggested to a couple of rom developers to simply add the binary file to /system/bin so that you can at least run the command from terminal but they don't even want to do that. I like being able to update my recovery at anytime by entering "flash_image recovery /sdcard/recovery.img" and then just rebooting to recovery. You can easily do that for kernels too. But I suppose it's so much easier to carry a computer around.
Click to expand...
Click to collapse
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Keep me posted will ya?
I believe that Faux and other developers would have to use the zImage kernel flashing technique to get it to work with his existing app but I'm sure he can simplify it to accept .img files and the .ko files in the /system/lib directory of a zip file. It actually should be very easy. It took me about ten mintues with testing included to create the script for my method. I just can't code for apps else it would be done by now.
DEFINITIONOFREAL said:
Im going to contact joeykrim and see if I can get him to add support in his app, and Ive been using your method since I got the phone (2 days ago) and started reading, but still a little hassle, and a big htc fail
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
I contacted pershoot, no answer lol!!!
Joeykrim is willing to support the Amaze, he just needs testers, this would be a great backup incase the new script failed to push the kernel. I'll keep everyone posted with updates
Sent from my HTC Amaze 4G using XDA App
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I've been working with joeykrim getting his app setup for our device, it looks like it should work, hopefully, within the next couple of days we can get this working and released
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Binary100100 said:
That would be wonderful!
I'm tired of having to repeat myself.
flash_image boot /sdcard/boot.img
flash_image recovery /sdcard/recovery.img
Click to expand...
Click to collapse
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
DEFINITIONOFREAL said:
I just wish the devs would use your script, it would make things so much easier
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
seansk said:
could a script be written to automatically flash these while installing/flashing the custom rom? This would cut down atleast the step for flashing kernels for a lot of noobs!!
Click to expand...
Click to collapse
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Binary100100 said:
Actually, yes! I did add it to the init.d script but since xboarder had removed the init.d scripts from his rom it doesn't work anymore. But you sure could. It was basically how I was setting up my CWMFaux kernels. However it didn't seem to work 100% of the time. Couldn't figure out why.
It basically worked like this...
Flashing the CWM custom kernel .zip via recovery.
copies boot.img to /system
copies init.d 06tweaks script to init.d folder.
copies and set permissions for flash_image binary and kernelupdate script to /system/bin directory.
You then boot your phone up which triggers the init.d script which commands the kernelupdate script to initiate. The kernel update script is simply using the flash_image binary command "flash_image boot /system/boot.img" and it automatically updates the kernel. Then the init.d script removes the boot.img file from the /system directory to keep it from flashing upon every boot.
I would like to change it to /sdcard directory but there's the problem that the sdcard doesn't get mounted until the very end. WAY after the system. Which is why I stored it there. The system gets mounted even before the data partition so I couldn't even store the file in data because the script would run even before the data partition could mount. Basically the script is initiated while your still looking at the boot animation. Pretty much when your softkey backlights and led light comes on it flashes the new kernel. It's a pretty neat workaround if I must say but unfortunately nowhere near perfect and not even close to having an s-off workaround.
Now if you don't mind the fact that it won't be initiated upon boot I could make it so that it will flash any file in a perspective folder on the sdcard.
example:
kernelupdate would update the kernel with any *boot*.img file located in a certain directory... say /sdcard/kernel
recoveryupdate would update the recovery with any *recovery*.img file located in a certain directory... say /sdcard/recovery
The problem:
Some people would want to collect their kernels and recoveries and store them in those directories. That would NOT be possible since using the command "flash_image recovery /sdcard/*recovery*.img would flash any img file with the word "recovery" in it. So if there's more than one it would error out and not flash anything because of the conflict. Same principal with the kernel only MOST kernels are simply named "boot.img" where-as almost all recovery files have a unique name since they are all already custom.
Click to expand...
Click to collapse
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
seansk said:
quite a dilemma, I wonder if we could add pause to the script until everything is loaded on the first boot then after the pause the script flahes the recovery and more importantly the kernel!!! if this was possible we could keep the files in a separate place on the SD card.
Still nothing like S-off!!! Thanks HTC for being so dev friendly
Click to expand...
Click to collapse
I'm sure there's a way to add a delay timer of some sort. I'm just not that savvy. Easiest way would be through an app like Tasker.
DEFINITIONOFREAL said:
Would this be a possible solution to our kernel flashing problems, I know it works for the evo
Sent from my HTC Amaze 4G using XDA App
Click to expand...
Click to collapse
The short answer is yes!
I've setup the application to support the HTC Amaze 4G, but before I release it publically and officially, I want to have a few testers confirm everything is working properly for them.
Posted all the information in a new thread as this one seems to be covering a few different topics so I didn't want to "hijack".
http://forum.xda-developers.com/showthread.php?p=21574722
Thanks for the request and for reaching out to me DEFINITIONOFREAL.
Binary100100 said:
Once I see that they do I can work out something else like:
kernelupdate
recoveryupdate
kernelupdate would be
flash_image boot /sdcard/kernel/*boot*.img
recoveryupdate would be
flash_image recovery /sdcard/recovery/*recovery*.img
So that if you place ANY of the appropriate img file in the perspective folders on the sdcard partition it would flash the .img by just entering either of the two commands from adb shell or terminal.
But I'm not going to waste my time if the devs don't want to use it.
Click to expand...
Click to collapse
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
joeykrim said:
I think my application, Flash Image GUI, will be the best alternative, but of course I have a biased opinion!
Regarding alternatives, I think a simple sh script which takes an argument would make a nice wrapper. The argument would be location to the image file to flash. The script could either bundle the flash_image binary or take the location of it as another argument.
All depends on how the developers want to create some type of standard. Which is another great reason Flash Image GUI will work well as it contains everything required and doesn't rely on developers providing support in their ROM, only relys on developers following the standards for ROMs and kernel .zip files.
Also, in looking through some of the custom ROMs and kernel .zip files for this device, I notice one of the custom kernels does something similar to the suggestions above, it executes a file located in /system/etc/init.d on every boot which automatically flashes /system/boot.img file.
At first glance I was horrified to see this as this is a *major* security issue. If anybody were to place any type of file in /system/boot.img, either a rogue kernel or just a blank file, the script automatically flashed it on boot w/o any type of file verification or user notification!
Wanted to get that off my chest and discourage the use of *automatic* loading of any type of major file, such as kernel or recovery image, especially without at least file verification or user approval/notification.
I'll try and keep up with the thread and help contribute ideas to alternatives for anybody who wants to develop/implement! Great ideas in the thread and always enjoy reading community collaboration efforts, especially in resolution to manufacturer "adjustments" of standards.
ugh, sorry about the double post (too excited for being too early in the morning). if a moderator wants to combine my last two posts, please do. i dont have access to delete a post.
Click to expand...
Click to collapse
I look forward to tryin out your app.
It was basically what this thread was all about in the first place.
The clockwork method that you mentioned is the only workaround that I was able to come up with for custom kernels (like Faux123) because a kernel cannot be flashed through recovery without s-off. Really stupid. So I started thinking "How can we flash a boot.img file from recovery without the typical means?" Then came up with the solution to flash_image the boot.img file automatically IF the file is detected. But how to start a script automatically upon boot? init.d is the only way I could think of. Okay... so where to put the boot? I tried the sdcard but it failed to mount until it was way too late. So... data. Nope... still didn't mount in time. Cache? Well... how many developers will include a cache file into their roms? So the only other option was /system and it seemed convenient since /system mounts BEFORE the script can run (obviously) so that's why it is as it is. I also figured "If someone wants to flash a new kernel all they need to do is push the boot.img to /system and reboot." Must easier than using the EKF method (requiring PC access) and I don't know about you but I'm not around a computer 24/7.
To get a privileged shell you need to modify the following lines to the given values in the default.prop file
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
Click to expand...
Click to collapse
I have the extracted the recovery image of my phone model : So is it possible to modify the following values in the default.prop file, repack the image and flash it using fastboot(bootloader is unlocked) to get a privileged shell, and then copy the su binary after remounting system as read/write?
Do I need to change any other values in any of the files? And will it work, theoretically at least?
What are the chances of it messing up anything?
[I posted this on android.stackexchange but not much activity there]
No chances of bricking at all
Going further I would suggest you to tag in a shell script within init.rc so that it copies superuser apk and binary automatically as you boot
That's great
And is there any way to confirm that the recovery (downloaded) that I have is indeed from my device? Is the data within the prop files such as build and model no. etc enough?
Sent from my A9 using xda app-developers app
It didn't work. Either it wasn't the stock recovery in the first place, or the process isn't that easy. This can be closed now.
Modify boot.img
I think it is only the boot.img which is to be flashed. You don't need to flash recovery as whole.
If you have root access, you could manually edit default.prop. But, the modifications exist only till reboot. Once you reboot, boot.img will reload all the necessary system files to original. So, edit boot.img.
Adriel David said:
Hello I want to modify default.prop to modify it I need root access now I rooted my phone and cwm installed I want to make a flashable zip backup of default.prop can you provide me the script to be flashed by cwm because I am afraid bricking my phone
Click to expand...
Click to collapse
default.prop is on ramdisk or initrd which is part of the boot.img.
I use abootimg to edit boot, some use mkbootimg. Google editing initrd will give you info you need
varun.chitre15 said:
No chances of bricking at all
Going further I would suggest you to tag in a shell script within init.rc so that it copies superuser apk and binary automatically as you boot
Click to expand...
Click to collapse
Sorry to call on such an old post, but wouldnt this mean that on each boot (if modified on boot.img. On each fireup of recovery if on recovery.img) the superuser apk and binaries are reinstalled? Because this /is/ init.rc we're referring to. Please correct me if I am wrong, and also tell me if this is the best way to go about it I'm trying to come up with a way to root my device without using dirtycow haha
Hi all, researcher and enthusiast,
I own a complete backup of all partition of the LG P990 with stock ICS, made it with nvflash with a command like this,
Code:
nvflash -r -read <-partition number-> my_partition.img
for all the partition listed in the partition table.
I guess that in someone of that raw image file, (outputted by nvflash), is located the entry system partition, (PartitionId=23 for the LG P990 ICS partition layout).
It's easy for every linux user to mount the raw image file, simply with 'mount' utility.
Browsing them we can find as already hypothesized the entrie android system partition!
If I copying in it the 'su' executable compiled for my platform, it could work?
Yes. Simple as that. Just be careful with permissions.
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Do not say "thanks"; just press it under here.
louiscypherbr said:
Yes. Simple as that. Just be careful with permissions.
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Do not say "thanks"; just press it under here.
Click to expand...
Click to collapse
Thanks! I'll have a close look to your work now, for others that consider this stuff interesting, louiscypherbr's work is here:
http://forum.xda-developers.com/showthread.php?t=2010671
Nice job!
louiscypherbr said:
Yes. Simple as that. Just be careful with permissions.
Click to expand...
Click to collapse
Ok louis, but the partition23 image file after adding su binary or other things is bigger than the previous that we had read with nvflash, right?
If I flash back it with
--bl fastboot.bin --download 23 image.img
how can this work..?
In the part table is write that have been reserved 536.870.912 bytes for the partiton 23, but we want flash an img file bigger than that size (because we added some stuff), this not causes problem?
And what do you mean for careful?
The extracted file is a dd partition image, meaning it's extracted byte by byte. So it includes the empty space, which you can see with "df" command after mounting it.
You can add files that fit in that position and it will be ok when flashed.
Do not say "thanks"; just press it under here.
Stupid thing! You're right!
And, what you mean for careful with perm?
The su binary should be have the setuid bit set in addition to the obvious x, is this enough?
Have you compiled su by yourself...?
louiscypherbr said:
There's a topic I made on the ancient v28g time with stock v28g rooted system, on dev section. There you'll find useful info.
Click to expand...
Click to collapse
Where have you found the executable of su packed in your v28g louis...???
Hey, sorry for being far from this.
What I was talking about permissions is that you should keep su permissions/owner. I did this just copying the su from a rooted Rom zip to /system/xbin and pasting inside your loop mounted /system with file manager (I'm kde fan, so I used dolphin, the kde graphical file manager, but you can use any other as well).
Sent from my LG-P990 using xda app-developers app
I want to root my redmi6a but it has no boot ramdisk so I'll have to root it via recovery.img but i can't seem to find it on the stock firmware zip any help would be appreciated thanks!
To root Android you neither have to fiddle around with phone's boot.img nor with phone's recovery.img. Rooting Android simply is adding a binary called su to Android's filesystem and make it executable. This can get achieved by means of ADB.
xXx yYy said:
To root Android you neither have to fiddle around with phone's boot.img nor with phone's recovery.img. Rooting Android simply is adding a binary called su to Android's filesystem and make it executable. This can get achieved by means of ADB.
Click to expand...
Click to collapse
I mean i want to root it with magisk
I've spent last day automating the guide at https://forum.xda-developers.com/t/guide-t220-t225-flash-a-gsi-on-the-a7-lite-without-twrp.4456821/ into a bash script (linux only)!
Here it is releasing it for anyone that needs it
Code:
I am not responsible whatever happens to your device
by using this script, i have tested it on my own device
and it worked but it may or may not work for you.
I will do my best to help you but that may be limited
as i have other responsibilities in life
Before starting read the third post
UsageDownload the your desired firmware from somewhere like samfw.com and extract it
Download your desired GSI image and extract it
Download otatools-mini, gsi-build script and vbmeta image, place them all together inside one directory (extract the otatools-mini next to the script)
Download patched odin
Run this in Linux or WSL!
Code:
$ ./build-gsi.sh <PATH TO YOUR AP FILE .tar.md5> <PATH TO GSI .img>
And let it do the work, may take a while depending on your PC
You may get something like this in the process, ignore it
Code:
Invalid sparse file format at header magic
Then go into download mode (VOLUME UP and DOWN when plugging in USB) and flash the CUSTOM_AP file you got from the script and BL, CSC from the firmware you used, DO NOT USE HOME_CSC
Reboot into recovery and factory reset (VOLUME UP while booting)!
If you are getting dm-verify error then flash the vbmeta_disabled_R (it needs to be .tar, extract it) in odin as AP and try rebooting again into recovery
DownloadsI used to provide one archive but it was large and i couldnt change the script without reuploading it so i am going to use gist for the script and provide other files separately
ota-tools-mini
build-gsi.sh
Getting HelpIf you want me to help you ALWAYS post full output from the script, and make sure to use the latest script from the gist
I've spent a lot of time trying to make it work with all GSIs but i could not get it to work consistently
By default it works for all smaller GSIs, if you get the following error
Code:
ERROR: Output image is bigger than original super image, rerun the script with correct super image size
Then you will have to manually provide the new super size which i cannot help you with try to guess but it has to be divisible by 512
Not enough free space to expand partition: vendor
error while repacking
i have a lot of space . but it shows me like that
lpmake E 01-15 23:22:16 100 100 builder.cpp:698] [liblp]Not enough free space to expand partition: vendor
i am using debian wsl
Please post full script log in a spoiler or pastebin
sandorex said:
Please post full script log in a spoiler or pastebin
Click to expand...
Click to collapse
Could you try normal AP file not the magisk patched, i do not know how it modifies it
Also from my experience you do not need to patch whole AP file for magisk, you just need to patch the boot.img, zip it then flash it
OK . i will try
i tried with original ap file but same error
dxsyrz said:
i tried with original ap file but same error
Click to expand...
Click to collapse
It seems for some reason your gsi is too big, i managed to reproduce it, ill see if i can fix it
@dxsyrz can you test this one, it should work now
EDIT: i've updated the gist so you can just use that instead
good util but test more.
tom.android said:
good util but test more.
Click to expand...
Click to collapse
It worked for me, i would not release it if it did not work
sandorex said:
It worked for me, i would not release it if it did not work
Click to expand...
Click to collapse
OK sorry to write that message.
sandorex said:
It worked for me, i would not release it if it did not work
Click to expand...
Click to collapse
Well, something did not work in my case:
:: Uncompressing super image
super.img.lz4 : decoded 5637366988 bytes
:: Running simg2img
./build-gsi.sh: line 79: /mnt/c/Users/Zero/Desktop/otatools-mini/otatools-mini/simg2img: No such file or directory
^ Despite the files actually existing. You tell me cuz I've no idea (do note I do know how to do this manually, was just trying your script to simplify everything).
nirogu325 said:
Well, something did not work in my case:
:: Uncompressing super image
super.img.lz4 : decoded 5637366988 bytes
:: Running simg2img
./build-gsi.sh: line 79: /mnt/c/Users/Zero/Desktop/otatools-mini/otatools-mini/simg2img: No such file or directory
^ Despite the files actually existing. You tell me cuz I've no idea (do note I do know how to do this manually, was just trying your script to simplify everything).
Click to expand...
Click to collapse
You need to place otatools-mini in folder next to the script not together with the script
hi i have this problem
izimen said:
hi i have this problem
View attachment 5814501
Click to expand...
Click to collapse
You havs a space in your path, its actually a bug but you can jist move the files to somewhere without spaces
EDIT: Fixed it on gist
sandorex said:
You havs a space in your path, its actually a bug but you can jist move the files to somewhere without spaces
EDIT: Fixed it on gist
Click to expand...
Click to collapse
ok i try
bro it worked thank you I managed to make it work with a GSI and when I try with another I have this error