Related
alrighty, basically im lazy and want someone else to do this for me.
heres my idea:
you install rc33 or whatever you want, make a nandroid backup of it, rename the folder to OS1. this folder contains your boot.img data.img and so on
then install or place a nandroid backup of another build into a folder called OS2..
then you would be able to boot into the modified recovery mode, which would have the selection to run a script, which then asks which OS to flash, 1 or 2, you press 1 or 2 wait for it to flash and reboot, a little hacky way to get a dual boot...
now who wants to repack a recovery image for me?
good idea would be worth a try , too bad im not up to par for the job , but id like to see it done
i'll give this a shot tomorrow and see what happens, not really feeling like doing it now. and i'm not gonna do it via rebuilding the recovery.img, just gonna make a script that does it for me from the recovery terminal. i'm quite lazy as well and i already have a script that runs the fastboot commands from my computer script to flash from one build to another, in theory it shouldn't be too hard to get the script terminal reaady and do that.
tubaking182 said:
i'll give this a shot tomorrow and see what happens, not really feeling like doing it now. and i'm not gonna do it via rebuilding the recovery.img, just gonna make a script that does it for me from the recovery terminal. i'm quite lazy as well and i already have a script that runs the fastboot commands from my computer script to flash from one build to another, in theory it shouldn't be too hard to get the script terminal reaady and do that.
Click to expand...
Click to collapse
I have a .bat file that I use to flash back and forth from Windows.
To RC33
cd C:\Android\
@echo off
echo :::Instructions:::
echo You must have:
echo system.img
echo data.img
echo boot.img
echo installed in the "C:\Android" directory
echo then enable fastboot on device before proceeding
pause
fastboot flash system system.img
fastboot flash userdata data.img
fastboot flash boot boot.img
fastboot reboot
Click to expand...
Click to collapse
To 502H
cd C:\Android\502H\
@echo off
echo :::Instructions:::
echo You must have:
echo system.img
echo data.img
echo boot.img
echo installed in the "C:\Android\502H" directory
echo then enable fastboot on device before proceeding
pause
fastboot flash system system.img
fastboot flash userdata data.img
fastboot flash boot boot.img
fastboot reboot
Click to expand...
Click to collapse
Pretty simple. I have them stored to my desktop. I save my nandroid backups to the appropriate file and just double click. No problem. I just wish there was a script that I can use to reboot into HARDSPL mode (someone tell me if there is).
keatonreckard:
This is the worst idea i've heard so far...
FLASH has a limited life-time, and rewriting the whole system at every boot is a BAD idea.
If you want to dual-boot, you should look into making your own init-system, adding the ability to load another system (From SD).
Binary100100:
"adb reboot bootloader"
there might be a simpler way: change the kernel command so it mounts somewhere in sdcard as root. not sure how to do this without a computer though.
Hey binary, with your phone plugged into your comp pull up you cmd and type adb shell reboot bootloader, the phone will boot right into fastboot mode making it easy to continue the script
just to clarify...i meant a script that is store locally on the device in the recovery image... so then you dont need a computer at all... you can already do this, you just have to type in the commands from the recovery console...i just wanted an easier way to do it
Binary100100 said:
I have a .bat file that I use to flash back and forth from Windows.
To RC33
To 502H
Pretty simple. I have them stored to my desktop. I save my nandroid backups to the appropriate file and just double click. No problem. I just wish there was a script that I can use to reboot into HARDSPL mode (someone tell me if there is).
Click to expand...
Click to collapse
To flash back and forth from windows? You've been running Windows Mobile on the Dream? I must be missing something.
Joushou said:
keatonreckard:
This is the worst idea i've heard so far...
FLASH has a limited life-time, and rewriting the whole system at every boot is a BAD idea.
If you want to dual-boot, you should look into making your own init-system, adding the ability to load another system (From SD).
Binary100100:
"adb reboot bootloader"
Click to expand...
Click to collapse
not flash at every boot...just so you can text out a build and if you dont like it go back to a stable one on the go....
again, im taking the lazy way out
Disregard! - My mind ran ahead of what this post was about and I posted something regarding a slightly different idea!
I don't know about re-installing Nandroid backups...
But, if one wanted to be able to run two different installs...
Seems to me an easier way about doing this would be to have a modified SPL. It could have the option of selecting an update file...
For example, one could put two files on their sd card - update1.zip and update2.zip. The SPL could have one of the following options:
1) reboot into recovery mode - select "alt-s" - then you would have an option to select 1 or 2.
2) have an additional "Alt- " option.
"Alt-s" - runs update1.zip
"Alt-?" - runs update2.zip. (dev could pick the additional letter)
I think this would be great! No reteaching of anyone how to use the process. And, one could leave the primary use-able update.zip as "update1.zip" and use the other as the version being tried out. It wouldn't be a Nandroid back up... But, with the new "nowipe" builds it should work well.
My $.02 worth.
Joushou said:
keatonreckard:
This is the worst idea i've heard so far...
FLASH has a limited life-time, and rewriting the whole system at every boot is a BAD idea.
If you want to dual-boot, you should look into making your own init-system, adding the ability to load another system (From SD).
Binary100100:
"adb reboot bootloader"
Click to expand...
Click to collapse
To be fair, that limited life-time is something like 1,000,000 writes, which would take about... oh... a year straight of constantly rebooting your phone(assuming it takes 30 seconds per reboot)
EDIT: and that assumes re-writing the whole system every time you boot, which I don't think he means since he's saying its in the recovery image.
hmmm....
I know that from the alt+x console you can do this....
mount sdcard
echo "boot-recovery
--update_package=SDCARD:build1/update.zip" > /cache/recovery/command
reboot recovery
so if you wanted 2 builds available (I would think you would need a wipe for 2 completely different builds) but....
make 2 folders in on your sdcard
build1
build2
place a copy of the update.zip from each build you want to boot in the folder
make a script like this
Code:
echo "boot-recovery
--update_package=SDCARD:"$"/update.zip" > /cache/recovery/command
reboot recovery
save the script to the sdcard directory
then when you start your phone you could
1. type "mount sdcard" (no quotes)
2. type "sh sdcard/script.sh build1" (for build 1 located in /sdcard/build1/update.zip)
3. type "sh sdcard/script.sh build2" (for build 2 located in /sdcard/build2/update.zip)
problem would be when wipes are needed. But if you have 2 solid builds and don't need to wipe when swapping it should work.
Just need a way to make a script or bootloader that could run either one of these.
Cannot see another way around it since the OS is loaded into phone ROM/RAM
of course if your build supports the reboot command from the OS then you could just make a script to run when you want to reload the other build. Then you could skip the recovery console.
@beagz - Ha, forgot about that script. Yes, to switch between say, the DudesG build and Haykuro's H build one could write a script like that in Gscript and change back and forth when a new build comes out.
Like now... One could run Dudes G build and try out Haykuro's new ADP1.5 build.
But, I do believe your right about going back to a JF33 build - would need to wipe...
Gimpeh said:
To flash back and forth from windows? You've been running Windows Mobile on the Dream? I must be missing something.
Click to expand...
Click to collapse
Nah.. I was referring to using a bat file on my Windows computer to switch between 1.1 to 1.5 back to 1.1 by just executing the bat.
Now that i know that "adb reboot bootloader" will work it can be completely automated!
... but will it default to fastboot? Hmmm...
tubaking182 said:
Hey binary, with your phone plugged into your comp pull up you cmd and type adb shell reboot bootloader, the phone will boot right into fastboot mode making it easy to continue the script
Click to expand...
Click to collapse
Thanks! But is this going to put the phone in FASTBOOT mode? I'm trying to make this completely automatic if it's possible. Simply keep your latest and greatest backup .img's in a certain directory on your computer and EXECUTE!
Take a shower or whatever... come back and VOILA! Your previous backup.
The method that I've come up with thus far is pretty simple... but you just can't execute and walk away. You still need to enable FASTBOOT at the least on the bootloader. Although I haven't tried messing with it lately. I have my phone just like I want it.
Now that the Official ADP1.5 is out let's get to work on Mulitouch, themes, etc!
Wow this seems crazy but it just might work. Lol.
bat file to automatically restore backups using Windows!
So all you need to do is...
Open notepad, copy and paste the quoted text below, edit the top line of this bat file to the directory of your backups (I used "c:\android" for an example), save as .bat and double click. Wait and your done. Just watch it happen automatically.
Also if you decide to change that directory on the top line also use the directory on the 14th line. Your done. Easy restore to a backup.
HINT! Make a couple of these with a variety of directories on the top to change what backup your want to flash back to.
Example: c:\android\rc33; c:\android\501h; c:\android\adp15; etc
cd C:\android
color A
cls
@echo off
echo.
echo :::Instructions:::
echo.
echo You must have:
echo.
echo system.img
echo data.img
echo boot.img
echo.
echo installed in the "c:\android" directory
echo.
pause
cls
color b
echo.
echo.
echo.
echo Now restoring:
echo.
echo system.img
echo data.img
echo boot.img
echo.
echo to your device.
color c
echo.
echo DO NOT TURN OFF OR UNPLUG YOUR DEVICE DURING THIS PROCESS!!!
@adb shell reboot bootloader
@fastboot flash system system.img
@fastboot flash userdata data.img
@fastboot flash boot boot.img
@fastboot reboot
Click to expand...
Click to collapse
I've tested it and it works beautifully!
Hope it helps!
Thanks to everyone that pointed out the command "adb shell reboot bootloader"
This post is noob friendly.
OR
Use this script below for it to prompt for the location of your backups.
color A
cls
@echo off
echo.
echo :::Instructions:::
echo.
echo Enter directory of nandroid backups that you would like to restore...
set /p flash=path:
cd %flash%
cls
color b
echo.
echo.
echo.
echo Now restoring:
echo.
echo system.img
echo data.img
echo boot.img
echo.
echo to your device.
color c
echo.
echo DO NOT TURN OFF OR UNPLUG YOUR DEVICE DURING THIS PROCESS!!!
@adb shell reboot bootloader
@fastboot flash system system.img
@fastboot flash userdata data.img
@fastboot flash boot boot.img
@fastboot reboot
Click to expand...
Click to collapse
This one is even more noob friendly... but it's not as fast because it requires you to enter the location of your backups.
I hope it helps someone out there. It helps me.
[email protected]:
The average lifetime of flash is 100.000 writes, and flash isn't delivered 100% intact, they're usually delivered with faulty blocks (Depending on where you get it, blah blah blah).
That should change your numbers a bit (A month i believe?)
And, sure, he is using the update-zip, so it's not written to the same pages every time.
But still, it's a bad idea (Other than wearing stuff down, it will also be very slow ).
To dual-boot, modifying the init-system so it could choose from different android-runtimes would be way faster/cooler...
If possible, this would be pretty damn useful. Using a stable build while being able to tinker with experimental builds. Would definitly cut down on the constant flashing back and forth.
Full release post is here and I'll update at xda soon.
http://androidforums.com/lg-optimus...ry-optimus-one-p500-thunderg.html#post1896517
I got all the bugs worked out thanks alahkel & fughy for testing and of course Amon-Ra for original source.
New link version 2.2.1 Version 2.2.1
New version 3.06 Version 3.06
Thanks to you for the whole great work you've done!
We really appreciate that.
really GREAT WORK !!!!
Please, i need some info, how use adb on P500.
Absolute AWESOME!!!
Thanks!
Thanks !
works like a charm. I have installed your custom recovery. Backed up everything with nandroid, tried KeruROM, flashed back my original branded ROM from nandroid backup.
Everything works. I'm not going to try flash back my original recovery mtd, there is no reason to do it, but have a dd backup just in case. I don't know if it is safe to tamper with recovery mtd, cause I'm not sure if it is re-flashed after every system shutdown. I don't think so, cause I haven't found recovery.img in /system.
I have two questions regarding flashing custom recovery. I haven't used this command:
Code:
# mv /system/etc/install-recovery.sh /system/etc/install-recovery.sh.bak
cause, i didn't found this script on my phone. Is it ok?
Second question: Is it mandatory to copy flash_image to /system/bin with this command?
Code:
cat /sdcard/flash_image > /system/bin/flash_image
Can't we use /data/local/tmp directory and running flash_image from there as we used in the process of rooting the phone? This way we don't have to remount /system in rw and do not have to modify it.
Now I'm going to explore ROM modding ;-)
Vintersorg said:
Thanks !
works like a charm. I have installed your custom recovery. Backed up everything with nandroid, tried KeruROM, flashed back my original branded ROM from nandroid backup.
Everything works. I'm not going to try flash back my original recovery mtd, there is no reason to do it, but have a dd backup just in case. I don't know if it is safe to tamper with recovery mtd, cause I'm not sure if it is re-flashed after every system shutdown. I don't think so, cause I haven't found recovery.img in /system.
I have two questions regarding flashing custom recovery. I haven't used this command:
Code:
# mv /system/etc/install-recovery.sh /system/etc/install-recovery.sh.bak
cause, i didn't found this script on my phone. Is it ok?
Second question: Is it mandatory to copy flash_image to /system/bin with this command?
Code:
cat /sdcard/flash_image > /system/bin/flash_image
Can't we use /data/local/tmp directory and running flash_image from there as we used in the process of rooting the phone? This way we don't have to remount /system in rw and do not have to modify it.
Now I'm going to explore ROM modding ;-)
Click to expand...
Click to collapse
Flash_image doesn't have to be there but for simplicity I put it there so it would be in ATH. The install-recovery.sh is an evil script that will rewrite a recovery on boot with stock recovery(that only is there on some phones after an official ota update) so rom markers please remove it if it exists.
Any chance the p509 optimus t is similar enough for this to work? I'm willing to be the guinea pig if it should work.
Joeseph Mother said:
Any chance the p509 optimus t is similar enough for this to work? I'm willing to be the guinea pig if it should work.
Click to expand...
Click to collapse
Its close enough it has a very good chance of working but will take a guinea pig to verify. Kernel should be close enough to try. Only differences I saw in the ramdisk of p500 & p509 was model number and lang of en GB and en Us repectively. I had a bad/corrupt dump to work off of on the p509/T. I could use a good dump source with a md5sum to verify its not corrupted in uploading/downloading.
make sure you do this 1st to backup your stock recovery
from terminal or adb shell
Code:
dd if=/dev/mtd/mtd2 of=/sdcard/recovery-dump-T.img bs=4096
please upload that dump for me with a md5 too and I'll work on an official.
Can it be done without root? As normal user?
Thanks of all to drellisdee
I want to advertise that the custon recovery file is no more available at Media fire link that suggest us.
Waiting that the file will be restored is there someone that can upload it???
Thank's of all!!!
Are you just wanting kernel & recovery dumps, because I think I've already changed most other things on my system
Installs, starts off saying E:Bad boot message "
Button layout is correct.
Usb mounting works.
Wipe appears to have worked.
Backup fails with Error:Run 'nandroid-mobile.sh' via adb!
I was looking for just the custom recovery (recovery-RA-GNM-thunderg-1.1.0.img.zip). Now it's available again!!!!
I think that i 've to apply it anyway.
Then if you say that some new rom and kernel are incoming it could be great!!!!
I hope to learn the necessary to help in development ... in this time i accept your works...
Joeseph Mother said:
Installs, starts off saying E:Bad boot message "
Button layout is correct.
Usb mounting works.
Wipe appears to have worked.
Backup fails with Error:Run 'nandroid-mobile.sh' via adb!
Click to expand...
Click to collapse
You get that error on nandroid if battery is below 30%
Joeseph Mother said:
Are you just wanting kernel & recovery dumps, because I think I've already changed most other things on my system
Click to expand...
Click to collapse
yes I only need the recovery one.
ruigui said:
Can it be done without root? As normal user?
Click to expand...
Click to collapse
It was last post on previous page... Can these backups be done as normal user, or must it be as root?
ruigui said:
It was last post on previous page... Can these backups be done as normal user, or must it be as root?
Click to expand...
Click to collapse
Recovery menu?
Only with root settings....
drellisdee said:
You get that error on nandroid if battery is below 30%
Click to expand...
Click to collapse
I wish it was that easy, battery was 90%.
Stock T recovery:
http://www.mediafire.com/?01bleb4njbf1ccy
md5: b18bd6e79c7b962739816a2f1d4bdacf
personalweb said:
Recovery menu?
Only with root settings....
Click to expand...
Click to collapse
You didn't understand. If i am working on a terminal emulator, must the following command be done as root or can it be done as normal user?
dd if=/dev/mtd/mtd2 of=/sdcard/recovery-dump-T.img bs=4096
Click to expand...
Click to collapse
UPDATE: First of all, thanks to everyone that responded. You guys are awesome! I'm returning the phone to HTC and hopefully it gets fixed. I do believe its hardware related but I think the real answer is way over my head.
I'm not really sure whats going on here, but the only ROM I can use / flash is Cyanogen. I was running trickdroid and then the phone decided to freeze and just reboot whenever I tried to launch anything. I cant use my nand from stock, install any sense, aokp or miui ROM. They install and even boot, but then it just freezes and reboots as soon as I unlock the lock screen. I even went as far as returning it back to stock with the RUU, but same scenario. I'm completely stumped. Anyone have anything to suggest? Thanks.
You flashed with a fullwipe and boot.img?
I did, multiple times. I typically do a factory reset, wipe cache, format data, format system, format dalvik then install the ROM. Once the ROM is installed, I then reboot back into fastboot and flash the boot.img. Just to add a little more, your ROM rocks man and I really want to go back to using it. The reason why I had to flash the boot by fastboot is because when I used your script it kept telling me permission denied on certain lines.
Bump
try to flash any sense rom, Format /system in recovery before flashing. Then run an RUU
An RUU wont run unless you have a sense ROM already, So dont worry if the phone dont boot, Aslong as the rom flashes, the RUU should work.
Then just start from the beginning.
Oh and RUU requires RELOCKED bootloader and in some cases Stock recovery
azzledazzle said:
try to flash any sense rom, Format /system in recovery before flashing. Then run an RUU
An RUU wont run unless you have a sense ROM already, So dont worry if the phone dont boot, Aslong as the rom flashes, the RUU should work.
Then just start from the beginning.
Oh and RUU requires RELOCKED bootloader and in some cases Stock recovery
Click to expand...
Click to collapse
I tried this and it didn't work. As soon as i unlock the lock screen it just freezes and reboots. So confused....
dubntz said:
I tried this and it didn't work. As soon as i unlock the lock screen it just freezes and reboots. So confused....
Click to expand...
Click to collapse
Yes but dont worry about that, The RUU should still work even with the phone freezing. You just need the Sense ROM on the phone, Whether it boots or not.
azzledazzle said:
Yes but dont worry about that, The RUU should still work even with the phone freezing. You just need the Sense ROM on the phone, Whether it boots or not.
Click to expand...
Click to collapse
Sorry, but what I meant to say is that I put a sense ROM back on, ran the RUU and it still froze once i tried to unlock the lock screen.
dubntz said:
Sorry, but what I meant to say is that I put a sense ROM back on, ran the RUU and it still froze once i tried to unlock the lock screen.
Click to expand...
Click to collapse
Oh i see... That is so weird
Have you asked in the Cyanogen thread ? The ROM must have altered something deep inside for something like this to happen...
Ive never seen anything like it
azzledazzle said:
Oh i see... That is so weird
Have you asked in the Cyanogen thread ? The ROM must have altered something deep inside for something like this to happen...
Ive never seen anything like it
Click to expand...
Click to collapse
I have not posted anything, although i'm going to now. It is so weird. I can install any sense ROM, but it freezes when I try to unlock the lock screen. I can not install AOKP or MIUI as they just boot loop. Cyanogen is the only ROM that I can flash...lol
dubntz said:
I have not posted anything, although i'm going to now. It is so weird. I can install any sense ROM, but it freezes when I try to unlock the lock screen. I can not install AOKP or MIUI as they just boot loop. Cyanogen is the only ROM that I can flash...lol
Click to expand...
Click to collapse
Have you tried taking out your sim card and rebooting? My phone kept freezing as soon as I unlocked the lockscreen and this is what worked for me...
I have, but no luck.
Sent from my HTC One S using Tapatalk 2
I feel like the phone is not properly wiping or installing the boot.img correctly. I have been trying different things for days. Just doesn't make sense. No pun intended..ha
Just some more experimenting. I tried to use a script from the trickdroid ROM to flash to boot and It came back with some permission denied errors. I'm wondering if that has something to do with it. I don't get any errors like that when I install it through fastboot though...
I'm beginning to think it has something to do with the boot.img not flashing properly. I think there might be some permission issues going on with the phone. I just tried to flash the latest CM nightly with the new boot and it just boot loops.
do you have an sdcard bu
you could try formatting and reloading the card, assume you can get to recovery
also, i fastbooted boot img before flashing rom, one right after the other. thought you said you flashed rom rebooted then flashed boot img, not sure if that matters
good you are wiping system also, or that can cause issues too
rugmankc said:
do you have an sdcard bu
you could try formatting and reloading the card, assume you can get to recovery
also, i fastbooted boot img before flashing rom, one right after the other. thought you said you flashed rom rebooted then flashed boot img, not sure if that matters
good you are wiping system also, or that can cause issues too
Click to expand...
Click to collapse
The ONES has an internal SD Card only so I cant remove it; however, I have formatted it and still the same results. I'm thinking I can't install any ROM that requires a new boot.img. Is something not mounting properly?
dubntz said:
Just some more experimenting. I tried to use a script from the trickdroid ROM to flash to boot and It came back with some permission denied errors. I'm wondering if that has something to do with it. I don't get any errors like that when I install it through fastboot though...
Click to expand...
Click to collapse
This script youre running, is it the one linked from the Trickdroid 4.3 thread, from http://d-h.st/2JV ?
If so check below where it tries to chmod +x fastboot-linux comes before the script cd's to the files directory where fastboot-linux actually lives. So fastboot-linux never gets execute permissions and therefore everything except the echo stuff fails.
Code:
@echo off
chmod +x fastboot-linux
echo "Flashin boot.img"
sleep 1
echo ...
cd files
./fastboot-linux flash boot ../boot.img
echo ...
echo "Flashing complete"
echo ...
echo "Erasing cache partition"
sleep 1
./fastboot-linux erase cache
echo ...
echo "Cache partition cleaned"
echo ...
echo "If there were no errors, you can continue"
echo ...
echo "If not, try again!"
echo ...
echo "Enjoy TrickDroid!"
sleep 20
To make it work edit it like this (move the cd files) or go into files and run chmod +x fastboot-linux before running the script. The Mac script has the same problem.
Code:
@echo off
cd files
chmod +x fastboot-linux
echo "Flashin boot.img"
sleep 1
echo ...
./fastboot-linux flash boot ../boot.img
echo ...
echo "Flashing complete"
echo ...
echo "Erasing cache partition"
sleep 1
./fastboot-linux erase cache
echo ...
echo "Cache partition cleaned"
echo ...
echo "If there were no errors, you can continue"
echo ...
echo "If not, try again!"
echo ...
echo "Enjoy TrickDroid!"
sleep 20
Dunno if this will help your general situation though, good luck!
frdd said:
This script youre running, is it the one linked from the Trickdroid 4.3 thread, from http://d-h.st/2JV ?
If so check below where it tries to chmod +x fastboot-linux comes before the script cd's to the files directory where fastboot-linux actually lives. So fastboot-linux never gets execute permissions and therefore everything except the echo stuff fails.
Code:
@echo off
chmod +x fastboot-linux
echo "Flashin boot.img"
sleep 1
echo ...
cd files
./fastboot-linux flash boot ../boot.img
echo ...
echo "Flashing complete"
echo ...
echo "Erasing cache partition"
sleep 1
./fastboot-linux erase cache
echo ...
echo "Cache partition cleaned"
echo ...
echo "If there were no errors, you can continue"
echo ...
echo "If not, try again!"
echo ...
echo "Enjoy TrickDroid!"
sleep 20
To make it work edit it like this (move the cd files) or go into files and run chmod +x fastboot-linux before running the script. The Mac script has the same problem.
Code:
@echo off
cd files
chmod +x fastboot-linux
echo "Flashin boot.img"
sleep 1
echo ...
./fastboot-linux flash boot ../boot.img
echo ...
echo "Flashing complete"
echo ...
echo "Erasing cache partition"
sleep 1
./fastboot-linux erase cache
echo ...
echo "Cache partition cleaned"
echo ...
echo "If there were no errors, you can continue"
echo ...
echo "If not, try again!"
echo ...
echo "Enjoy TrickDroid!"
sleep 20
Dunno if this will help your general situation though, good luck!
Click to expand...
Click to collapse
It flashed the boot with no issues this time. Still not able to use another ROM. Its so odd. They install but as soon as I unlock the lock screen it just freezes and reboots.
assume you are using the latest clockworkmod recovery for the "OneS"
checked all md5's before flashing anything
can you take the system and boot images from a good sense nandroid or sense rom and put them on your pc in your fastboot.exe folder, open command window cd to fasboot.exe folder and adb reboot bootloader to get into fastboot
then run these commands 3 times
fastboot -w
fastboot erase system
fastboot erase cache
fastboot erase boot
fastboot flash system system.img
fastboot flash boot boot.img
fastboot reboot
you will have restore any user data manully
if you don't have a nandroid copied to you pc from phone do that first
It sounds like maybe you have not wiped everything from cm rom from phone, erasing multiple times may help
Hello everyone,
rhcp was able to locate a method with which to do updates the standard way HTC does them. If you are, for instance, on 1.73 and have the 1.85 OTA .zip file (the one sent from HTC, not a CWM .zip file), you can use this method to place it in the right location and start an update.
Disclaimer:
I do not take responsibility if something goes wrong. PLEASE do this at your own risk.
Please do not use this to go to 1.85 as you may lose root. This is more FYI for future OTA updates or after 1.85 is rooted.
Requirements:
You must have ROOT before doing this. You'll be accessing a location that is not writable without root.
You must have the official OTA file. If someone can help with this portion I can post it here for all users to use if they wish.
Follow these steps to pull the OTA update:
When it shows "downloading" and the OTA completes, if you have root, please do the following:
Code:
adb shell
cd /cache
ls -l
Locate the file ending with .zip here. May look extremely long and should resemble something like OTA_Evita_U_Cingular.........zip
Quit out of adb shell
Code:
adb pull /cache/<file name of the OTA package.zip>
Post that package.zip file on a file share and send me the link and I will add it to the OP.
To update using the OTA file, follow these steps:
Code:
adb push <file name of the OTA package.zip> /mnt/sdcard/
adb shell
su
cp <file name of the OTA package.zip> /cache/update.zip
cd /cache/
mkdir recovery
cd recovery
echo “–update_package=/cache/update.zip” > command
adb reboot recovery
This will cause your device to update using the OTA method that HTC uses to push updates.
If this helped you...PLEASE donate to rhcp, which happens to have had to pay for a new One S due to bricking the first time figuring this out. His donate link is here.
Toss me a Thanks if you think this guide was helpful .
h8rift said:
Hello everyone,
rhcp was able to locate a method with which to do updates the standard way HTC does them. If you are, for instance, on 1.73 and have the 1.85 OTA .zip file (the one sent from HTC, not a CWM .zip file), you can use this method to place it in the right location and start an update.
Disclaimer:
I do not take responsibility if something goes wrong. PLEASE do this at your own risk.
Requirements:
You must have ROOT before doing this. You'll be accessing a location that is not writable without root.
You must have the official OTA file. If someone can help with this portion I can post it here for all users to use if they wish.
Follow these steps to pull the OTA update:
When it shows "downloading" and the OTA completes, if you have root, please do the following:
Code:
adb shell
cd /cache
ls -l
Locate the file ending with .zip here. May look extremely long and should resemble something like OTA_Evita_U_Cingular.........zip
Quit out of adb shell
Code:
adb pull /cache/<file name of the OTA package.zip>
Post that package.zip file on a file share and send me the link and I will add it to the OP.
To update using the OTA file, follow these steps:
Code:
adb push <file name of the OTA package.zip> /mnt/sdcard/
adb shell
su
cp <file name of the OTA package.zip> /cache/update.zip
cd /cache/
mkdir recovery
cd recovery
echo “–update_package=/cache/update.zip” > command
adb reboot recovery
This will cause your device to update using the OTA method that HTC uses to push updates.
If this helped you...PLEASE donate to rhcp, which happens to have had to pay for a new One S due to bricking the first time figuring this out. His donate link is here.
Toss me a Thanks if you think this guide was helpful .
Click to expand...
Click to collapse
nice but this update didnt fix anything anyway. wifi still sucks.
djfrost40 said:
nice but this update didnt fix anything anyway. wifi still sucks.
Click to expand...
Click to collapse
Lol. Be it as it may....this is still a handy method for us to use with future OTA updates.
h8rift said:
Lol. Be it as it may....this is still a handy method for us to use with future OTA updates.
Click to expand...
Click to collapse
I think ATT and HTC just need to issue a refund to all of the unfortunate folks that fell for this phone hook line and sinker...LOL, I tried the update, and wifi is still bad maybe even worse... I just boxed mine up and went back to my HTC Vivid.
djfrost40 said:
I think ATT and HTC just need to issue a refund to all of the unfortunate folks that fell for this phone hook line and sinker...LOL, I tried the update, and wifi is still bad maybe even worse... I just boxed mine up and went back to my HTC Vivid.
Click to expand...
Click to collapse
Sorry to hear that djfrost40. I have literally had zero issues with this phone. No issues mentioned here (besides HTC's software-tweaked multi-tasking) have been evident on my phone. Hope your Vivid treats you well.
h8rift said:
Sorry to hear that djfrost40. I have literally had zero issues with this phone. No issues mentioned here (besides HTC's software-tweaked multi-tasking) have been evident on my phone. Hope your Vivid treats you well.
Click to expand...
Click to collapse
Wow was starting to think I was the only one because like you I have had zero problems with my phone never had to replace it and the multi tasking doesn't really effect me all that much
Sent from My Nocturnalized Beast
The only issue I have is getting my OC to work 100%. Aside from that, I love the phone to death!
This method does not seem to work for me. I have no trouble following the steps but the phone just boots into recovery and nothing else. Also I think there are a couple of "exits" missing from the list of commands right after the creation of the command file, maybe they are implied.
Has anyone else verified this works for them? I am on a rooted, TWRP and still at 1.73. I also tried this method with CWM recovery installed but no luck.
anika200 said:
This method does not seem to work for me. I have no trouble following the steps but the phone just boots into recovery and nothing else. Also I think there are a couple of "exits" missing from the list of commands right after the creation of the command file, maybe they are implied.
Has anyone else verified this works for them? I am on a rooted, TWRP and still at 1.73. I also tried this method with CWM recovery installed but no luck.
Click to expand...
Click to collapse
If you have twrp, why have you flashed a custom Rom?
Sent from my HTC One X using Tapatalk 2
kleeman7 said:
If you have twrp, why have you flashed a custom Rom?
Sent from my HTC One X using Tapatalk 2
Click to expand...
Click to collapse
Yeah, kinda does'nt make sense. Actually I am liking the original HTC sense and also I am not sure which rom to try out.
Update.zip for root??
Is it possible to make an update.zip that we could flash via stock recovery to push su bianary? Just a thought.
kizzle4 said:
Is it possible to make an update.zip that we could flash via stock recovery to push su bianary? Just a thought.
Click to expand...
Click to collapse
Nope, unless you work for HTC and know how to get the key to sign the update zip
Sent from my HTC One XL using Tapatalk 2
What about update zip from say an international version?
kizzle4 said:
What about update zip from say an international version?
Click to expand...
Click to collapse
It will fail once it reads the build prop and realizes that this isn't an international one x, and if it does flash you would have a nice paperweight
Besides what does this accomplish? You can't modify ANY zip file from HTC without breaking the signature. Which makes this method useless
Sent from my HTC One XL using Tapatalk 2
In order for a thread to exist in the development section, it must contain a link to downloadable content. Because this is more of a guide, I'm moving this to general.
Thread Moved.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If you choose not to decide, you still have made a choice"
Sent from my Galaxy Note (i717), using XDA Premium.
What steps in the OP modify if there's not enough space on the cache partition to hold the update.zip? Is it safe to run the following steps in that case:
Code:
adb push <file name of the OTA package.zip> /mnt/sdcard/
adb shell
su
cd /mnt/sdcard/
mv <file name of the OTA package.zip> update.zip
cd /cache/recovery
echo "-update_package=/mnt/sdcard/update.zip" > command
AlxMAX said:
What steps in the OP modify if there's not enough space on the cache partition to hold the update.zip? Is it safe to run the following steps in that case:
Code:
adb push <file name of the OTA package.zip> /mnt/sdcard/
adb shell
su
cd /mnt/sdcard/
mv <file name of the OTA package.zip> update.zip
cd /cache/recovery
echo “–update_package=/mnt/sdcard/update.zip” > command
Click to expand...
Click to collapse
Wondering this too... or even using a larger partition like /data that has 1GB free. :-/
Can someone dd the radio partition for me and link to it?
Wanna make the zips =)
FYI: use this adb command and then pull the img of your sd card -
Code:
C:\adb>adb shell dd if=/dev/block/mmcblk0p17 of=/sdcard/radio.img
taylor.fowler said:
Can someone dd the radio partition for me and link to it?
Wanna make the zips =)
FYI: use this adb command and then pull the img of your sd card -
Code:
C:\adb>adb shell dd if=/dev/block/mmcblk0p17 of=/sdcard/radio.img
Click to expand...
Click to collapse
"removed from dropbox" stock radio from new at&t ota, download taylor.fowler cwm flashable
Cm10.x and sense zips coming soon!
Sent from my One X using xda app-developers app
First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?
mgbelisle said:
First post, please move my thread to a more appropriate category if needed or send me to a duplicate thread if I missed it.
It looks like Android 7/Nougat overwrites the /system/build.prop file on every boot, and I'm trying to figure out - am I editing it wrong or is that a new design? It did not happen in Android 6/Marshmallow. I have a Nexus 5X FWIW, and being a software engineer I am comfortable with adb and fastboot and even wrote a couple Android apps in the past, but the android file system is a black box to me. This is what I did:
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write, edited build.props
$ adb shell
# cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
# echo 'net.tethering.noprovisioning=true' >> /system/build.prop
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
# exit
// Rebooted into stock
$ adb reboot
$ adb shell
$ cat /system/build.prop | tail -n 3
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
// See how the net.tethering line is not there
// Rebooted into twrp
$ adb reboot bootloader
$ fastboot boot /tmp/twrp-3.0.2-2-bullhead.img
// Mounted system read/write
$ adb shell
# cat /system/build.prop | tail -n 4
ro.build.expect.baseband=M8994F-2.6.36.2.20
ro.expect.recovery_id=0xc3fa4d20943e3f2c988a1ee26f54d3982287ac4b000000000000000000000000
net.tethering.noprovisioning=true
// See how the net.tethering is still there
If this is as designed, why does /system/build.prop differ when booting stock vs twrp?
Click to expand...
Click to collapse
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Sent from my SCH-I535 using Tapatalk
Droidriven said:
Have you tried pulling a copy of build.prop then opening it in a text editor and make your changes to it then save it and push the edited copy back to /system?
Click to expand...
Click to collapse
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.
mgbelisle said:
Thanks for the reply Droidriven. I did not try that because the bash commands I did seem like the same thing. But I tried it just now, and it's the same result.
Click to expand...
Click to collapse
You're using a temp recovery aren't you? Are you using that because your bootloader is locked? Are you rooted?
Sent from my SCH-I535 using Tapatalk
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I doubt you'll make the changes and keep them without root.
Sent from my SCH-I535 using Tapatalk
Droidriven said:
I doubt you'll make the changes and keep them without root.
Click to expand...
Click to collapse
Hmm but that doesn't quite make sense to me. I made the changes as root and they've definitely persisted (even when I reboot into twrp) and the changes are there if you do the same thing in Android 6. There are many references to doing changes this way like in http://forum.xda-developers.com/nexus-5x/general/guide-how-to-unlock-tethering-nexus-5x-t3231301 but it's just with Android 7 now, the stock 7 firmware is mounting something on /system/build.prop that is different than what TWRP mounts at /system/build.prop. I'll try the same thing with CyanogenMod Recovery, maybe that will have different results.
mgbelisle said:
Yes I'm using a temp recovery to make the edit as root, twrp specifically, like my shell commands show in the first post. My bootloader does happen to be unlocked, but the reason I'm using the temp recovery is so my firmware stays stock so I can use Android Pay. Which answers your last question incidentally, no I'm not rooted.
Click to expand...
Click to collapse
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Sent from my SCH-I535 using Tapatalk
Droidriven said:
I don't see where actually flashing TWRP would cause a problem instead of using a temp recovery. Your stock firmware will still be full stock, I don't think which recovery you have would cause a problem with android pay.
Click to expand...
Click to collapse
Yeah I understand that, but even though it wouldn't cause a problem it doesn't seem that would be necessary. Interestingly, when I'm booted into twrp with /system mounted, the build.prop file has the contents and timestamp I expect.
# ls -la /system/build.prop
-rw-r--r-- 1 root root 4919 Dec 17 16:52 /system/build.prop
But when booted into system (stock Android 7 like I mentioned) the timestamp shows a very different file is being mounted.
$ ls -la /system/build.prop
-rw-r--r-- 1 root root 4876 2009-01-01 03:00 /system/build.prop
More info, flashing twrp as opposed to just booting it had the same effect. I tried that because of what you said Droidriven, BTW thanks for your help so far.
Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...
tronik said:
Ever get any farther with this? I'm having the same issues on my Stock bl-unlocked Google Play N5X 7.1.1 NMF26F
Booting into TWRP, pulling /system/build.prop, editing, mounting /system RW, replacing /system/build.prop, still not making changes.
Also for some reason every SuperSU attempt I make (for any versions since 2.78 (and 2.79+) fails at Patching sepolicy - Failure, aborting.
Ugh...
Click to expand...
Click to collapse
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip
mgbelisle said:
I never figured out why it was happening, but when I flashed TWRP and installed SuperSU (which were successful for me, no errors) then the problem went away and I was able to persist edits to /system/build.prop. That is odd how SuperSU installation fails for you with that error. I have the exact same setup as you Nexus 5X 7.1.1 NMF26F and following these instructions I installed SuperSU without error.
http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
The version I used were twrp-3.0.2-2-bullhead.img and SR5-SuperSU-v2.78-SR5-20161130091551.zip
Click to expand...
Click to collapse
Appreciate the prompt response. Yeah, I'm using twrp 3.0.2-2 also, and I've tried numerous versions of SuperSU all failing with the same sepolicy update error... I just don't get it. Never had these problems before Nougat.
Just tried with the specific one in the article you linked:
"Patching sepolicy
--- Failure, aborting"
So weird. Anyway, glad to know yours was fixed!
edit:
I finally decided to try this other root method (phh) and it is working: http://www.theandroidsoul.com/npf10c-root-android-7-1-1-nexus-5x-6p/
I don't know why my trusty SuperSU no longer works.
Oh well.