I dont understand how everyone is remounting /system.... whenever i try to do it, it fails because /system is read only. The whole point of remounting is to make it rw so its not readonly, this is like a catch22 and idk how people are getting it to work
It's still read only they are just fooling themselves. The only way to modify system is through the img flash
Related
I've been trying to figure out how to fix my phone and through using the adb logcat the only thing left is just getting the core.jar file in the /system/framework to change from read only to rw. Each time I try to change it it says its read only or bad mode. Any ideas?
Metatronx said:
I've been trying to figure out how to fix my phone and through using the adb logcat the only thing left is just getting the core.jar file in the /system/framework to change from read only to rw. Each time I try to change it it says its read only or bad mode. Any ideas?
Click to expand...
Click to collapse
try
Code:
adb remount
What would the syntax be for remounting the core.jar and is it possible to do in terminal? Thank you especially for the quick response\!
From your other thread..
The entire /system partition is always read-only, unless you tell your phone to remount it read-write.
Code:
mount -o remount,rw /dev/block/mtdblock3 /system
But for your problem.. You shouldn't really need to manually tweak files in /system if you flash another ROM. The new ROM will replace that entire partition. Have you wiped? What ROM are you trying to flash?
Kudos for using logcat and trying to jump in yourself though.
I've been trying to figure out how to fix my phone and my knowledge of unix is terrible. I checked the adb logcat on my phone and the only thing left is just getting the core.jar file in the /system/framework to change from read only to rw. Each time I try to change it it says its read only or bad mode. If not is it possible to delete this file and the phone will rebuild a proper version of it. It seems to be the root of what is causing my phone to go into a bootloop whenever I attempt to install a non-JF build. Thank you guys ahead of time.
The entire /system partition is always read-only, unless you tell your phone to remount it read-write.
Code:
mount -o remount,rw /dev/block/mtdblock3 /system
But for your problem.. You shouldn't really need to manually tweak files in /system if you flash another ROM. The new ROM will replace that entire partition. Have you wiped? What ROM are you trying to flash?
Kudos for using logcat and trying to jump in yourself though.
Saiboogu said:
The entire /system partition is always read-only, unless you tell your phone to remount it read-write.
Code:
mount -o remount,rw /dev/block/mtdblock3 /system
But for your problem.. You shouldn't really need to manually tweak files in /system if you flash another ROM. The new ROM will replace that entire partition. Have you wiped? What ROM are you trying to flash?
Kudos for using logcat and trying to jump in yourself though.
Click to expand...
Click to collapse
I've been unable to replace the ROM because I keep getting stuck at the T-Mobile G1 screen in a bootloop constantly running those errors. I've tried cyanogen, dudes, jachero and keep getting stuck in a bootloop. I had an earlier post here http://forum.xda-developers.com/showthread.php?t=536657.
Metatronx said:
I've been unable to replace the ROM because I keep getting stuck at the T-Mobile G1 screen in a bootloop constantly running those errors. I've tried cyanogen, dudes, jachero and keep getting stuck in a bootloop. I had an earlier post here http://forum.xda-developers.com/showthread.php?t=536657.
Click to expand...
Click to collapse
Interesting.. Doesn't sound fun. I remember your other thread - didn't chime in that time because I had no advice. Still not sure what could be causing it. Did you try the last bit of advice in that thread?
Also .. I'm no Android development expert, but just form my PC knowledge.. That logcat from the other thread could be explained by file corruption. And if you get similar issues on different ROMs, it points to your device. Bad blocks on the internal storage, or glitch in the memory controller. May be something that doesn't get utilized until one of the newer (and larger) ROMs gets written to that block.
That's all just a theory.. But if you can't get it running, is there any chance you can exchange it? To rule out the hardware.
Hi
my question is odd, but is completely theoretical
let's say I completely erase all files on the phone
something like "rm -r -f /" from CWM
will I be able to boot into download mode and flash a new firmware?
or are there some directories which we should never mess with on android?
....
or are there some directories which we should never mess with on android?
Click to expand...
Click to collapse
Don't mess with your /efs folder or your bootloader.
efs will affect the IMEI, but it won't affect the phone ability to enter download mode
the bootloader is not a file, so afaik you can't just delete it with rm
omrij said:
efs will affect the IMEI, but it won't affect the phone ability to enter download mode
the bootloader is not a file, so afaik you can't just delete it with rm
Click to expand...
Click to collapse
Noone said that the bootloader is a file here (except you). I said don't mess with it...and what the point having a phone without the ability to use it as a phone??
omrij said:
Hi
my question is odd, but is completely theoretical
let's say I completely erase all files on the phone
something like "rm -r -f /" from CWM
will I be able to boot into download mode and flash a new firmware?
or are there some directories which we should never mess with on android?
Click to expand...
Click to collapse
you have different partitions on your phone.
as long as you just wipe system, data, dbdata or sdcard nothing will happen. your phone will not boot anymore but who cares.
deleting the efs folder would be a bad Idea but that still wont f*** up the device for ever. you'd have to find and destroy the bootloader but I don't think the partition is mounted anywhere so as long as you don't format every entry in /dev/ you should be fine.
But there is no reason to rm -r -f your smartphone. if you want to clean it up go into recovery and format /system / data and /dbdata
Download mode is in the primary bootloader, which is not part of the linux filesystem. So, basically yes, you'd retain download mode
Sent from xda premium app on i9000m.
theduckking said:
But there is no reason to rm -r -f your smartphone. if you want to clean it up go into recovery and format /system / data and /dbdata
Click to expand...
Click to collapse
I agree
I just wanted to know how "idiot proof" is the phone
if it can be recovered even if I delete the wrong file "by mistake"
thank you
its almost impossible to kill the SGS to the point of no return. BUT IN THE WRONG HANDS IT DOES HAPPEN !!!
you shouldnt ever need to mess about with things like that, But like you say if it was a mistake im sure there would be some sort of fix.. But just be careful.
as mentioned previously system / data / dbdata / cache ect..... are safe to format. but anything other than that i wouldnt touch... it wouldnt speed up / free memory on the phone so..........
I just wanted to know how "idiot proof" is the phone
Its very idiot proof problem is far to many idiots blindly flash something without reading a single FAQ .
jje
I installed Ginger Yoshi 1.5 on my Android Dev Phone 1 by following these instructions:
http://forum.xda-developers.com/showthread.php?t=1178665
I found that most things are working, but I cannot install CoPilot GPS (28MB)
Error 498 in Google Play seems to mean the /cache partition is too small. My cache partition is 27MB.
I tried redirecting /cache to larger place with Cache Fixer 1.1
The "Data" option doesn't succeed in expanding the cache.
The "Tmpfs" option successfully makes the cache bigger, but it makes Play force close when I try to install the app.
I Tried using CacheDownload2SD 1.7.1, but it doesn't do anything
I got a message saying my su binary should be updated. I don't know if that is related or not.
I tried updating the SuperUser su binary from 2.3.2-efgh to 3.1.1
su Binary Updater says "Make sure new su works... fail!"
When I try again, su Binary Updater says "Copying su to /system... fail!"
When I try yet again, su Binary Updater again says "Copying su to /system... fail!"
I used Root Checker to verify root access. The phone is properly rooted. I don't know if this issue is related
I've considered downloading an apk and manually installing it. That should work, but then Google Play wouldn't let me know when an update became available. Any ideas on how to solve the problem? Does anyone know why Cache Fixer and CacheDownload2SD dont' work? Can anyone see why the su binary won't update? I've spent all day clearing caches, rebooting, and attempting installs. Why does Google Play need to download to such a tiny partition?
@IMSargon if your /cache partition is too small then you need to use custom MTD.
HTCDreamOn said:
@IMSargon if your /cache partition is too small then you need to use custom MTD.
Click to expand...
Click to collapse
Thanks for that. I certainly have some more reading before I fully understand the topic. When I upgraded to Ginger Yoshi 1.5, I changed from DangerSPL to hboot-1.33.0013d which gives practically the same partition sizes, except /cache is 27MB instead of 30MB, which is why I didn't have this problem before.
So you're saying I can flash to this custom bootloader to increase my cache size (decreasing /system and/or /data accordingly), install the GPS app, then flash back for normal operation? It sounds like a risky proposition. Is there no way to permanently or temporarily redirect the location to which Play downloads APKs? Such solutions appear to exist (Cache Fixer, etc), but they don't seem to work for me (why?).
No, if you change partition sizes you will be wiping those partitions. Maybe a better option is to do it just once but bind mount to sdcard, see the link htcdreamon gave for more info on this
Sent from my Nexus 4 using xda premium
demkantor said:
No, if you change partition sizes you will be wiping those partitions.
Click to expand...
Click to collapse
This is a relief to hear. It sounded like they would just redefine the partition boundaries with the data in place and hope for the best. I was wondering how that worked. After re-reading, the instruction do call for wiping the partitions and re-flashing the ROM.
demkantor said:
Maybe a better option is to do it just once but bind mount to sdcard, see the link htcdreamon gave for more info on this
Click to expand...
Click to collapse
That would work, and it's something I'll seriously consider once I have a chance to read all the documentation. It seems to me, though, that I should be able to unmount and remount elsewhere the /cache partition on a live system from the command line. Any reason I should not attempt that?
If you want to resolve your problem then follow these steps
- Clean your Device Cache
- Erase Market Data
- Scan your Device for Viruses
- Restore Smartphone to Factory Settings
I also have tutorial like article where you will find all the solution steps to fix the error here is the link:
optimum-systems.com/2013/04/error-498-in-android.html
I hope you will resolve your problem
I tried making a folder under /sdcard, removing /cache, and replacing it with a symlink to the folder in /sdcard. That didn't work for a number of reasons. Firstly, mkdir was missing, which was a pain. I just made the directories with File Manager on the phone - I'll fix that later. Then it wouldn't let me change the ownership of the target directory on the sdcard, even though I was root. When I tried downloading my app, Play force closed.
My next idea was to put the folder in /sd-ext, which is my next largest partition. This is an ext4 partition on the sdcard. I created a folder there. Then I deleted /cache/download and created a symlink to my folder in /sd-ext. I didn't have any problems changing permissions this time. For whatever reason, Play did not force close, and successfully installed the app.
I'll write what I did here, but I'll pretend mkdir worked.
Code:
rm /cache/download
mkdir /sd-ext/download
chown system:cache download
ln -s /sd-ext/download /cache/download
chown -h system:cache /cache/download
I'd expect this setup to survive a reboot, so maybe you want to delete the symlink and remake the original folder to set things back to normal. If not, only apps that use /cache/download are effected, so you might as well leave it. Just clean that folder out every so often.
There have been quite a bit of people with issues with Systemless root, there are some apps that are not recognizing root, i had this issue with my Oneplus One on COS 13.1 and now the same thing works with our OnePlus 3 on OxygenOS
I had come across this on another forum, i don't recall where so i don't want to take the credit for this, i just want to provide the fix for people who have this phone and having issues
Download Terminal from app store and type
Code:
su
mount -o remount,rw /system
touch /system/bin/su
mount -o remount,ro /system
reboot
Thank you ! Before I try this , can you tell me what this method is doing ? All I can tell is that it is mounting something as read only instead of read write
I belive it creates a dummy file bc some apps require it to show as a system file
SDMU said:
Thank you ! Before I try this , can you tell me what this method is doing ? All I can tell is that it is mounting something as read only instead of read write
Click to expand...
Click to collapse
Code:
1. su
2. mount -o remount,rw /system
3. touch /system/bin/su
4. mount -o remount,ro /system
5. reboot
1. To get root privileges
2. Remounts /system partition in writable mode
3. Creates an empty file called su to /system/bin/ folder
4. Remounts /system partition to read only mode.
5. reboot
Edit. As stated above, some apps still check root access by looking su file in /system/bin folder
Squabl said:
1. To get root privileges
2. Remounts /system partition in writable mode
3. Creates an empty file called su to /system/bin/ folder
4. Remounts /system partition to read only mode.
5. reboot
Edit. As stated above, some apps still check root access by looking su file in /system/bin folder
Click to expand...
Click to collapse
This defeats the purpose of a system less su, I.e., not modifying the system partition. Step 3 modifies the system partition.
The reason apps are not seeing the su in system less state is because they have been written incorrectly. Chainfire already said these apps should be re written
candiesdoodle said:
This defeats the purpose of a system less su, I.e., not modifying the system partition. Step 3 modifies the system partition.
The reason apps are not seeing the su in system less state is because they have been written incorrectly. Chainfire already said these apps should be re written
Click to expand...
Click to collapse
Yes, it "disables" systemless root and afterwards it is just a root and banking apps and ota updates etc will fail. I don't need systemless root so I have modified my system partition to get some poorly coded apps to function. This method is not recommended if you need systemless root and it's a good thing that you pointed that out!