I have followed both parts of Toast's root guide. I have then flashed 1.0.8 of JoeyKrim's rooted stock build ROM - odex version if that really matters, though I doubt it.
I find that using ConnectBot on the device, I can indeed type SU and get the hash prompt. So far so good, but even after killing all apps, I cannot manage to delete the Sprint*.apk files. I get a read-only filesystem error.
I'm assuming this is possible through booting into my custom recovery, but I thought one of the benefits to the NAND unlock was ability to do this "live" within Android.
Am I missing something, or is /system/app just a special case of read-only settings when running normally?
First, please post in the proper section. This is development not q&a. Second, you need to remount. It defaults to read only, but can be changed. Enter the following command sequence:
su
mount -o rw,remount /dev/block/mtdblock4 /system
rm /system/app/Sprint*
Beware, that gets rid of visual voicemail too. I use Google voice personally, but it should be known.
axlebot said:
First, please post in the proper section. This is development not q&a. Second, you need to remount. It defaults to read only, but can be changed. Enter the following command sequence:
su
mount -o re,remount /dev/block/mtdblock4 /system
rm /system/app/Sprint*
Beware, that gets rid of visual voicemail too. I use Google voice personally, but it should be known.
Click to expand...
Click to collapse
Well, I figured this was more specific than Q&A since it was directly related to root and custom ROM, and I've seen those questions asked here in numerous threads...
As to your point, I did try that, but kept getting the same error. Have confirmed ability to write to /system outside of /system/app, which seems odd.
Sorry the evo auto corrected where it shouldn't have. I fixed it. it shoukd have been rw instead of re.
axlebot said:
Sorry the evo auto corrected where it shouldn't have. I fixed it. it shoukd have been rw instead of re.
Click to expand...
Click to collapse
Not a problem - caught the issue when I read your post. But I saw an issue where even that command was not giving me R/W access. Strangely, pulling the battery and rebooting seemed to help. Odd.
Thanks for the assist. I had kept thinking with full unlock you would not have to run that command each time.
Hello fellas,
I've ran out of ideas at what to do. My old GT-I5510 got screen cracked and in order to recover my files, memo app and calendar app data in particular (both stock), I tried to root it with KERUK to gain access to /data where it should be stored, but it's no use when I don't see what I'm doing in recovery mode. ADB does communicate but only in recovery mode, otherwise I believe USB debugging is needed, which I did not enable before it got screen cracked. In fact, /data is not accessible at all ("opendir failed, Permission denied"). The backup command from ADB does not work (supposedly without root) either ("adb: unable to connect to backup"). I also tried to copy everything with "adb pull / C:/recovered-files/" which started copying all the files from accessible folders but aborted as soon as it tried to open a restriced path/file. I checked all of the subfolders and none seemed to have write permissions. /sdcard seems to be accessible but inside there are no files shown through the ADB shell although the SD card definitely has stuff on it.
What should I do? Thank you so much in advance!
I'm not quite sure, but am I even posting in the right forum? Seems that noone knows even a tip for this. After all, my "guest thread" (http://forum.xda-developers.com/general/xda-assist/samsung-gt-i5510-display-cracked-trying-t3132014) was answered right away. Sorry for double post, but I thought this possible misunderstanding needed a push for people to see.
I think the forum is correct, there are only a few people using a Galaxy 551 left now, and I presume all of them have rooted their device at an earlier stage.
If you canNOT "su" in an "adb shell" in normal operation mode, you could still attempt to find the mount points, and run the necessary mount commands when rebooted into (CWM; or TWRP - I'm pretty sure stock recovery won't do anything you'll need) recovery. Check that you're having superuser status by running "id" (which should return UID zero).
You probably will be more successful if you could copy everything to the SDcard (which has to be mounted by hand), either using "tar" or "rsync" (that one can be found in several places).
I tried to copy the system image file (system.rooted.H81510c-EU.img = 4 GB) to a different location as the /data/media/0/ of
Code:
dd if=/data/media/0/system.rooted.H81510c-EU.img bs=8192 seek=55296 count=529920 of=/dev/block/mmcblk0
is obviously NOT available to me because I use device encryption. (/data unavailable) So I tried to find a way to replace /data/media/0/ with anything that maps to my external_SD Card (/mnt/media_rw/external_SD) as this is not encrypted (can be encrypted easily). The Send_Command.exe \.\\COM5 shell is NOT very helpful in even understanding if the SD_Card is mounted. Anyone knows anything about it?
Second I tried to, as I am rooted, to copy the system image file to any location the Send_Command.exe \.\\COM5 shell would be able to read from although the device is encrypted. This would have been a 2 step process of rooting, unrooting and encryption and re rooting but I wanted to try. Somehow despite having root rights I could NOT copy anything directly to /. Or any other folder available in the Send_Command.exe \.\\COM5 shell. Any files or folders I created where successfully created when NOT created in / but I could not copy the large image file. It always told me not enough space, which is not the case. Folders I created seemed to be vanished after a reboot.
Anyone can shine a light on this? Can’t I copy because the device is already encrypted, or can’t I copy because of SLELinux Security?
Third I tried to copy the image file via Push_File.exe \\.\COM5 system.rooted.H81510c-EU.img /tmp/system.rooted.H81510c-EU.img which seemed to work. Just to find out it started fine and then quickly failed. Maybe not enough space in /tmp or wrong Push_File.exe parameter?
Anyone can help me out here?
Best regards
since you are going to need to re-encrypt it after you root it anyway why don't you just decrypt it first and save yourself the hassle?
run id in the command shell. it'll show you have recovery selinux context, which is very limited. you cant do much which is why we are having to copy the whole system partition off the device and edit it remotely. I dont think you'll have much luck mounting the sdcard, but thats not to say you shouldnt try and post back if you succeed.
@diedemus
Because LG encryption is buggy and will not encrypt when rooted. (10a + 10b tested)
I run the id command successfully. So I do have the limited shell = recovery selinux and I am root. Any idea how to mount the sdcard when in recovery selinux context?
Is there a technical documentation of that shell? I couldn't find any. Help is greatly appreciated.
Sent from outer space using telepathy
With samsung there is a way to encrypt a rooted device.
Download terminal and launch
$su
Click to expand...
Click to collapse
the $ will become a #
Now type
pkill -KILL daemonsu
Click to expand...
Click to collapse
the# will become a $
Just after that (don't wait) go to encryption and encrypt the phone (it can take long time).
remixtech said:
With samsung there is a way to encrypt a rooted device.
Download terminal and launch
the $ will become a #
Now type
the# will become a $
Just after that (don't wait) go to encryption and encrypt the phone (it can take long time).
Click to expand...
Click to collapse
Interesting. I should try that one day. Only have one device left though, no more playing around [emoji2]
This development device was encrypted. LG devices can be unencrypted. Did NOT work. Device rebooted and never started decryption. Same as with encryption.
I did remove root, supersu, busybox everything AND tricked the LG RCT into thinking that the device was never rooted.
Decryption worked fine after that. I guess encryption will too. Why LG links device encryption and rooting is beyond me.
I should write a full guide one of this days on how to archive that.
This post was written on my rooted LG G4 with Xposed AND device encryption. So it is possible [emoji3]
Gesendet von meinem LG-H815 mit Tapatalk
fpsq said:
Interesting. I should try that one day. Only have one device left though, no more playing around [emoji2]
This development device was encrypted. LG devices can be unencrypted. Did NOT work. Device rebooted and never started decryption. Same as with encryption.
I did remove root, supersu, busybox everything AND tricked the LG RCT into thinking that the device was never rooted.
Decryption worked fine after that. I guess encryption will too. Why LG links device encryption and rooting is beyond me.
I should write a full guide one of this days on how to archive that.
This post was written on my rooted LG G4 with Xposed AND device encryption. So it is possible [emoji3]
Gesendet von meinem LG-H815 mit Tapatalk
Click to expand...
Click to collapse
Please do that. I come from Samsung and i would like to encrypt my device with XPosed !
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
Many guides recommend to backup the EFS partition before installing any ROMs "just in case".
Unfortunately, I cannot find any up-to-date manual on how to do so the proper way in case of the Fold 3.
Guides I do find either suggest to copy some images from a specific /dev/block with dd, which seems to be e outdated as non-existant on the Fold 3 or are incomplete by recommending to only copy the content of the folder /efs with a root explorer or mention EFS Professional which at least for me fails with some obscure array/dimension/whatnow error message just when attemping to even only get the partitions.
In the Dr. Ketan - thread, the developer suggested to use TWRP but here, is also unclear whether being suitable now or not, also in terms of half the stuff being encrypted nowadays. Uargh.
So how do all of you back this up if it is common sense that it is oh so important?
If you are rooted, the dd method can be done quite simple either on a terminal emulator or with adb shell.
If using terminal:
su
then
dd if=/dev/block/by-name/efs of=/sdcard/efs_backup.img
If using adb shell:
adb shell
then
su
then
dd if=/dev/block/by-name/efs of=/sdcard/efs_backup.img
Or you can just back it up with TWRP, it should give you the option to do it.
Thanks a lot. I used dd in Termux in the root context and the resulting file size is 20 MB. Hope it is what I need as that EFS backup thing somehow has something of "hopefully, one never needs it".
By the way, the attempt to use TWRP for that fails as it only recognizes the internal storage which is shown as 0MB, probably due to the encryption.