Develop Bugs

Christmas gift to all flashjunkies

These rom's is not any releases but only Christmas presents for all the flashjunkies on XDA.
My little contribution to the hero community
NR1. CM-6.2.0-RC0-Hero, Built this evening,well all know what it is,apps2sd etc.. + all google apps, everything included.
Wipe of all + ext partion
Flash rom
Well you know yourselves what you should do.
Here > http://www.elelinux.se/extra/CM-6.2.0-RC0-Hero-signed.zip
NR2. Gingerbread_2.3.1_r1_alpha1 This is a pure alpha, borrowed some from Lox_Dev particular solution on how to boot up
How to install then
1: Wipe of all in recovery
2: In recovery, adb shell run command
Code:
mount /system && rm -rf /system/* && umount /system
then flash the rom
3: Reboot boot and then when everything is ready
4: Reboot to recovery and flash gapps and reboot again
5: Enjoy
Rom here > http://www.elelinux.se/extra/Gingerbread_2.3.1_r1_alpha1.zip
Gapps http://www.elelinux.se/extra/gapps-mdpi-2010-10-20-signed.zip
What works in cm rom everything I tried in all cases,and in gingerbread well it's a surprise, at least it is booting up
Credits to erasmux for the kernelsource and to Lox_Dev for the gingerbread rom
Merry Christmas, I wish all

I'm the first one who will say thanx man for youuuuu good work
downloading now and i will leave my feedback soon

thanks and theres me just setting up my new rom lol , merry xmas and a biggg thank you

it gave me an error that i can't remove system/lost+found for CM7

elelinux were do i put the comand mount /system && rm -rf /system/* && umount /system ,, sorry mate a bit new to all this

and fastboot doesn't do anything just say Failed
or adb shell show me an erorr about dev/block/mtdblock3

yadabwoy said:
elelinux were do i put the comand mount /system && rm -rf /system/* && umount /system ,, sorry mate a bit new to all this
Click to expand...
Click to collapse
boot to recovery mod by power and menu and connect ur device by the usb and write in CMD in windows {7 or vista press WINDOWS Button AND R } and write cmd and press enter then write the directory to the sdk in cmd like this
cd C:\AndroidSDK\tools
Click to expand...
Click to collapse
then write adb shell and u will see this # write the command after it directly
required :
SDK
HTC SYNC

sameh_elhakim said:
it gave me an error that i can't remove system/lost+found for CM7
Click to expand...
Click to collapse
I got that. I flashed anyway and it still boots

+1 ..........

sameh_elhakim said:
it gave me an error that i can't remove system/lost+found for CM7
Click to expand...
Click to collapse
You don't need to only flash

elelinux said:
You don't need to only flash
Click to expand...
Click to collapse
sry i didn't understood what u meant
if u mean that i have to write the adb shell command so i did that and all errors above
and i tried to only flash without any command with adb shell but it's failed too

Hmm, the only problem I have is that WiFi gets stuck on obtaining an IP address.
Other than that, it's actually not too bad

sameh_elhakim said:
sry i didn't understood what u meant
if u mean that i have to write the adb shell command so i did that and all errors above
and i tried to only flash without any command with adb shell but it's failed too
Click to expand...
Click to collapse
What I mean is wipe of all(factory reset and dalvik cache), then the command don't care about the errors,then flash and reboot should work for all.

Xtiro said:
Hmm, the only problem I have is that WiFi gets stuck on obtaining an IP address.
Other than that, it's actually not too bad
Click to expand...
Click to collapse
Well as I say, pure alpha but the direction is correct in all cases. the graphics are ok,so for those who have the strength, this is a good rom to build on.

thanks for the reply , i get an error saying mount is not recognized as an internal or external comand ??

This gingerbread actually works pretty well and smooth! I also get the "obtaining address", but it scans okay.
Btw, why ADW and not stock launcher?
Keep it up, Ele

Like i said gooood work :
for who want to know whats working and whats not.:
Working
1-calls
2-SMS
3-High Speed
4-Sounds (ringtons and media )
5-u can install any application on it
6-APP2SD Working Perfectly !!!
7-Gallery 3D
Not Working :
1-WIFI
2-USB doesn't detected
3- Something is worng with Battery use in option i thing the top toolbar have some errors or something in colors
4-Camera
5-No arabic the dev. deleted it and this the worst thing in this release (only for Arabian )
6- Sensor doesn't work at all (Rotation ... etc)
i will update the post if there is anything else....Enjoy and thanx for the dev (LOX & elelinux)

i just hope to see kernel .34 for our htc hero gingerbread soon this will fix alot and gave us alot of speed i think

is it necessary to update from your 2.2.1_update1? Thanks!

Do you have plan to fix flash?

[Q] Unrooting

Hi All,
This is just a quick 2 part question as I see many threads for the GNEX on rooting, but none very concrete on removing root. I've tried searching, but I must have missed it.
So, my questions are:
1. Once rooted via whatever method (I used fastboot method myself, thanks efrant for teaching the fastboot stuff), how do I unroot this thing to bring it back to stock configuration?
2. To make the unit truly stock again, can I just use fastboot and flash a factory google image? I know doing this will eliminate all my data, but will it remove all traces of any rooting done? (Insecure Kernal, SU, Busybox and whatever else)?
Please let me know.
Thanks guys... wasn't planning on rooting, but I miss the ability to do it. lol

1. See two.
2. Yes.
Flashing the stock image will bring your phone back to an out-of-the-box state.
Sent from my Galaxy Nexus using Tapatalk 2

infazzdar said:
1. See two.
2. Yes.
Flashing the stock image will bring your phone back to an out-of-the-box state.
Sent from my Galaxy Nexus using Tapatalk 2
Click to expand...
Click to collapse
Thanks man,
Makes me feel better about my decision to root this phone.
Appreciate the reply.

If you installed Superuser to system when you rooted then you'll need to remove that also but here are the basic adb commands for the job (make sure you have data and system mounted via CWM so you have access):
Code:
adb shell
rm /system/bin/su
mount -o remount,ro -t ext4 /dev/block/mmcblk0p1 /system
exit
BusyBox is another matter since CWM installs it to sbin every time you boot with it. Perhaps someone has a better idea (?), but from messing around a bit the other night the best method I've come up with is to use BusyBox to remove BusyBox, as follows:
Code:
adb shell
cd /sbin
cp busybox /data/local/tmp/busybox
chmod 06755 /data/local/tmp/busybox
rm busybox
/data/local/tmp/busybox rm `/data/local/tmp/busybox find -follow -maxdepth 1 -type l`
/data/local/tmp/busybox rm /data/local/tmp/*
exit
that second to last line gets rid of all the stray symlinks busybox left behind, not sure if CWM leaves any of those recovery/symlinks in sbin also or if those should be removed as well; perhaps someone else can fill us in on that point!

osm0sis said:
If you installed Superuser to system when you rooted then you'll need to remove that also but here are the basic adb commands for the job (make sure you have data and system mounted via CWM so you have access):
Code:
adb shell
rm /system/bin/su
mount -o remount,ro -t ext4 /dev/block/mmcblk0p1 /system
exit
BusyBox is another matter since CWM installs it to sbin every time you boot with it. Perhaps someone has a better idea (?), but from messing around a bit the other night the best method I've come up with is to use BusyBox to remove BusyBox, as follows:
Code:
adb shell
cd /sbin
cp busybox /data/local/tmp/busybox
chmod 06755 /data/local/tmp/busybox
rm busybox
/data/local/tmp/busybox rm `/data/local/tmp/busybox find -follow -maxdepth 1 -type l`
/data/local/tmp/busybox rm /data/local/tmp/*
exit
that second to last line gets rid of all the stray symlinks busybox left behind, not sure if CWM leaves any of those recovery/symlinks in sbin also or if those should be removed as well; perhaps someone else can fill us in on that point!
Click to expand...
Click to collapse
So flashing a Google factory image won't remove root? Or it will, but won't remove all evidence if someone went searching around trying to deny warranty.
When I rooted, I used the method of flashing recovery, then installed the su.zip via recovery. When I unrooted I simply flashed a factory image.
when you say installed superuser to system I'm guessing you mean something more advanced than the typical root process, correct?
Sent from my Galaxy Nexus using XDA

thos25 said:
So flashing a Google factory image won't remove root? Or it will, but won't remove all evidence if someone went searching around trying to deny warranty.
When I rooted, I used the method of flashing recovery, then installed the su.zip via recovery. When I unrooted I simply flashed a factory image.
when you say installed superuser to system I'm guessing you mean something more advanced than the typical root process, correct?
Sent from my Galaxy Nexus using XDA
Click to expand...
Click to collapse
Flashing the factory system image DOES remove root (and busybox and anything else you changed on the ROM).There is no need to do anything that osm0sis said to do.
And there is no "more advanced" process of rooting. Root is two files placed on you system: /system/bin/su and /system/app/Superuser.apk. Nothing more. (Whether you place them there yourself, or have CWM do it for you, is irrelevant.) Remove those those and root is gone.
Sent from my Galaxy Nexus using Tapatalk 2

if you grab wugfresh's toolkit itll do all of that with one-click convenience. thats what I do to un-root my Nexus.

Zbraptorsdr said:
if you grab wugfresh's toolkit itll do all of that with one-click convenience. thats what I do to un-root my Nexus.
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?p=21936493
Sent from my Galaxy Nexus using Tapatalk 2

efrant said:
Flashing the factory system image DOES remove root (and busybox and anything else you changed on the ROM).There is no need to do anything that osm0sis said to do.
Click to expand...
Click to collapse
Right, I was referring to "unroot"ing without reflashing the system.img, since my intent with that method was to keep all settings, etc. as-is, just remove all traces of root.

osm0sis said:
Right, I was referring to "unroot"ing without reflashing the system.img, since my intent with that method was to keep all settings, etc. as-is, just remove all traces of root.
Click to expand...
Click to collapse
Yup, you would need to remove it manually if you were running a custom ROM, but with a stock ROM, flashing the system partition only WOULD leave all your data/settings as is.

osm0sis said:
BusyBox is another matter since CWM installs it to sbin every time you boot with it.
Click to expand...
Click to collapse
IS this true? Can someone confirm? And is it true for all phones?

Zbraptorsdr said:
if you grab wugfresh's toolkit itll do all of that with one-click convenience. thats what I do to un-root my Nexus.
Click to expand...
Click to collapse
The easiest way to do it, just click and its does it on its own.

The-Droidster said:
IS this true? Can someone confirm? And is it true for all phones?
Click to expand...
Click to collapse
Just wanted to clear this up now that I'm a bit more wise on the subject. The sbin stuff doesn't matter since it's all part of the ramdisk, and gets generated on each boot (to recovery or OS) and otherwise doesn't exist. No need to delete anything but su. :good:

osm0sis said:
Just wanted to clear this up now that I'm a bit more wise on the subject. The sbin stuff doesn't matter since it's all part of the ramdisk, and gets generated on each boot (to recovery or OS) and otherwise doesn't exist. No need to delete anything but su. :good:
Click to expand...
Click to collapse
he means, of course, "su" as in /system/bin/su AND /system/app/Superuser.apk. partially correct, i think, ramdisk is only used for early OS boot. Ramdisk + kernel = boot.img.
Recovery is on a different partition, for starters, and AFAIK, deploys needed files to a temporary location on the phone's ram or in the file system, which would be the recovery partition. Busybox gets placed in there as well.
Sent from my i9250

stock kernel has a ramdisk but not all kernels are packaged with one. recovery also has a ramdisk, just as it also has a kernel. Decompile/split/unzip one some time and you'll see /sys/ and /proc/ and /sbin/ all get generated from the ramdisk. And yes, if you for some reason put Superuser.apk or SuperSU.apk in /system/app/ (a completely unnecessary step), then naturally they need to go too.

[HOW-TO] [GSM & CDMA] How to root without unlocking bootloader (for ITL41D to JRO03O)

[HOW-TO] [GSM & CDMA] How to root without unlocking bootloader (for ITL41D to JRO03O)
As of Oct 10, 2012: Google has patched this vulnerability starting with JRO03U. That is to say, this works on versions of ICS and JB from ITL41D to JRO03O inclusive. It will not work for JRO03U or newer. (My previous guide found here only worked on Android versions 4.0.1 and 4.0.2, i.e., ITL41D/F and ICL53F.
Once you have root, you can use segv11's BootUnlocker app to unlock your bootloader without wiping anything. Easy as pie!
Disclaimer: I take no credit for this exploit or the implementation of it. All credit goes to Bin4ry and his team. I just isolated the parts required for the GNex, modified it slightly and eliminated the script.
So, it looks like Bin4ry (with the help of a couple of others) has managed to find a way to exploit a timing difference in the "adb restore" command. See source here. (Although this may be old news to some, I hadn't seen it before a few days ago.) This is more for informational purposes, as having a Nexus device, we are able to backup our data, unlock the bootloader and restore the backup, so this is guide is not really that useful for most, but you still have those users who are scared to unlock their bootloader. It is useful however, for those with a broken power button, as it allows them to unlock their bootloader without the power button.
How this works
The way this works is as follows: the "adb restore" command needs to be able to write to /data to restore a backup. Because of this, we can find a way to write something to /data while this is being done. Now, Android parses a file called /data/local.prop on boot. If the following line exists in local.prop, it will boot your device in emulator mode with root shell access: ro.kernel.qemu=1. So, if we can place a file called local.prop with the aforementioned line in /data, once your device boots, it will boot in emulator mode and the shell user has root access, so we now can mount the system partition as r/w.
So what does this all mean:
You can now root any version of ICS and JB released to-date without having to unlock your bootloader (and without losing your data).
Moreover, you should now be able to root your device even if your hardware buttons are not working.
Additionally, this allows those who have not received an OTA update and want to apply it without having an unlocked bootloader or root to do so by copying the OTA update to /cache from /sdcard.
Notes:
1) Please read the entire post before attempting this.
2) This does not wipe any of your data, but I take no responsibility if something happens and you lose your data. Maybe consider doing a backup as per this thread before attempting this.
3) This assumes that you have USB Debugging enable on your device (Settings > Developer Options > Enable USB Debugging) and the drivers for your device installed on your computer. For the drivers, I would recommend you remove all old drivers and install these. If you don't know how to install them, or are having issues, look here.
4) This obviously needs to be done over ADB, as you cannot run adb in a terminal emulator on-device. If you do not have ADB, I've attached it in the zip (Windows and Linux versions). Unzip all files.
Step-by-step:
1) Download the attached files to your computer and unzip them;
2) Open a command prompt in that same directory;
3) Copy the root files to your device:
adb push su /data/local/tmp/su
adb push Superuser.apk /data/local/tmp/Superuser.apk
4) Restore the fake "backup": adb restore fakebackup.ab Note: do not click restore on your device. Just enter the command into the command prompt on your PC and press the enter key.
5) Run the "exploit": adb shell "while ! ln -s /data/local.prop /data/data/com.android.settings/a/file99; do :; done" Note: when you enter this command, you should see your adb window flooded with errors -- this is what is supposed to happen.
6) Now that the "exploit" is running, click restore on your device.
7) Once it finishes, reboot your device: adb reboot Note: Do not try and use your device when it reboots. Running this exploit will reboot your device into emulator mode, so it will be laggy and the screen will flicker -- this is normal.
8) Once it is rebooted, open a shell: adb shell
Note: Once you do step 8, your should have a root shell, i.e., your prompt should be #, not $. If not, it did not work. Start again from step 4. (It may take a few tries for it to work. Thanks segv11.)
Now we can copy su and Superuser.apk to the correct spots to give us root.
9) Mount the system partition as r/w: mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
10) Copy su to /system: cat /data/local/tmp/su > /system/bin/su
11) Change permissions on su: chmod 06755 /system/bin/su
12) Symlink su to /xbin/su: ln -s /system/bin/su /system/xbin/su
13) Copy Superuser.apk to /system: cat /data/local/tmp/Superuser.apk > /system/app/Superuser.apk
14) Change permissions on Superuser.apk: chmod 0644 /system/app/Superuser.apk
15) Delete the file that the exploit created: rm /data/local.prop
16) Exit the ADB shell: exit (May have to type exit twice to get back to your command prompt.)
17) Type the following (not sure if this is needed for the GNex, but it shouldn't matter): adb shell "sync; sync; sync;"
18) Reboot: adb reboot
19) Done. You now should have root without having to unlock your bootloader. If you want to unlock now, you can without wiping anything. See segv11's app linked at the beginning of this post.
Note: If you still do not have root access after doing these steps, redo them and add this step between 10 and 11:
10b) Change the owner of su: chown 0.0 /system/bin/su (Thanks maxrfon.)

I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work

Lorenzo_9 said:
I've done all. It installs supersuser app but the phone is not really rooted and apps that requires it doesn't work
Click to expand...
Click to collapse
Did you try opening the Superuser app?
What happens when you open an app that requires root? Do you get the request for su access?

You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted

Lorenzo_9 said:
You can open the app but whith apps that requires root there are no requestes and they don't... Even using root checker you see that you're not rooted
Click to expand...
Click to collapse
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.

efrant said:
Re-run the entire procedure again (including pushing the su and Superuser.apk files). When I had done it, I used the latest version of su and Superuser.apk, but when I uploaded the files in the attachment in post #1, I used the files that Bin4ry had in his package, which I assume are older. Regardless, re-download the attachment in the first post and try it again.
Click to expand...
Click to collapse
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?

Lorenzo_9 said:
Ok I'll do it and then I'll report you what happens. So now have you updated su and superuser.apk?
Click to expand...
Click to collapse
Yes, I put the latest versions in the zip in the first post.

I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.

serty4011 said:
I can confirm that this works, and also that step 10b was not needed for me. This is the first time I have not used a toolkit so if I can do it, anyone can.
Running a Verizon Galaxy Nexus, this allowed me to update to the leaked Jelly Bean OTA with a locked bootloader. I first flashed stock 4.0.4 and locked the bootloader. I then used the exploit to gain root access, allowing me to apply IMM76Q and JRO03O OTA updates via stock recovery. (Rebooting between updates.) Thank you for creating a guide that this newb could easily understand and follow.
Click to expand...
Click to collapse
Thanks for confirming that step was not needed.

Thanks!
Bookmarked for future reference :good:

does it work on nexus 7 ?

dacc said:
does it work on nexus 7 ?
Click to expand...
Click to collapse
Yes, it should.

thans for quick response

Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?

wictor1992 said:
Works fine for my GNex, big thanks! How about putting it into a script for non-advanced users here?
Click to expand...
Click to collapse
Glad you got it working!
As for putting it into a script, I could but I'd rather not. As with most of the guides that I have written up, I purposely do not put things into a script so that people would actually go through all the steps and, by doing so, maybe get an understanding of what they are actually doing, and hopefully learn something in the process. If I would have packaged it up into a script, a lot of the less experienced users would not even try to go through the steps -- they would just use the script, and no one learns anything yet again. See here for some discussion on one-click scripts. Granted, blindly following a step-by-step is not much better, but I have tried to put comments and explanations throughout to facilitate learning. It's about the journey...
P.S.: I would appreciate it if no one else posts a script in this thread.

efrant said:
P.S.: I would appreciate it if no one else posts a script in this thread.
Click to expand...
Click to collapse
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"

Zepius said:
can i make a script that just puts in big text "STOP USING TOOLKITS AND 1 CLICKS"
Click to expand...
Click to collapse
LOL! Yes, sure, that's one script I don't mind being posted. LOL!

Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).

wictor1992 said:
Heh, fair enough. I think I'm learning a bit about adb
One question: I can't replace system APKs by installing them, it tells me that there is a signature conflict. How can I fix that? I thought it shouldn't happen after rooting. (I'm trying to install the "international" velvet.apk).
Click to expand...
Click to collapse
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.

when running adb after running the command where i tell it to restore fake restore and then while the "exploit" is running ikeep getting , in cmd, link failed, no such file or directory, and it just keep doing that. is this normal or did i do something wrong.
efrant said:
Let's try to keep this thread on-topic please.
But to answer your question, don't install the apk. Using a file explorer that has root access, copy it to /system/app (after making sure that system is r/w) and make sure the permissions are set to match the other apks in that directory.
Click to expand...
Click to collapse

Messed up build.prop, phone won't boot, can I push build.prop via adb?

My phone is on 4.1.2 still, and I had edited the build.prop to not update to 4.2 (after hearing all the problems). Now that 4.2.2. is out i decided to update, I tried restoring the build.prop file that i had as a backup of 4.1.2. I guess I must've changed some text without realizing.
Now my phone is stuck, it gives me the Google Logo with the unlocked sign, and then it disappears...and where there should be a boot animation...black. Nothing. Stays like that.
Any way I can push the build.prop via the computer using abd or something?

Not sure if adb will push to system, since i had an issue pulling from system.
Are you rooted?
You could try booting to recovery to enable adb, then remount system as r/w
adb shell
su
mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
cd /system/ NOT SURE IF THIS IS REQUIRED, I'D TRY IT FIRST WITHOUT THIS LINE TO SEE
chmod 644 build.prop
chown root.root build.prop
exit
I've never had to do that, but i belive my linux syntax is correct, i pulled it from http://www.linux.org/article/view/file-permissions-chown. This is only of course if the build.prop failed bc on the incorrect permissions and ownership(maybe you had it on your sdcard). If this doesn't work, it looks like you'll be fastboot flashing a system image. [Sometimes the time and date of your build.prop may affect the ability to ota even if you get it to boot, to which you would need to reflash the system image anyway]. But i'd like to know if you try this and it works.

So what I ended up doing was installing clockwork recovery and then installing an odexed Rom version of the stock image of 4.1.2. Everything works, nothing got wiped.
Sent from my GT-N7100 using xda app-developers app

bodh said:
Not sure if adb will push to system, since i had an issue pulling from system.
Are you rooted?
You could try booting to recovery to enable adb, then remount system as r/w
adb shell
su
mount -o remount,rw -t ext4 /dev/block/mmcblk0p1 /system
cd /system/ NOT SURE IF THIS IS REQUIRED, I'D TRY IT FIRST WITHOUT THIS LINE TO SEE
chmod 644 build.prop
chown root.root build.prop
exit
I've never had to do that, but i belive my linux syntax is correct, i pulled it from http://www.linux.org/article/view/file-permissions-chown. This is only of course if the build.prop failed bc on the incorrect permissions and ownership(maybe you had it on your sdcard). If this doesn't work, it looks like you'll be fastboot flashing a system image. [Sometimes the time and date of your build.prop may affect the ability to ota even if you get it to boot, to which you would need to reflash the system image anyway]. But i'd like to know if you try this and it works.
Click to expand...
Click to collapse
Yes, you need to 'cd /system' before typing the commands to change permissions and ownership, as you have them.
Sent from my Nexus

ksc6000 said:
So what I ended up doing was installing clockwork recovery and then installing an odexed Rom version of the stock image of 4.1.2. Everything works, nothing got wiped.
Sent from my GT-N7100 using xda app-developers app
Click to expand...
Click to collapse
How did you install clockwork recovery when it was not booting at all ??! Could you please guide me ? I actually have an LG Optimus G stuck in boot loop ..... (T_T)

Claureid said:
How did you install clockwork recovery when it was not booting at all ??! Could you please guide me ? I actually have an LG Optimus G stuck in boot loop ..... (T_T)
Click to expand...
Click to collapse
Then you should go to your own forums, as 99% of the info here wont do you any good

Claureid said:
How did you install clockwork recovery when it was not booting at all ??! Could you pbootlease guide me ? I actually have an LG Optimus G stuck in boot loop ..... (T_T)
Click to expand...
Click to collapse
I don't think you can do that with your phone what I did. But here is the gu ide that I used to temporarily boot into clockwork recovery to use it:
http://forum.xda-developers.com/showpost.php?p=23229578&postcount=3

ksc6000 said:
I don't think you can do that with your phone what I did. But here is the gu ide that I used to temporarily boot into clockwork recovery to use it:
http://forum.xda-developers.com/showpost.php?p=23229578&postcount=3
Click to expand...
Click to collapse
Thanked you buddy !!

Question Help with bootloop after editing settings file

Hey folks,
Last night I was editing a file located under "data/system/users/0/settings_ssaid.xml" and upon rebooting my phone, it's been stuck in a boot loop. I have an original copy saved in a different folder, but unable to access anything to replace it.
Is there any specific fastboot command I can run to swap the files (adb push, pull etc)? Only boot slot A is giving me an issue, and I was reading flashing system.img would be able to help, but I don't wanna do anything I'm unsure will wipe any of my data where I'd have to start over unless I've recovered some of that data first.
If I do have to flash any stock images, pls post the instructions for clarity.
Thanks in advance.

Assuming adb can actually access your device, while it's stuck in a boot loop (test this by running 'adb devices' and see if you receive a response)
You can run the following command to list all the files in your specific folder.
adb shell ls FILEPATH
Every file in your specific folder will be listed. You can then do the following to pull/push your file
adb pull FILEPATH
adb push FILENAME FILEPATH
Of course you need to place the file that you want to push in your ADB folder.
Mind though, that simply replacing your edited file with the backup might not solve your bootloop.
You can always look up available commands here
adb shell ls - Android ADB Shell Commands Manual

Morgrain said:
Assuming adb can actually access your device, while it's stuck in a boot loop (test this by running 'adb devices' and see if you receive a response)
Click to expand...
Click to collapse
Yes, I can access adb and my device while it's booting up, but once it reboots I lose connection. Unless I can interrupt the process I'd have to be very quick in my typing to copy files lol.
Even with the few seconds I have to type some commands to access the directory of the file I edited, I do get a permission denied error.
Would swapping to Slot B during boot allow me into the system, or even flashing the system.img file?

RetroTech07 said:
Yes, I can access adb and my device while it's booting up, but once it reboots I lose connection. Unless I can interrupt the process I'd have to be very quick in my typing to copy files lol.
Even with the few seconds I have to type some commands to access the directory of the file I edited, I do get a permission denied error.
Would swapping to Slot B during boot allow me into the system, or even flashing the system.img file?
Click to expand...
Click to collapse
No because your file is on /data.
The issue is that you can't push your file to /scard since (I guess) you can't even get beyond to the point where /sdcard is mounted.
So copying it from /sdcard will likely be too late in the boot process.
Pushing directly into /data does not work either as you would have to be root. In the old days you could run and in root mode but I'm not sure that is still possible.
Factory reset will work.
On devices with separate recovery partition it would be possible to change recovery to allow adb access to /data so then push old file via recovery... But I would not know how to do that on Pixel as recovery is s part of the boot partition.

So effectively, it's likely you're only solution is to do a full firmware flash along with wipe.

I would first try a full flash removing the -w to avoid the wipe. It may work.

TonikJDK said:
I would first try a full flash adding the -w to avoid the wipe. It may work.
Click to expand...
Click to collapse
Probably a typo, but I think you meant you need to "remove" the -w to avoid a wipe.

Lughnasadh said:
Probably a typo, but I think you meant you need to "remove" the -w to avoid a wipe.
Click to expand...
Click to collapse
Thank you! My post is fixed.

TonikJDK said:
I would first try a full flash removing the -w to avoid the wipe. It may work.
Click to expand...
Click to collapse
Ok, I'm rooted so to be sure I don't mess anything up, lol can you list the steps just as a precaution?
Obviously I'd be in fastboot / recovery mode, then perform a flash-all but remove the -w so as to not erase my data?
Once the system boots, all of my texts and setup should remain as is, or do I have to go and recover it?
Would I be able to install the OS again on the inactive slot to recover data, or does that not work that way?

RetroTech07 said:
Would I be able to install the OS again on the inactive slot to recover data, or does that not work that way?
Click to expand...
Click to collapse
Nope ... there is only 1 data partition, so even when you flash the OS to the inactive slot, it would still use the same data partition. Moreover, it is then likely to upgrade/convert some files on /data which might result in not being able to go to the previous version in the old slot.

RetroTech07 said:
Ok, I'm rooted so to be sure I don't mess anything up, lol can you list the steps just as a precaution?
Click to expand...
Click to collapse
See https://forum.xda-developers.com/t/...thout-wiping-data-and-retaining-root.4356065/

so, unfortunately doing a full flash without wiping data didn't work. I'm almost inclined to believe that if TWRP was available for the P6/P, that I could go and push the file I had saved back into the directory of where it was and save myself from this mess.
I'm kicking myself because I'm usually backing up my data before I modify any system files, but this one time I hadn't done so and I had Google's backup turned off at the time, so I'm gonna have to lose some text messages over the last few days with some folks I enjoy speaking to. I do have some saved from late last week, but nothing from the weekend up until now.

As you said you can access ADB while booting, why not push/remove/replace the file while booting, even if this takes multiple boots to perform all commands, it should work assuming you can also use SU, if you can't, none of the below will work.
Code:
adb push <backup file location> /sdcard
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /sdcard/settings_ssaid.xml /data/system/users/0/
chmod 600 data/system/users/0/settings_ssaid.xml
I don't know why it's affecting your boot though, there's a .fallback file that the system should fall back to when the system notes that this file is corrupt.
If the above doesn't work, and you could try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /data/system/users/0/settings_ssaid.xml.fallback /data/system/users/0/settings_ssaid.xml
If that doesn't work, try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
And reboot, but again, I don't know why you're bootlooping from this, that file shouldn't be integral to booting.
Also, if you need to back up your data, why not just boot to boot_b, if it's not causing you issues? You really shouldn't have to reset your device to fix one problem - you could do a /data & /sdcard pull while booted to boot_b, or just run something like Titanium & SMS backup/restore.

DanielF50 said:
As you said you can access ADB while booting, why not push/remove/replace the file while booting, even if this takes multiple boots to perform all commands, it should work assuming you can also use SU, if you can't, none of the below will work.
Code:
adb push <backup file location> /sdcard
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /sdcard/settings_ssaid.xml /data/system/users/0/
chmod 600 data/system/users/0/settings_ssaid.xml
I don't know why it's affecting your boot though, there's a .fallback file that the system should fall back to when the system notes that this file is corrupt.
If the above doesn't work, and you could try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
cp /data/system/users/0/settings_ssaid.xml.fallback /data/system/users/0/settings_ssaid.xml
If that doesn't work, try:
Code:
adb shell
su
rm data/system/users/0/settings_ssaid.xml
And reboot, but again, I don't know why you're bootlooping from this, that file shouldn't be integral to booting.
Also, if you need to back up your data, why not just boot to boot_b, if it's not causing you issues? You really shouldn't have to reset your device to fix one problem - you could do a /data & /sdcard pull while booted to boot_b, or just run something like Titanium & SMS backup/restore.
Click to expand...
Click to collapse
I appreciate the help but I can't go back as I've already wiped everything minutes before you sent this. If I had the above commands sooner I would have loved to try, although I'm not really sure why this became an issue in the first place. I tried booting to slot B, using both patched and normal boot images but it wasn't working, unless I did something wrong.
All I remember is installing an app to edit UDID for individual apps that I've used in the past, but because it wasn't identifying root properly, to which I'm assuming is an Android 12 issue, I decided to follow instructions for manually editing such IDs in the file I edited in my OP.
After I rebooted, I remember the main system about to start and seeing the Google boot logo with a percentage # go all the way up to 90%, then that's where the boot loop started. My guess at this point is either the app or the file I edited caused an issue, because I did nothing else up until that point. What's odd, is that after I formatted the whole system and rebooted, I saw the same percentage appear on screen after installing the same app to see if that was the issue, but it booted fully just fine.
I was going to just keep fighting this and keep the phone the way it was until I could maybe fix everything, but figured there's nothing I could do at this point since trying a flash of everything failed. I was up until 5am last night and it's almost 4 am with me trying to fix this. I feel defeated and upset because I don't believe I had to wipe this in the first place, and could have likely saved all of my data. I didn't have Google's backup option turned on and hadn't backed up my text messages because I was dumb. I'm more upset with myself than the phone honestly.

RetroTech07 said:
I appreciate the help but I can't go back as I've already wiped everything minutes before you sent this. If I had the above commands sooner I would have loved to try, although I'm not really sure why this became an issue in the first place. I tried booting to slot B, using both patched and normal boot images but it wasn't working, unless I did something wrong.
All I remember is installing an app to edit UDID for individual apps that I've used in the past, but because it wasn't identifying root properly, to which I'm assuming is an Android 12 issue, I decided to follow instructions for manually editing such IDs in the file I edited in my OP.
After I rebooted, I remember the main system about to start and seeing the Google boot logo with a percentage # go all the way up to 90%, then that's where the boot loop started. My guess at this point is either the app or the file I edited caused an issue, because I did nothing else up until that point. What's odd, is that after I formatted the whole system and rebooted, I saw the same percentage appear on screen after installing the same app to see if that was the issue, but it booted fully just fine.
I was going to just keep fighting this and keep the phone the way it was until I could maybe fix everything, but figured there's nothing I could do at this point since trying a flash of everything failed. I was up until 5am last night and it's almost 4 am with me trying to fix this. I feel defeated and upset because I don't believe I had to wipe this in the first place, and could have likely saved all of my data. I didn't have Google's backup option turned on and hadn't backed up my text messages because I was dumb. I'm more upset with myself than the phone honestly.
Click to expand...
Click to collapse
Ah damn, I was too late!
The 90% thing sounds like the November Google Play services updated - mine updated yesterday and I got the same thing when I rebooted, maybe something between the two got corrupt.
Yeah, I get that, I've had more than my fair share of self inflicted (and not so self inflicted) problems that have lost me data but you live and you learn I suppose