Not sure if this will help anyone else, but I searched forever trying to figure out how to write into the system folder using Terminal Emulator on the Note 3 to no avail. I found a slew of posts that said to type "mount -o rw,remount /system" to achieve this. When I used this command it didn't return any errors so I assumed it worked, however no files ended up being copied and pasted to the location I wanted. I found numerous other examples that were supposed to enable writing to the system as well, but none of them worked. I finally figured out how to get it to work on my Note 3 by typing "mount" in terminal emulator and noticing that at the very beginning of the string that was returned was "rootfs". So if you are wanting write to your system using Terminal Emulator on the VZW Note 3 here is what ended up working for me:
Code:
mount -o remount,rw rootfs
to return to read only enter:
Code:
mount -o remount,ro rootfs
I wanted to figure this out because a bug in TWRP v2.6.3.0 maimed my efs partition and bricklooped my phone. Even flashing the Stock Developer tar by Beans wouldn't bring it out of the brickloop. I was able to get out of the brickloop by following this thread, but even though my phone booted up and the IMEI # was correct, my /efs folder was missing in action. This caused odd things to happen like my lock screen not functioning and the power button instantly turning the phone off instead of bringing up the power menu. I discovered this was because the phone was placed into something called "factory mode" and that to fix it you needed to edit some files in the efs folder, which were completely missing on my device. Member js0uth graciously sent me his efs folder from his Developer Note 3 and when I copied it to my phone it began to function normally again (big shout out to js0uth!). However, this folder was completely deleted once again after a reboot. So now you can see why I was looking for a way to copy these files using Terminal Emulator. I ended up making a Tasker profile with the Secure Settings plugin that automatically copies the files from my ext SD card to my system folder on boot of the device. In order to mount, copy/paste the files while retaining the correct permissions from the folder that js0uth sent me, and unmount the system I had the set up my Secure Settings command as follows:
Code:
mount -o remount,rw rootfs;cp -Rpf /storage/extSdCard/efs/* /efs/;mount -o remount,ro rootfs
So now I have a livable workaround for my problem until I can discover a way for the phone to rebuild my own /efs folder.
Edit: See radionerd's post for a permanent fix to this issue and be sure to hit thanks under his name if it helps you.
I did the same to my DE. Corrupted EFS about a month ago after a few flashes using TWRP 2.6.3.0. Boot loops for 28 hours of hell until I followed your tracks to the trick that deleted my corrupted EFS folder, and created a new empty folder. I guess this would wipe out IMEI, Mac, and more in models that store phone specific data in EFS. We lucked out I've read that our phones have that info in a few other folder not EFS
Since wiping EFS I have run stock ROM, CM11, and now bean V6. I didn't see the factory mode popup until recently. I noticed that the screen will flash when leaving or entering cell service.
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Thanks for documenting your steps to recovery.
radionerd
radionerd said:
My corrupted EFS was 3MB. I'm curious what's the size of the EFS folder from js0uth?
Click to expand...
Click to collapse
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
radionerd said:
Were you able to enter the factory mode on string? something like this?
Code:
# echo -n ON > /efs/FactoryApp/factorymode
this is from an S3
Click to expand...
Click to collapse
Setting the Factorymode folder to ON is actually what disables that mode. Seems backwards I know, but when it's set to OFF (or if the folder is completely missing as in my case) that warning message will display. If that folder is intact on your phone then you should be able to use a string to disable or enable Factorymode.
It got worse before it got better
bodieism said:
It's 1.04 MB. Sorry for taking so long to respond. I thought I had it set up to send instant emails for replies to this thread, but apparently I didn't.
No worries, I went from an annoyance of no lock screen to bricked for over 6 weeks. This happened after trying to do an EFS backup.
I've learned a lot since back then, My DE is back 100%, EFS is repaired. I think we ran the same script which actually points to the wrong mount in our phones. It brought us out of bootloops, but efs was pointed to block12. Qualcom snapdragon Note-3's use mmblk0p11 to load /efs.
If you still have to load the tasker script, I think I figured out an easy fix to rebuild your original efs folder.
I would backup mounts first, delete /efs folder. Then run the original script, but this time change from 12 to 11.
Code:
adb shell
su
mke2fs /dev/block/mmcblk0p11
mkdir /efs
mount -t ext4 /dev/block/mmcblk0p11 /efs
Bet that would do the trick
Here is my thread
Click to expand...
Click to collapse
^ That did do the trick! :good:
Phone is back to 100% working order :highfive:
Related
hi, developers!
it's so urgent if anyone knows how to do this please instruct me, infinitive thanks here in the first place!
i need to pull the directory of /data out to my PC，i'm rooted and able to use adb for this only,
first i use the command line
---------------------------------
adb pull /data(enter)
---------------------------------
The result is
---------------------------------
0 files pulled ,0 files skipped..
---------------------------------
then i tried the following command line
---------------------------------
adb shell(enter)
su(enter)
cd data(enter)
cd data(enter)
ll(enter)
---------------------------------
ok，it's not empty! everything I need is here,and ACCESSIBLE...for sure!
then i exited the adb shell mode and pulled again, but pulled nothing...
alright i went back to adb shell mode with su and tried
---------------------------------
chmod 777 /data(enter *no sign to show if this worked)
---------------------------------
then do the same pulling thing but again, didn't make any sense.
i also tried "cp" the files in /data i need, but only to find they're copied to local storage rather than my PC.
NOW COMES THE QUESTION:
is there any way i can directly gain privilege to pull files from /data,
or is there another way to backup /data to PC?
THE SITUATION IS
i've got a boot up problem, just can't pass through the bootanimation, before I reflash the pad, i'll need to retrieve crucial agenda notes and memo lest they're wiped.
but the recovery backup function failed to back up userdata...(/data)
Just a hunch, but can you (using adb shell and SU) cp /data to /mnt/external_sd, then pull it from there or use a card reader?
stuck
p_025 said:
Just a hunch, but can you (using adb shell and SU) cp /data to /mnt/external_sd, then pull it from there or use a card reader?
Click to expand...
Click to collapse
thank you pal! i've tried such thing as you remind me of but totally, /data is omitted! while i use "cp", for another thing, while i was trying to "cp" another folder to extern sd, it read read-only file system. so it goes all the way back to the PERMISSION thing, or i need to gain privilege to modify the property of /data so that i can pull what i need out of this nightmare...and should modify /external sd also if using "cp".
kept waiting, please help:crying:..any constructive instructions shall be greatly appreciated!!
yours truly cordially!!
can u actually use adb without access to the os??
what rom and BL were u on?
seems strange u need permissions for /data - have u tried mounting it?
from memory data resides at mmcblk0p8 u might be able to dd that 2 ur ext SD or Google to search dev forum
I'm know dev just throwing stuff o.to.tje
mix...
Sent from my GT-I9300 using Tapatalk 2
Hey i have really messed up my nexus 4.Please help.I'll tell you my problem in short:I have flashed recovery.img onto userdata by mistake using quikIMG.So now the phone got reset and the whole phone was seemed wiped.There was nothing on the phone.Thats what i assumed after peeking into galary/music etc but when i connected my phone to the pc it is showning that the phone's 10gb is used.Basically it is showing that the data is still there.Can you tell me any way to bring back the data?
Try factory reset
This may or may not work, no guarantees. This will be difficult, time consuming, and you must do everything exactly as written; so read it first and ask questions before you begin. I am using a Windows PC, most of these commands will be similar on other OS's, those when in the adb shell are identical. This will require adb and a custom recovery (I use TWRP, so I'll be able to offer TWRP specific help quicker), find a method to flash that before you begin, and find where that recovery keeps it backup files. Also this will require you to flash a rooted ROM, of the same android version you had before: if you had stock, I recommend you flash stock and root it; either way, have that ready to go before you start. Lastly, the worst case scenario will require you to have a linux system and possibly some kind of removable media (USB stick, external HDD, etc), you can just boot a linux live disk, and that's what I'll be doing with Ubuntu; again, have this ready first. There will come a point about mid way through, where, depending on the results you may need to wait for me to follow up with you, I will try to do this in a timely manner, but I can't promise anything.
Basically what we are going to do is explore the file system in an adb shell while it is booted to a custom recovery, hopefully from there your /data and /sdcard partitions will still be intact; if they are not we may still be able to recover some of your data. If they are intact you can simply use the recovery to make a backup of them.
And so, with your phone connected to your computer, boot to recovery. Then open a command prompt and enter:
Code:
adb shell
cat /proc/mounts
The output will look like:
/dev/block/mmcblk0p23 /data ext4 rw,relatime,data=ordered 0 0
/dev/block/mmcblk0p23 /sdcard ext4 rw,relatime,data=ordered 0 0
/dev/block/mmcblk0p22 /cache ext4 rw,relatime,data=ordered 0 0
Click to expand...
Click to collapse
First is the block, then the mount point, then the file system type, last is information about how recovery treats it.
If you do not see /dev/block/mmcblk0p23 associated with a mount point then enter:
Code:
mount -o rw /dev/block/mmcblk0p23 /data
mount -o rw /dev/block/mmcblk0p23 /sdcard
If you get an error on both of these then skip to the breakt.
Now check both these directories to ensure it is the data you expect it to be, enter:
Code:
cd /data
ls
cd /sdcard
ls
Maybe go down a few levels to confirm your data is really there. If the output doesn't look right, then skip to the break.
Otherwise, enter:
Code:
exit
Use the phone screen to navigate to the backups menu and backup data.
When the backup is complete use adb pull to copy the backup onto your computer, this may take a very long time.
Code:
adb pull /sdcard/TWRP TWRP
Now flash your ROM, including a data wipe, and boot it, once it is running fully, reboot into recovery and push the backup to the phone.
Code:
adb push TWRP /sdcard/TWRP
Use the phone screen to restore the data.
--------------------THE BREAK, cause XDA automagically made these two posts one, ****ers--------------------
Hopefully you got this sorted out with the first part, this part may not work at all, and it will be a lot more tedious if it does. So, at this point something happened which indicates /mmcblk0p23 really did lose the data, so we'll just copy the whole thing and explore that copy in linux to extract what data you can.
With the phone in recovery, and a command prompt in an adb shell:
Code:
dd if=/dev/block/mmcblk0p23 of=/tmp/userdata.ext4
This may take a REALLY long time. When it is done, enter:
Code:
exit
adb pull /tmp/userdata.ext4
This will take just as long or longer. Transfer userdata.ext4 to your removable media device. And boot to your linux setup. Open a terminal window in the directory with userdata.ext4 enter:
Code:
sudo mkdir userdata
sudo mount -o loop userdata.ext4 userdata
cd userdata
ls
Now if any of your data still exist in a form I'd be able to help you recover, it will be in this directory, userdata. If you see something that you recognize, or that you know you need, copy it and save it to the removable media. After that you can reboot your system.
Go ahead and flash your new ROM now, let it fully book, and then copy back whatever you managed to save.
I kinda lost steam there toward the end, sorry, it's 0316 here. If anything is unclear ask away. Good luck.
I tried today to upgrade from 4.1.2 to 4.2.2 but it failed about 30% of the way through the upgrade and ended with the Droid on his back with a red x.
Its rooted but got stock recovery.
I did the same upgrade for my Nexus 4 to 4.2.2 from 4.2.1 and that upgraded fine.
What's causing the upgrade to fail?
Any help would be much appreciated.
Thanks
Jon
Sent from my Nexus 7 using XDA Premium HD app
look for the error message in /cache/recovery/recovery.log
If you comb thru the bigger threads on the 4.2.2 update....every imaginable problem and solutions are in there.
Sent from my cell phone telephone....
This is part of the log that shows the failure.
Any help would be much appreciated.
Thanks
Verifying current system...
failed to stat "/system/xbin/bttest": No such file or directory
file "/system/xbin/bttest" doesn't have any of expected sha1 sums; checking cache
failed to stat "/cache/saved.file": No such file or directory
failed to load cache file
script aborted: assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
assert failed: apply_patch_check("/system/xbin/bttest", "07168ec97de36a7cca8b6867ad66937c6c6c1f4d", "2bb363a3f434d165d1167d915c2ba44967e22071")
E:Error in /cache/da55f917feee.signed-nakasi-JDQ39-from-JZO54K.da55f917.zip
Sent from my Nexus 7 using XDA Premium HD app
OK jonchill I will try to help out.
But only because you inadvertently disclosed a new OTA download (JZO54K->JDQ39) for nakasi.
Here's the deal:
The OTA process performs checksums on hundreds of individual files (and even partitions e.g. boot partition) before it begins any work. 100% of checksums must pass before anything gets changed by the OTA.
It's a safety feature meant to protect people from applying the wrong files to their tablets/phones. More importantly, the reason that it is done is because the OTA does not contain "replacement" files - it only has small binary "patch" files which can be used only in conjunction with the original file to create the intended replacement file. This is how OTAs can be so much smaller than a full ROM - the files already present are "patched" to create their replacements.
But the bottom line is that if *you* removed or altered any single file which is a target of the OTA patching process, these pre-installation checks will fail. (Even worse, it stops immediately - it is possible that you have more than one file involved in this. Because of this stop-on-first-fail behavior, you don't know yet whether or not there are more to come.)
When I say *you* I mean you personally plus any root-using apps which you installed and ran on your tablet. Could have been an app.
OK, now for the good news. I downloaded the OTA - thanks for providing the file name - and looked at the installer script; that installer script for JZO54K-> JDQ39 is shown here on pastebin. The file which your OTA is complaining about is "bttest" - and as it turns out, this check occurs on line 1040 - it is the third from last file checked. The only thing which comes after that is a check of
/system/xbin/dexdump
and
the boot partition ( EMMC:/dev/block/platform/sdhci-tegra.3/by-name/LNX )
Now I don't have any idea what might have caused "bttest" to disappear from your ROM. On the off-chance that "dexdump" got deleted too, attached is a zip of those two files from the JZO54K distro.
This is not a flashable zip - it's just the two files. It's your responsibility to get them into /system/xbin/
Note their ownership info:
Code:
-rwxr-xr-x 1 root 2000 5448 Oct 2 14:49 /system/xbin/bttest
-rwxr-xr-x 1 root 2000 59828 Oct 2 14:49 /system/xbin/dexdump
If you restore them to /system/xbin/ make sure you
Code:
chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
chmod 755 /system/xbin/bttest /system/xbin/dexdump
I verified their SHA1 checksums (note these are the 2nd string of digits in the failing assert_check).
2bb363a3f434d165d1167d915c2ba44967e22071 bttest
e5e4d35038ed3e32a15194275806d90e64e003c6 dexdump
good luck.
I've downloaded the files and tried transferring them across to XBIN but it fails saying the folder isn't writable, I've tried changing the permissions on the folder but it errors saying can't set permissions.
What am I doing wrong?
Thanks
The /system partition is typically mounted "ro" - Read Only.
Root-aware file browsers typically have a toggle in their (root-related) menu to remount /system in rw mode, but you can easily do it yourself from the command line. (using a terminal emulator or adb). You just need to be root to do this. (Or you can just do everything in the custom recovery, in which case the /system mount point will be in "rw" mode by default)
C:\foo> adb shell
$ su
# mount -o remount,rw /system
(copy files into place, do chmods , etc)
# mount -o remount,ro /system
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
jonchill said:
Just tried a you suggested and it doesn't seem to want to put the system into RW. I've also tried changing the permissions through the file manager I've got installed and get the same result.
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]:/ $ su
su
[email protected]:/ # mount -o remount,rw /system
mount -o remount,rw /system
mount: Read-only file system
255|[email protected]:/ #
Thanks
Click to expand...
Click to collapse
Well, that's odd. I'm not really sure why that is happening. You could fool around with the mount command a little bit or just avoid all this nonsense and do what you need via adb in the custom recovery.
If your bootloader is unlocked, but you don't want to *flash* a custom recovery (I see you said you have stock recovery), you can nevertheless temporarily *boot* one, and just that temporarily booted custom recovery as in:
- put device in bootloader mode
C:\fubar> fastboot boot name-of-custom-recovery-image.img
(wait until it is booted)
C:\fubar> adb shell
# mount /system
# cp /sdcard/wherever/bttest /system/xbin/bttest
# cp /sdcard/wherever/dexdump /system/xbin/bttest
# chown 0.2000 /system/xbin/bttest /system/xbin/dexdump
# chmod 755 /system/xbin/bttest /system/xbin/dexdump
# sync
# umount /system
reboot
I don't know how you originally rooted, but generally the adb connection from either custom recovery (TWRP/CWM) needs an additional USB driver (yes, even though you "already have ADB working with the normal OS"). I suppose most lazy folks use either a toolkit or the XDA Universal Naked driver for this. (No support will be given by me on driver installs - I need to draw the line someplace.)
good luck
Tried booting to a temp custom recovery (TWRP) and followed your instructions but still getting the Read-Only file system. At this stage would it be better to take a backup and re-flash a full image?
C:\NRT\data>adb shell
~ # ←[6n
~ # ←[6nmount /system
mount /system
~ # ←[6ncp /sdcard/bttest /system/xbin/bttest
cp /sdcard/bttest /system/xbin/bttest
cp: can't create '/system/xbin/bttest': I/O error
~ # ←[6ncp /sdcard/dexdump /system/xbin/dexdump
cp /sdcard/dexdump /system/xbin/dexdump
cp: can't create '/system/xbin/dexdump': Read-only file system
Thanks
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
bftb0 said:
Well that is bizarre.
Some boot kernel/ramdisk configurations use a "errors=remount-ro" mount option with ext4 filesystem that automatically prevents a "rw" mount if corruption was detected in the ext4 filesystem meta-data.
Although when the mount of /system succeeds in 4.2.2 stock I don't see that - this is what you get:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
I also don't see that option in use with TWRP 2.4.1.0 either:
Code:
adb shell cat /proc/mounts | grep system
/dev/block/mmcblk0p3 /system ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
It's just a hypothesis - but perhaps somehow your /system partition got damaged?
I am reluctant to continue giving advice since your device is behaving non-nominally. (I never used JZO54K, so I can't say for sure.)
It is possible that doing a dirty overflash of factory 4.2.2 (of only the boot partition & system partition) via fastboot would succeed, but I would feel a lot more comfortable about doing that in the sequence JOP40C->JOP40D->JDQ39 where you are converting a 4.2.x ROM to a later version. In your case though, coming from a 4.1.x ROM (JZO54K), that seems like there could be downstream problems.
The conservative route would be to take as many backups as you feel are appropriate, e.g. Nandroid + TiBu or Carbon, reinstall the full factory 4.2.2 stock (including bootloader!), re-root, and then restore your market apps & data (TiBu or Carbon). Note that because we have no idea what the changes/bug fixes were in the 4.18 bootloader update, you probably want to make sure you install the 4.18 bootloader first (and make sure to reboot to it!) before doing any of the subsequent steps (partition erasures & formatting, in particular).
I wouldn't do anything at all, though until I had succeeded making a full Nandroid backup and making sure I had a copy of it off of the tablet. Do your Nandroid backups succeed?
Click to expand...
Click to collapse
Thanks for all your help, as this is going to be quite a bit more complex than first thought I'm going to leave the above until I come back from holiday.
Thanks again.
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
GedBlake said:
You can always tell when there's a technical guru around... they use wonderful phrases like "...since your device is behaving non-nominally...".
bftb0, your posts, as ever, continue to be hugely informative and a delight to read...
----------
Hi, jonchill... (when you return from your holiday)...
Here's what I would try...
When I'm poking around in /system (usually for something more prosaic, like changing the BOOTANIMATION.ZIP), I use X-Plore File Manager (http://play.google.com/store/apps/details?id=com.lonelycatgames.Xplore&hl=en).
It's a ROOT capable DUAL pane file manager... so you should be able to copy the files directly into /SYSTEM/XBIN (setting one pane as your SOURCE, the other as your DESTINATION TARGET).
Once copied there, LONG PRESS on the respective files just copied, select PERMISSIONs from the context menu that appears, and set accordingly.
But first, you will have to go into CONFIGURATION>ROOT ACCESS and set X-Plore File Manager to SUPERUSER+MOUNT WRITABLE...
I have both these files (bttest and dexdump) in my xbin folder... and permissions for both are 755.
See my screenshots appended to this post.
Hope this helps...
Rgrds,
Ged.
-----------
PS. where did you get the OTA updater ZIP nakasi-JDQ39-from-JZO54K.da55f917.zip from? I've Googled around for it, but can't find it anywhere. Would be nice to have it in my collection.
Click to expand...
Click to collapse
Ged
The OTA was what I received automatically.
I've already got XPlore and have tried what you suggested but get Can't write to file /system/xbin/bttest can't move temp file to /system/xbin/bttest.
Thanks
I can't figure out how to delete some of the system apks off my rooted Nook Simpletouch. Running 1.2.1, and Nootered it. Tried to ADB uninistall Phone.apk, but it just reports failure. I could use some help.
/system is usually read-only.
To make changes in its content you need to remount it read/write:
Code:
stop
mount -o rw,remount /dev/block/mmcblk0p5 /system
The stop is to be on the safe side, it stops the android subsystem.
After you are done making changes it's best to:
Code:
reboot
Renate NST said:
/system is usually read-only.
To make changes in its content you need to remount it read/write:
Code:
stop
mount -o rw,remount /dev/block/mmcblk0p5 /system
The stop is to be on the safe side, it stops the android subsystem.
After you are done making changes it's best to:
Code:
reboot
Click to expand...
Click to collapse
Just rename them. add ",bak:" to the end or similar. This will disable them, and if you notice instabilities because of getting rid of them you can just remove the appended extension. If everything runs well, you can then delete them with no worries.
I've renamed some of the recommended ones and have an error that comes up. "A problem has occurred, contact support". I need to figure out what is causing that to happen. its annoying but doesn't seem to be an actual problem.
What does "mmcblk0p5" represent?
mmcblk = multimedia card block device, 0 = first device, p5 = fifth partition
Thanks Renate, but It's not working. In order to rename or delete an apk off my Nook simpletouch, would someone please give me step instructions? I feel I'm missing something.
Code:
stop
mount -o rw,remount /dev/block/mmcblk0p5 /system
cd /system/app
mv BoringApp.apk BoringApp.bak
mv TediousApp.apk TediousApp.bak
reboot
And don't tell me that you have no boring or tedious apps!
The advice here is correct, better to rename sysapp extensions (.bak or .ap_) than delete as some might be needed by future apps/sys hacks/kernels. For those who can't adb by cable or keep it up wifi-wise, this is the easiest way even easier than root explorer:
https://play.google.com/store/apps/details?id=com.ghisler.android.TotalCommander
for sys or user app removal if you have to and can't use adb or even total commander, but then you shouldn't if not knowing sys file structures (I use Pro version, for removing many apps i just tested in a batch, sorted reminder):
https://play.google.com/store/apps/details?id=com.jumobile.manager.systemapp
I renamed talk telephone music audio etc apks on nst but Gallery is the only one I removed on all android devices & nst as it's just nasty which has never been missed by later hacks and quickpic is much better anyway:
https://play.google.com/store/apps/details?id=com.alensw.PicFolder
I created another directory under /system called archive. I move apps I don't what to use and fonts I change into /system/archive then I can just move them back if I have issues.
This still isn't working. My commands keep getting rejected. It isnt allowing stop to work. Also, I tried "adb cd /system/apps" and when that didn't work, I tried
"adb shell"
"#cd /system/apps"
No dice.
EDIT: Got it. needed to call it shell instead of adb. I also accidentally wrote "apps" instead of "app".
My internal SD partition won't let me add or delete any contents on it. Anyone have a solution?
Could you please type "mount" in the terminal and copy it here?
It should be RW, you can try typing in the terminal: mount -o remount,rw /sdcard
Never mind. Got it working by rebooting to recovery, going through ADB, and chmod 777.
blackknightavalon said:
Never mind. Got it working by rebooting to recovery, going through ADB, and chmod 777.
Click to expand...
Click to collapse
Yes, I saw last nigh I was able to see your mount dump. You moved your /data and /sdcard partitions to f2fs. I have been trying to reproduce your issue and I have found the origin of it. It seems that you performed the backup of your internal sdcard using adb when switching to f2fs. In such case you indeed need chmod -R 777 /sdcard
I will update the guide accordingly.
Thanks for bringing this issue up.
Oki said:
Yes, I saw you had moved your /data and /sdcard partitions to f2fs. I have been trying to reproduce your issue and I have found the origin of it. It seems that you performed the backup of your internal sdcard using adb. In such case you indeed need chmod -R 777 /sdcard
I will update the guide accordingly.
Thanks for bringing this issue up.
Click to expand...
Click to collapse
It's not that I'm afraid of bricking a phone, it's that I want to keep it usable. That's probably why I won't ever buy another HTC phone until they get rid of CID and MID. And I was one of the guys who cracked the location of the ringtones/notifications on the original Galaxy Gear when it went to Tizen.
Anyway, I let it sit for 12 hours and, sure enough, the chmod fix stuck.
blackknightavalon said:
It's not that I'm afraid of bricking a phone, it's that I want to keep it usable. That's probably why I won't ever buy another HTC phone until they get rid of CID and MID. And I was one of the guys who cracked the location of the ringtones/notifications on the original Galaxy Gear when it went to Tizen.
Anyway, I let it sit for 12 hours and, sure enough, the chmod fix stuck.
Click to expand...
Click to collapse
Your sdcard dump was very useful. At least I was able to see it before you deleted it. It led me to the origin of this issue. We are lucky with the 2017U, it doesn't have the DFU mode of the 2017G. Ours at least is unbrickable due to the EDL mode. When doing testing or trying new things, a safe backup is all you need.