Related
Background
To update (flash) a recovery image onto your phone allows you to update or replace your recovery environment on your phone. There are a number of ways to flash a new recovery image, some of the more commonly used methods are using a tool such as ROM Manager or using development tools such as Fastboot. There is also a third method using a standalone utility "flash_image" which allows the flashing of recovery using the terminal emulator on the phone.
flash_image is not a new tool, it has been used on Android since the beginning, many custom ROMs include the utility as part of the ROM itself though not all stock ROMs (including the stock ROM on the G2) include it.
Requirements
1. A permanently rooted (with S-OFF) phone
2. The flash_image binary
3, A recovery image that is compatible with your phone and ROM
3. A terminal emulator application on the phone or use of an ADB shell
Overview:
1. Get the flash_image binary and recovery image onto your phone
2. Copy or move the flash image binary to your system and make executable
3. Use flash_image to update your recovery environment
Stage 1: Get flash_image and recovery image on your phone
1. Download the flash_image binary (not needed if you are running a custom ROM that includes this binary)
2. Download the recovery image you wish to use
You can either directly download the files onto your phone or onto your PC and transfer to your phone. Probably the easiest way to do this is to connect your phone to your computer via USB and mount USB storage, then copy the files to your SD Card. Alternatively you can use ADB Push, bluetooth file transfer or several other methods.
Stage 2: Copy or move the flash image binary to your system and make executable
In terminal emulator:
su
mount -o remount, rw /system
cd /sdcard (or wherever you downloaded/copied the file)
cp flash_image /system/bin
cd /system/bin
chmod 777 flash_image
Click to expand...
Click to collapse
Stage 3: use flash_image to update your recovery environment
In terminal emulator:
su (not needed if using the same terminal session used in the steps above)
cd /sdcard (or wherever you downloaded/copied the recovery image)
flash_image recovery recovery.img (use the appropriate file name for the image file you are flashing)
Click to expand...
Click to collapse
Reboot into recovery and verify that the correct recovery environment is installed
Notes
Any of the commands that call for using a terminal emulator on the phone should work fine using an ADB shell if you prefer.
This was tested on G2 but I can't think of why it would not work on Desire Z or any other phone for which this version of flash_image works. Obviously different phones have different compatible recovery images.
I've attached a zip file containing the flash_image binary that I extracted from the CM 6.1 update zip. I suspect most custom ROMs already have flash_image.
If you are wondering "Why should I use this method over using ROM Manager?" you could be using a recovery image that ROM manager doesn't support, for example ClockWorkMod Recovery 3.x which is required for some experimental ROMs.
If you are wondering "Why should I use this method over using fastboot?" The two main reasons are you can't use fastboot if you are not with a computer with working ADB and using fastboot requires that you have previously flashed the engineering HBOOT.
This is my first guide so I'm open to suggestions or feedback.
Nice one
Though I would suggest that
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
could be simplified to :
Code:
mount -o remount,rw /system
Edit - actually /system isn't even on /dev/block/mtdblock3, and it's not a yaffs2 file system, I suspect that's come from another phone model ?
"dd" will do exactly the same, but no need to install extra stuff since its already there.
dhkr123 said:
"dd" will do exactly the same, but no need to install extra stuff since its already there.
Click to expand...
Click to collapse
I wouldn't have a problem using dd myself. But I would have thought it was much more risky, since instead of typing something relatively user-friendly like "recovery", you're typing in /dev/xyz/abc or similar, which if you get it slightly wrong could be disastrous ?
Excellent, worked for me, flashed CW 3.0 without fastboot
steviewevie said:
Nice one
Though I would suggest that
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
could be simplified to :
Code:
mount -o remount,rw /system
Edit - actually /system isn't even on /dev/block/mtdblock3, and it's not a yaffs2 file system, I suspect that's come from another phone model ?
Click to expand...
Click to collapse
Interesting, I've been using that command since forever (since I first rooted my G1 in early 2009) and it definitely does work on my G2 as well as my wife's MT4G.
I just tried "mount -o remount,rw /system" on my phone and it does not work, mount gives me the "Usage:" messages which seems to mean it wants more parameters.
steviewevie said:
I wouldn't have a problem using dd myself. But I would have thought it was much more risky, since instead of typing something relatively user-friendly like "recovery", you're typing in /dev/xyz/abc or similar, which if you get it slightly wrong could be disastrous ?
Click to expand...
Click to collapse
Unless you run wpthis before dd, you're perfectly safe. The radio partitions are all protected by the power-on write protect feature of the eMMC AS WELL as the linux kernel write protect on low addresses. Worst you can do is blow away your system, data, cache, misc, boot, or recovery partitions, and these are trivial to recover from.
raitchison said:
Interesting, I've been using that command since forever (since I first rooted my G1 in early 2009) and it definitely does work on my G2 as well as my wife's MT4G.
I just tried "mount -o remount,rw /system" on my phone and it does not work, mount gives me the "Usage:" messages which seems to mean it wants more parameters.
Click to expand...
Click to collapse
Depends on whether or not the mount command can tell the associations between the devices and mount points, which is determined by either system configuration, or what mount command you are using (i.e. android's mount or busybox mount).
raitchison said:
Interesting, I've been using that command since forever (since I first rooted my G1 in early 2009) and it definitely does work on my G2 as well as my wife's MT4G.
I just tried "mount -o remount,rw /system" on my phone and it does not work, mount gives me the "Usage:" messages which seems to mean it wants more parameters.
Click to expand...
Click to collapse
Sorry, there should have been an extra space, this works on my phone :
Code:
mount -o remount, rw /system
I don't have a "/dev/block/mtdblock3" on my system. My system partition is mounted on /dev/block/mmcblk0p25, and it is ext3 not yaffs2.
What ROM are you running ? I am running the stock DZ 1.34 ROM. I wonder if you are running Gingerbread ?
steviewevie said:
Sorry, there should have been an extra space, this works on my phone :
Code:
mount -o remount, rw /system
I don't have a "/dev/block/mtdblock3" on my system. My system partition is mounted on /dev/block/mmcblk0p25, and it is ext3 not yaffs2.
What ROM are you running ? I am running the stock DZ 1.34 ROM. I wonder if you are running Gingerbread ?
Click to expand...
Click to collapse
I'm running the Stock G2 T-Mobile post-OTA ROM, definitely not Gingerbread.
Edit: I just tried your method and it works, I will update the guide because your way is simpler and sounds like a safer choice.
you could just rename the CW 3.x.x recovery to the exact named recovery slap it in the cloclwork download folder after you delete the old one and flash it with CW just a quicker trick for GB roms
Not sure that's actually quicker, at least I don't think it would be for me, especially if you are changing recoveries with any frequency (like if tying out Gingerbread ROMs then going back to a 2.2 ROM) because you'd need to constantly rename your recovery images. With my method you would only need to leave the two files named as they are, or for expediency you could rename to recovery.img and recovery3.img then when you wanted to switch you could just execute:
flash_image recovery recovery.img
Click to expand...
Click to collapse
or
flash_image recovery recovery3.img
Click to expand...
Click to collapse
Depending on which recovery you wanted at that point & time.
As I said in the guide, there are already a number of options available, using ROM Manager and fastboot are the most commonly seen in guides but your method and mine are other options for people for whom they work better.
Works!!!
Hi my friends!
It worked for me flawlessly. I was using virtuos 0.9 on my desireZ
Great description, but file did not work for me
It's a very good description that a novice like me can follow. And, I am sure the provided file works for many of you, since many of you reported it to work. After following this guide, and not getting it to work (Stopping Signal error), I decided to find another binary file for flash_image, and the other flash_image file worked for me on my Sprint CDMA Hero. My phone currently has aospMod v0.9.9.2 | AOSP 2.2.1(12/10/2010), if it matters.
One can download a flash_image from here http://cyanogen-files.carneeki.net/flash_image.zip
Then unzip and place on sdcard - follow all the steps in the original post of this thread.
It is my understanding that this file is not unique for different android phones, but if I am incorrect, someone please reply to this thread to correct me.
Again, great job in summarizing the steps.
Regards,
Sanjiv
so darn easy! thank you!
Also usable for splash screen ??
Just curious,
Anybody tried to use flash_image to flash a custom splash screen ?
Something like :
flash_image splash1 customsplash.img
very good post for a newbie like me, just want to make sure, do i need to do the stage 2 every time I flash the recovery?
jaoyina said:
very good post for a newbie like me, just want to make sure, do i need to do the stage 2 every time I flash the recovery?
Click to expand...
Click to collapse
No, you only need to do stage 2 once, whenever you update/change recoveries from that point forward just use stage 3.
Is there a way I can reflash a recovery without access to the ROM?
I'm stuck at the HTC splash screen, so I'm basically stuck in my current (broken) recovery.
sanjivp2000 said:
One can download a flash_image from here (..)[/URL]
Click to expand...
Click to collapse
The flash_image in the start post did not work for me, the one above did.
Also, my HTC Hero was missing the cp command.
Instead, I used: cat /sdcard/flash_image > /system/bin/flash_image
Successfully flashed recovery again
I've been searching my _ off for two days now to find a solution for my problem, but I can't find one working for me.
What I do have right now:
NO working ROM (I believe because of a failed atempt to revert to a backup in CWM)
Access to my bootloader (unlocked through HTCDev)
Access to my recovery (Which is the latest CWM)
Fastboot/adb working
Phone boots upon the HTC logo screen
NO ROM zipfile on the SD-Card (I accidentilly deleted that, I still hate myself for that)
I've managed to push to ROM file into both /data and /system, which (ofcourse) isn't usefull to flash from because they don't show up in CWM.
What I've tried:
Reverting to a Nandroid backup, I've 2 on the sdcard. Both don't pass the part where /system is being restored.
'asd shell' to push files, or mount the SD card, does not work. First I had the error saying '--exec /system/bin/sh failure: file or dir not found (2)'. I managed to push the sh file into system, (and I believe into /system/bin), and the error changed to '[...] No directory (20)'
asd push /sdcard/; doesn't work because /sdcard is read-only.
In CWM I can't mount as USB storage, is says something about a file which can't be found.
TWRP recovery doesn't work on my device, I can touch whatever I wan't, the only button responding is the power button, which causes a locked recovery, which I can't unlock. (You need to swipe for that, which my phone seems to ignore).
I've read almost every topic on XDA and whatever Google could give me, but most solutions somewhere relied on the asd shell, or pushing into the /sdcard, or simply assume I still can mount as USB storage.
Does anyone have any suggestions left on howto get a ROM into the /sdcard so I can flash it? I would be thanking you forever!
Thanks in advance!
No ADB shell, then adb push *filename* /sdcard?
Maybe sideload a ROM?
Sent from my GT-I9300 using Tapatalk 4 Beta
I can't push files to the /sdcard since it's an read-only directory.
I tried the sideload part, but instead of executing something, it shows me the help of adb.
Any clue how to fix my shell, or get a ROM on it?
Tried typing 'adb remount' a few times and trying again?
Also, you should update your CWM to latest version so you can mount sdcard
tomascus said:
Tried typing 'adb remount' a few times and trying again?
Also, you should update your CWM to latest version so you can mount sdcard
Click to expand...
Click to collapse
I tried using remount, but that is to remount the /system partition right? I can put the ZIP on the /system partition. But CWM can't install from there.
I'm using the last version of CWM, but it gives me an error about a file not being found, so I can't mound as USB Storage device.
I returned the phone, to the store. I pretty much gave up after another few hours of struggling.
hi guys, a friend of mine is asking me if there's something i can do to make her cp a bit faster/ smoother running stock rom (gb 2.3.6) since he don't want to use any custom rom. her cp
searching the thread, i was able to read some info that some was able to flash mod/ tweaks on stock roms to at least improve its performance. so i'm planning to install andrenaline engine or crossbreader on it but, as far as i know, flashing them requires ur rom, aside from of course being rooted, have cwm, etc., to support init.d which stock roms don't have. (corect me if i'm wrong)
i'm a bit in doubt doing this in the fist place, so any guide/ help or suggestions to make this init.d thing work is really really much appreciated. thnx in advance!
info i got (xda forum) about making stock rom support init.d Enable Init.d for Any Phones w/o Need of Custom Kernels
here, this link provide init.d support;
http://forum.xda-developers.com/showpost.php?p=32716432&postcount=3
flash zip_init.zip.
copy zip_init.zip to sd-card,
boot to cwm, mount /system, mount /data then flash zip_init.zip
check for test.log in /data if it is there or not, no test.log not working.
it work on my stock rom.
also flash adrenoboost v0.7 will boost perfromance from stock 5000 to 7000 (antutu benchmark).
adrenoboost link;
http://forum.xda-developers.com/showthread.php?t=2167228
saintsoh said:
here, this link provide init.d support;
http://forum.xda-developers.com/showpost.php?p=32716432&postcount=3
flash zip_init.zip.
copy zip_init.zip to sd-card,
boot to cwm, mount /system then flash zip_init.zip
check for test.log in /data if it is there or not, no test.log not working.
it work on my stock rom.
also flash adrenoboost v0.7 will boost perfromance from stock 5000 to 7000 (antutu benchmark).
adrenoboost link;
http://forum.xda-developers.com/showthread.php?t=2167228
Click to expand...
Click to collapse
thnx for the reply bro. about the adrenoboost, i think its main purpose is to boost the performance of Adreno 205 GPU or similar gpu but my friends device doesn't have gpu.
i didnt know tat.
anyway i think after mount /system, u should also mount /data (just in case).
it work on my sgw without mount /data but then i saw check /data for test.log which makes it necessary or not?
i'm not sure, just be on the safe side mount /data.
saintsoh said:
i didnt know tat.
anyway i think after mount /system, u should also mount /data (just in case).
it work on my sgw without mount /data but then i saw check /data for test.log which makes it necessary or not?
i'm not sure, just be on the safe side mount /data.
Click to expand...
Click to collapse
okay, i'll try that and hope it'll work
EDIT: sad, it didn't work
just learn something new when i reverted back to stock and re-install zip-init for init.d support.
when flash zip_init.zip and reboot, cwm will ask to "disable recovery flash" - select "NO".
(note: if select "yes", it will give a false positive, 'install-recovery.sh' will not have execute permissions and init.d support will not work).
after troubleshoot found out the install-recovery.sh is not in execute permission (rwxr--r-- instead of rwxr-xr-x).
by correcting the 'install-recovery.sh' permission, init.d support will work again.
ps;
must install busybox app (do a normal install).
saintsoh said:
just learn something new when i reverted back to stock and re-install zip-init for init.d support.
when flash zip_init.zip and reboot, cwm will ask to "disable recovery flash" - select "NO".
(note: if select "yes", it will give a false positive, 'install-recovery.sh' will not have execute permissions and init.d support will not work).
after troubleshoot found out the install-recovery.sh is not in execute permission (rwxr--r-- instead of rwxr-xr-x).
by correcting the 'install-recovery.sh' permission, init.d support will work again.
ps;
must install busybox app (do a normal install).
Click to expand...
Click to collapse
i got busybox installed, but i'm having status 0 error in CWM. in troubleshooting guide, it says replace the update-binary in zip-init.zip with a working update-binary of your phone and i don't how to do it
dec0der said:
i got busybox installed, but i'm having status 0 error in CWM. in troubleshooting guide, it says replace the update-binary in zip-init.zip with a working update-binary of your phone and i don't how to do it
Click to expand...
Click to collapse
update-binary is in the zip file, just download the latest which is the v2 and re-flash again.
if still doesn't work, try get help from init.d support thread.
i didn't get it working on the first time twice but somehow get it work again again.
saintsoh said:
update-binary is in the zip file, just download the latest which is the v2 and re-flash again.
if still doesn't work, try get help from init.d support thread.
i didn't get it working on the first time twice but somehow get it work again again.
Click to expand...
Click to collapse
it was v2 of zip_init that i use and i think i re flashed it 5x already and still getting that error anyways, thnx 4 ur help bro, godbless!
dec0der said:
it was v2 of zip_init that i use and i think i re flashed it 5x already and still getting that error anyways, thnx 4 ur help bro, godbless!
Click to expand...
Click to collapse
superusers app needed for terminal emulator, fx explorer(root access), busybox and script manager apps installed for root access.
use script manager, look for install-recovery.sh in /etc or system/etc (both r the same directory).
touch su n boot icon, su will turn green n boot will turn blue. reboot.
or
use fx explorer to set file permissions if u do not know linux commands.
google play search for fx explorer app and fx root addon (enable root access).
use root folder, look for install-recovery.sh in system/etc.
touch tool menu below and mount read-write then u can change file permission.
or
if u r familiar with linux commands, u can use terminal emulator to change file permission.
check install-recovery.sh permission is rwxr-xr-x, not other like rwxr--r--.
how2check in emulator, type n press enter:
ls -l etc/inst* ↵
how2change file permission, type n press enter:
su ↵
cd etc ↵
mount -o remount rw /system ↵
chmod 755 install-recovery.sh ↵
exit ↵
exit ↵
done, there shouldnt be any error, reboot.
if not re-flash zip_init.zip, reboot, select "NO" to disable flash recovery.
saintsoh said:
superusers app needed for terminal emulator, fx explorer(root access), busybox and script manager apps installed for root access.
use script manager, look for install-recovery.sh in /etc or system/etc (both r the same directory).
touch su n boot icon, su will turn green n boot will turn blue. reboot.
or
use fx explorer to set file permissions if u do not know linux commands.
google play search for fx explorer app and fx root addon (enable root access).
use root folder, look for install-recovery.sh in system/etc.
touch tool menu below and mount read-write then u can change file permission.
or
if u r familiar with linux commands, u can use terminal emulator to change file permission.
check install-recovery.sh permission is rwxr-xr-x, not other like rwxr--r--.
how2check in emulator, type n press enter:
ls -l etc/inst*
how2change file permission, type n press enter:
su
cd etc
mount -o remount rw /system
chmod 755 install-recovery.sh
exit
exit
done, there shouldnt be any error, reboot.
if not re-flash zip_init.zip, reboot, select "NO" to disable flash recovery.
Click to expand...
Click to collapse
busybox was installed correctly as i can see the folder bin/ xbin. it's rooted already so superuser was in there and i used root explorer file manager. i can't find install-recovery.sh in /etc or system/etc which maybe means that it was not working
dec0der said:
busybox was installed correctly as i can see the folder bin/ xbin. it's rooted already so superuser was in there and i used root explorer file manager. i can't find install-recovery.sh in /etc or system/etc which maybe means that it was not working
Click to expand...
Click to collapse
1) phone is rooted,
2) superuser app installed,
3) busybox app installed,
4) root explorer file manager app installed,
5) no install-recovery.sh in /etc or system/etc?
6) no test.log in /data?
7) re-flash zip_init.zip, reboot, select 'NO' to disable flash recovery?
8) no init.d directory in /etc?
9) in etc/init.d directory, there should have two files 00test n 08setperm. in /etc should have install-recovery.sh file.
10) u dont have these three files?
flashing cant write on system directory, means manufacturer locked the system.
unless u can find way to break the lock.
saintsoh said:
1) phone is rooted,
2) superuser app installed,
3) busybox app installed,
4) root explorer file manager app installed,
5) no install-recovery.sh in /etc or system/etc?
6) no test.log in /data?
7) re-flash zip_init.zip, reboot, select 'NO' to disable flash recovery?
8) no init.d directory in /etc?
9) in etc/init.d directory, there should have two files 00test n 08setperm. in /etc should have install-recovery.sh file.
10) u dont have these three files?
flashing cant write on system directory, means manufacturer locked the system.
unless u can find way to break the lock.
Click to expand...
Click to collapse
1-4 yes, all done
5-10 don't have those files coz i got status 0 error flashing zip_init.zip v2 in CWM
if thats the case, maybe i'll try to flash different stock firmware 1st
dec0der said:
1-4 yes, all done
5-10 don't have those files coz i got status 0 error flashing zip_init.zip v2 in CWM
if thats the case, maybe i'll try to flash different stock firmware 1st
Click to expand...
Click to collapse
try manually put in those files in their respectively directories.
unzip n try putting those files in their respective order.
create a init.d directory in /etc then put those two files 00test n 08setperm into it.
put the install-recovery.sh in /etc, set all permissions to rwxrwxrwx.
(upload manager doesnt allow .sh file, rename install-recovery.sh.txt to install-recovery.sh)
done, reboot n see it works or not.
saintsoh said:
try manually put in those files in their respectively directories.
unzip n try putting those files in their respective order.
create a init.d directory in /etc then put those two files 00test n 08setperm into it.
put the install-recovery.sh in /etc, set all permissions to rwxrwxrwx.
(upload manager doesnt allow .sh file, rename install-recovery.sh.txt to install-recovery.sh)
done, reboot n see it works or not.
Click to expand...
Click to collapse
okay, i'll try that. thnx
Hello.
I have rooted my phone using
http://htc-one.wonderhowto.com/how-to/unlock-bootloader-root-your-htc-one-m8-0154444/
(in short, it's using SuperSU 2.00)
After some efforts, Root Checker says i am fine. I can get id 0 from adb, and via ssh.
But ... Busybox fails to install.
And if I remount /system RW, and mess in there a bit (like mkdir /system/tmp ), the mess is removed after reboot. Changes are not permanent.
Must I change my su app for superuser mentionned in the FAQ of the section (via recovery) ? Are there things to do before this migration ?
Other possible issues ?
I am used to fully unlocked HTC Sensation, where I changes to /system are easily permanent. But it was done using an exploit, few before HTC allowed rooting officially. Rooted M8 does not seem as much friendly ...
I *really* need busybox to work, and make permanent changes to /system. I am stuck.
Thanks.
doublehp said:
Hello.
I have rooted my phone using
http://htc-one.wonderhowto.com/how-to/unlock-bootloader-root-your-htc-one-m8-0154444/
(in short, it's using SuperSU 2.00)
After some efforts, Root Checker says i am fine. I can get id 0 from adb, and via ssh.
But ... Busybox fails to install.
And if I remount /system RW, and mess in there a bit (like mkdir /system/tmp ), the mess is removed after reboot. Changes are not permanent.
Must I change my su app for superuser mentionned in the FAQ of the section (via recovery) ? Are there things to do before this migration ?
Other possible issues ?
I am used to fully unlocked HTC Sensation, where I changes to /system are easily permanent. But it was done using an exploit, few before HTC allowed rooting officially. Rooted M8 does not seem as much friendly ...
I *really* need busybox to work, and make permanent changes to /system. I am stuck.
Thanks.
Click to expand...
Click to collapse
The /system partition is write protected on stock, meaning you can't add, modify, or delete files there. To disable this, you need to flash a kernel or rom with this disabled. Pretty much all sense based roms/kernels will state this in the features. I believe S-Off also disables it if you want to go the extra mile.
PS: Write protection is disabled in recovery. That is why superuser/root could be installed there.
PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613
akitten007 said:
The /system partition is write protected on stock, meaning you can't add, modify, or delete files there. To disable this, you need to flash a kernel or rom with this disabled. Pretty much all sense based roms/kernels will state this in the features. I believe S-Off also disables it if you want to go the extra mile.
PS: Write protection is disabled in recovery. That is why superuser/root could be installed there.
PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613
Click to expand...
Click to collapse
So, is there a way to install busybox via recovery ?
I did 3 things in recovery: all in /system/xbin
- chmod +s su
- touch t
- mkdir tmp
after reboot to normal mode, SUID bit was removed, but t and tmp are still here.
So, how do I install busybox ?
New issue: /data has the nodev flag; is it possible to remove it ?
I did not found /dev/shm ; was it moved somewhere else ? Any other place for similar use ? (world write temp folder in RAM).
akitten007 said:
PPS: Here is the kernel I run (protection disabled): http://forum.xda-developers.com/showthread.php?t=2705613
Click to expand...
Click to collapse
If your kernel allows me to install busybox, can i backup my original kernel to restaure it afterwards ?
Can I install busybox manually via recovery+adb ? I don't have any dev suite, but a good linux station; so, I can unzip, list, copy, and so on ... if there is not too much work to do.
doublehp said:
If your kernel allows me to install busybox, can i backup my original kernel to restaure it afterwards ?
Can I install busybox manually via recovery+adb ? I don't have any dev suite, but a good linux station; so, I can unzip, list, copy, and so on ... if there is not too much work to do.
Click to expand...
Click to collapse
Now you're starting to go over my head. If you want to keep your current kernel, I would try using this method here to manually add the module that disables the protection http://forum.xda-developers.com/showthread.php?t=2702575. I usually just install busybox using rom toolbox or any other busybox app. You could search for a busybox zip, but just disabling the write protection is a better option in my opinion. And I have actually 0.00 idea what flags mean on folders (sorry).
I rooted using TWRP recovery and super su. That guide you posted gives unnecessary instructions. TWRP automatically installs the SU binary and Super su the first time you boot into it. I was able to update Super su via google play, no need for the update zip. Just follow the instructions after rebooting to system from TWRP recovery.
I'm s-off, unlocked, my kernel, firmware and os are stock, only thing that isn't is recovery. I have write access to system and external sd card. All I did was make it writable with root explorer and have installed busy box no problem using this app https://play.google.com/store/apps/details?id=stericson.busybox.
I was given a better fix.
http://forum.xda-developers.com/showthread.php?t=2701816
In short:
adb push /mnt/big/tmp/wp_mod_m8.ko /mnt/sdcard/Download/
insmod /mnt/sdcard/Download/wp_mod_m8.ko
mount -o remount,rw /system
cd /system
touch z
mkdir zz
reboot
[email protected]_m8:/storage/emulated/legacy # cd /system/
[email protected]_m8:/system # ls
app
bin
build.prop
customize
etc
fonts
framework
lib
lost+found
media
priv-app
tts
usr
vendor
xbin
z
zz
[email protected]_m8:/system #
The miror is on maintainance for now. So, the guy on IRC gave me his local backup. I will push it here for 30 days:
http://dl.free.fr/gSha53ljz
(server will delete it after 30d nobody downloads it)
Busybox still fails to install; don't know why.
Hi all -
I have made updated scripts before, but something isn't working out for me. I started with this guys script here:
https://forum.xda-developers.com/showpost.php?p=19093919&postcount=20
Purpose is to add lines to build.prop from the script (also does a backup).
First time through I was getting an error which I resolved by updating to a different updater-binary.
I know that the .sh script that I am copying over is running (using some simple touch statements), however it never seem to touches my build.prop.
I think the issue is that somehow it can't access the build.prop file, possibly because it isn't mounting /system properly.
It seems to use busybox commands which I don't have on my device (and I'd rather not install, as I don't want to have to depend on it after clean flash).
Can someone help me out or point me to another script/method of updating build.prop via updater-script?
thanks
Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?
TraderJack said:
Yeah, I don't know what's going on.
I've also tried these scripts meant to modify build.prop:
https://forum.xda-developers.com/android/apps-games/pie-pixel-stuff-t3846138 (the prop patch script)
and
https://forum.xda-developers.com/showthread.php?t=2664332
Scripts appear to run fine, but build.prop is never edited.
None of these scripts states they are for the 3, but they do indicate they at least worked with the original Pixel.
Is something different in the 3 that would be preventing any of these from working?
Click to expand...
Click to collapse
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.
Tulsadiver said:
Try changing the updater-script code from busybox to toybox.
Edit: I took the script and made one that seems to work on Pixel 3's. Like the one you posted, put the lines you want added in the tmp/misc text file.
Click to expand...
Click to collapse
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.
TraderJack said:
Thanks...is the one you sent meant to be a Magisk flashable module or a TWRP one? It looks like a Magisk one.
The problem I was having with most of the other scripts was two-fold:
1) There did seem to be some mount issues. Not all the scripts I was using used busybox, the just specified "mount". Additionally, some scripts appeared to do mount commands in the updater-script (with its special syntax) while others attempted to do them in the script that was called via the run_program() calls. I think the mounts were working in most cases, though some seemed to fail on remounts if the /system was already mounted. It seems the correct way to do this (at least on Pixel 3) is to use toybox mount commands in updater-script. I couldn't find a lot of info about this, but is toybox built into the Pixel 3? I assume so, unless Magisk was putting it in the /sbin directory (which I doubt).
2) Most of the scripts I was working with are twrp flashable files, and none of those were working (no errors though). Definitely the issue I found was that build.prop is not located in /system when twrp has mounted the filesystem. It is in /system/system/build.prop. I was able to get scripts working to modify this by ensuring the mount commands worked and pointing to /system/system/build.prop. I don't understand the change in the extra subdirectory, and not many people have mentioned it.
I haven't been really up on recent developments. It seems that people have become adverse to installing TWRP permanently in the recovery and maybe people aren't really using TWRP modules anymore instead of going to Magisk ones? I don't really understand why not to install TWRP because I can still pass all the safety checks, use google pay, etc with TWRP installed. But if this is the way the community is going, I guess I need to stop assuming I can do these things via TWRP flashes.
Click to expand...
Click to collapse
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.
Tulsadiver said:
This is TWRP flashable to system. Not a module and cannot be installed via magisk manager.
Edit. The script was hard coded on that one. If you want to do custom scripting and not just add lines, use this one. In this one, bptweaks.sh and misc text are tweakable. In the first one, just misc.
This is not my work other than a few tweaks. This is an altered magisk installer. Used to be able to mount and run scripts.
Click to expand...
Click to collapse
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.
TraderJack said:
Thanks. I have not run this yet. It's not that I don't trust you, but I like to audit the script and since this appears to be a modified template the script is rather large and appears to be doing a bunch of things. Therefore I don't want to run it on my phone until I know exactly what it is modifying.
However, I can't see how this will work because it seems to have the same issue as the other scripts. In updater-script it has the following relevant section:
Code:
bp="/system/build.prop"
toybox mount /system
toybox mount /data
if [ -f /system/build.prop.bak ];
then
rm -rf $bp
cp $bp.bak $bp
else
cp $bp $bp.bak
fi
echo " " >> $bp
echo "# Enable pixel theme" >> $bp
echo " " >> $bp
for mod in misc;
do
for prop in `cat /data/tmp/tmp/$mod`;do
export newprop=$(echo ${prop} | cut -d '=' -f1)
sed -i "/${newprop}/d" /system/build.prop
echo $prop >> /system/build.prop
done
done
So it uses toybox to mount /system and then attempts to modify /system/build.prop by iterating through the misc file and editing inline the changes found therein. The problem here is that build.prop isn't in that location on my phone. Look at this adb output from my phone with TWRP running (slightly edited because I get linker errors on every command once /system is mounted..due to some endless recursion in the file system I think?):
Code:
crosshatch:/ # ls -l /system
total 0
drwx------ 3 root root 0 1970-08-29 20:11 etc
crosshatch:/ # toybox mount /system
crosshatch:/ # ls /system
acct d firmware init.recovery.crosshatch.rc lost+found postinstall storage
bin data init init.recovery.sdm845.rc metadata proc sys
bugreports default.prop init.crosshatch.rc init.usb.configfs.rc mnt product [B]system[/B]
cache dev init.environ.rc init.usb.rc odm res ueventd.rc
charger dsp init.rc init.zygote32.rc oem sbin vendor
config etc init.recovery.blueline.rc init.zygote64_32.rc persist sdcard
crosshatch:/ # cd /system/system
crosshatch:/system/system # ls
app [B]build.prop[/B] etc fake-libs64 framework lib64 product vendor
bin compatibility_matrix.xml fake-libs fonts lib priv-app usr
So I simply don't see how it is possible that the script you sent would modify /system/system/build.prop.
You have a Pixel 3 and ran this and it worked? If so, I'm curious does your build.prop show in the same location as mine within your adb session?
The only way I could see this working is if there is something magic in the code I haven't reviewed yet or somehow the filesystem from *within* twrp (the context of where this runs) looks different than if I do this over adb. I don't think that is likely, but I'm not an expert.
Click to expand...
Click to collapse
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Edit:. That code in bptweaks.sh and that you posted is not mine either. It came from one of the links in your original post. I thought you were indicating that you could not get a script to install. All I did was try and make a vehicle for a script that could modify the build.prop.
Tulsadiver said:
Most of the code has to do with mounting and unmounting magisk.img and not applicable. I ran this on my pixel 3XL and did indeed put the code in my build.prop. I'm not saying the code itself works, just that this edits the build.prop. Here is a version that has a bit more of the code stripped out.
Click to expand...
Click to collapse
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?
TraderJack said:
That's really interesting/strange. Would you do me a favor when you have a few minutes and adb in with twrp booted and see if your file system mirrors mine? Specifically, when you mount /system does build.prop show inside /system or in /system/system/build.prop.
If I adb into my phone with the OS booted it is in /system/build.prop, but from within twrp it is one more /system directory deep.
I'll try to review the latest one you sent and run it on my phone to see if it indeed works. I have a bit more confusion because the way this zip is built is that the updater-script looks to be a normal shell script. In most of these flashables I have seen the update-script is a special script that only uses a special syntax of commands, such as:
Code:
package_extract_file();
set_perm();
mount();
run_program("/tmp/backuptool.sh", "backup");
etc...
The code I see in this update-script is what you would normally find in an external shell script like that referenced in the run_program() above.
I don't know how Magisk actually builds theirs, though I can say that the updater-binary is significantly larger than the one used in other flashable zip files I have seen. Can you speak to that at all?
Click to expand...
Click to collapse
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.
Tulsadiver said:
The update-binary is the BusyBox installer script and zip extraction. It runs first, then the updater-script runs. Open the update-binary with a text editor. Above the ELF files is script.
Click to expand...
Click to collapse
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/
TraderJack said:
Ok...so that appears to be completely different to how most "normal" flashable zip files work where the update-binary is a smaller full binary script that then launches the update-script which uses the syntax I mentioned above. Clearly the Magisk devs know what they are doing but all the other flashables I have downloaded (and created) have not used this method. Unfortunately, it makes it impossible for me to compare apples to apples in why nothing else works and really doesn't answer any of the questions. While this script may work, it gives me no answers as to why it does, and why the others fail :/
Click to expand...
Click to collapse
Yes, it's in the mounting. Pixel 3's don't seem to use BusyBox. They've looks like they've gone to toybox. What this dumbed down version of magisk util_function.sh appears to be doing is installing BusyBox and setting it to be used instead. This one is more like you are used to seeing. The only way I could get it to work is still by using magisk util_function.sh for mounting purposes. I would not be able to write a script like that myself.
I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.
HesThatGuy said:
I haven't read all of the replies in this thread so forgive me if I'm saying something that someone else has already said.
I had the same issue as you've had when I first started flashing custom files onto my 1st Gen Pixel and what I've found that's worked for me is to do this:
1.) Boot into TWRP & flash Magisk
2.) Reboot into bootloader
3.) Boot into TWRP again & flash your custom files
4.) Boot up the phone as you normally would
Not 100% sure this will work since you have a Pixel 3 and this worked for me on a Pixel 1 but I'd think it would be worth trying.
Click to expand...
Click to collapse
Thanks, but 100% not relevant - not only to the replies, but also to the OP.
TraderJack said:
Thanks, but 100% not relevant - not only to the replies, but also to the OP.
Click to expand...
Click to collapse
Sounds like you need to disable dm-verity to edit build prop without using Magisk. Magisk is one big overlay seems to be the way of the future tho. I personally been disabling verity then adding xbin folder to root then linking to system then installing BusyBox to xbin. I don't like using Magisk to install BusyBox module or any module that alters the system because you will have to use Magisk to modify system from there on out instead of jus manully doing it yourself with a root explorer.
Also if you was to flash a open gapps zip it would add a addon.d folder to system. which open gapps and Magisk will install their backup scripts to the addon.d folder. would be a good place for you to add your own backup script as well.
Yeah, you need to disable verity to properly mount /system, /vendor, and /product partitions. It is not hard. In magisk manager just go to advanced options, untick verity, then install magisk from the app. After changes you can put verity back if that bugs you.