Database Users

[Solved] Is there an advantage with S-Off against mounting to rw and chmod 777?

Hi everybody!
Yesterday i came across S-OFF. From what i was able to find, S-OFF has two main advantages: 1.) Grant full NAND access, so you can write to /boot, /recovery and /system while in full booted mode. And secondly; allows unsigned fastboot flashing.
Now my question regards the first point; write access to all directories during full boot. Yesterday i was in need of write access to /system directory (actually just for creating a symlink). What i did - when got the "write-only permission" prompt at first try - i remounted system partition via terminal and then chmodded system directory:
Code:
/$ su
su
/# grep " /system " /proc/mounts | awk '{system("mount -o rw,remount -t "$3" "$1" "$2)}'
/# chmod -R 777 system
Afterwards i had write permissions to the system directory while i've been in full boot mode.
So my question is: If i'm not interested in unsigned fastboot flashing, nor in locking the bootloader etc, but only in having full access to all system directories - is my approach posted above giving me the same permissions, as S-OFF would do, or would S-OFF gimme any advantages?
My Phone:
*Nexus One on GRK39F Stock ROM,
*rooted (with "Superboot for Nexus One" by Madaco),
*su version 3 (by ChainsDD http://forum.xda-developers.com/showthread.php?t=682828)
Many thanks in advanced!
Cheers, Stephan
Update: @Mod/Admin: Sorry for posting to the wrong section. When i was looking at the section titles before posting this, i read Q&A as FAQ; donno why. I just realized the sticked thread at top of this section, thus recognized i posted to the wrong section. If you'd be so kind to move the thread to the approciated section, rather than closing it, i'd be thankful and promise to take more care about sticking to the board rules in the future. Thanks and kind regards!

I think you are mixing up a few things:
1) Nexus One's come with a partially unlockable bootloader. When you execute the "fastboot oem unlock" command, you are able to flash the /system, /boot, and /recovery partitions with unsigned images via the fastboot command. (So, essentially, you can give yourself root access once you are unlocked, and can write to the /system partition while booted normally.)
2) With S-OFF, you are able to flash ALL of the partitions of the N1 with unsigned images via fastboot, including radio, hboot, sp1custom and splash.
3) If you are rooted, you have write access to the system partition (the same as the above two).
So, to answer your question, having an unlocked bootloader, or S-OFF, or root: they all give you the same ability when it comes to the /system partition.
P.S. If you rooted with "Superboot for Nexus One" by Madaco, then you already unlocked your bootloader...

Hi Efrant!
Thanks for your answer, eventhough i'm even more confused now. ^^ You say
efrant said:
having an unlocked bootloader, or S-OFF, or root: they all give you the same ability when it comes to the /system partition.
Click to expand...
Click to collapse
But "Root" alone, on Android, does not necessarily gives you permissions to write to system directories. As long as a partition is mounted read only, you will - regardless you have userid 0 - get a "read-only file system" error prompt when trying to write to it. Or how comes
Code:
[U][B]whoami: unknown uid 10063 :[/B][/U]
issuing
[B]$ ls /data/app[/B]
returns
[B]opendir failed, Permission denied[/B]
issuing
[B]$ cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
returns
[B]cp -s -P /system/xbin/busybox /system/bin/busybox: Read-only file system[/B]
Code:
[U][B]whoami: unknown uid 0 :[/B][/U]
issuing
[B]$ su
# ls /data/app[/B]
returns directory listing
[B]namespace.apk
...[/B]
issuing
[B]$ su
# cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
returns
[B]cp -s -P /system/xbin/busybox /system/bin/busybox: Read-only file system[/B]
Code:
[U][B]whoami: unknown uid 0 :[/B][/U]
but issuing
[B]$ su
# mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
# chmod -R 777
# cp -s -P /system/xbin/busybox /system/bin/busybox[/B]
will finally create the symlink
For me, that doesn't look like i'm having same access to system directories whether for reading, nor for writing and that - even when logging in as userid 0 ?!
PS: And yes, you're right; i unlocked the bootloader (the very first day i bought my Nexus).

Bexton said:
Hi Efrant!
Thanks for your answer, eventhough i'm even more confused now.
But "Root" alone, on Android, does not necessarily gives you permissions to write to system directories. As long as a partition is mounted read only, you will - regardless you have userid 0 - get a "read-only file system" error prompt when trying to write to it.
Click to expand...
Click to collapse
Yes, but once you have root access, you can mount the system partition as r/w, without any other permissions/etc. All I was saying was that when you have root, you can write to the system. Of course I didn't spell it out step by step, i.e., by mounting the system as r/w, changing directory to the system, etc.
P.S. If you use a root file explorer (like Root Explorer for example, it make the process much easier).

Okay, i got it! Thanks!
So the bottom line: @secuflag has no effect on read and write permissions for the file system.
PS: Sometimes i'm using "root apps" (such as sysroot file explorer eg). But some things can not be done by apps. Plus, i think for a lot of tasks - if you're familar with linux - the command line is also much more comfortable and faster. But thanks for your tip (and help) anyway.

Bexton said:
So the bottom line: @secuflag has no effect on read and write permissions for the file system.
Click to expand...
Click to collapse
Correct (on Nexus 1s)
Sent from my Nexus One using Tapatalk

Here is a new safe way to get S_OFF for your N1. For me the only real advantage was getting rid of the ugly padlock image during boot, and customizing the initial splash image.
http://forum.xda-developers.com/showthread.php?t=1270589

garrettc67 said:
Here is a new safe way to get S_OFF for your N1. For me the only real advantage was getting rid of the ugly padlock image during boot, and customizing the initial splash image.
http://forum.xda-developers.com/showthread.php?t=1270589
Click to expand...
Click to collapse
Keep in mind that what you are linking to is not "true" S-OFF (i.e., setting secu_flag=0, like what you get when using an XTC clip or something similar). The radio is still S-ON.

efrant said:
Keep in mind that what you are linking to is not "true" S-OFF (i.e., setting secu_flag=0, like what you get when using an XTC clip or something similar). The radio is still S-ON.
Click to expand...
Click to collapse
Yes, very true. But for what I wanted it's OK. I'm very lucky that this method turned up on the same day that my new XTC Clip arrived, since it fried itself when I plugged-in the battery and I was about as depressed as a geek could be

[Q] [Help]

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.

Upgrading to 4.2.2 Issue

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

[SOLVED] Using Terminal Emulator to write to system

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:

[GUIDE] Revert from ART to Dalvik if boot fails

Today I tried to enable ART on my S3 Mini running Maclaw's CM11. After the phone was shut down, the CM loading circle stayed there forever and the phone didn't boot.
To fix this you can boot the phone into recovery (I'm using CWM) and use ADB to revert the runtime back to Dalvik.
There are 3 ways to do this:
Use the following manual instructions
Download the second attachment and run the batch file, while the phone is connected using a USB cable and in recovery mode. For this you need USB drivers installed.
Download the first attachment and flash it in recovery
Manual instructions
Boot to recovery
Open the shell
Code:
adb shell
Now, while in the shell, the data filesystem must be mounted.
Code:
mount /data
Still staying in the shell, use the following command to set Dalvik as the runtime of choice.
Code:
setprop persist.sys.dalvik.vm.lib libdvm.so
Now the /data-filesystem can be unmounted using
Code:
umount /data
Type exit in the shell to exit ADB shell.
Reboot the phone and it should get past the loading circle again
If anything goes wrong, I'm not responsible

Very good idea. Thanks
I am not sure, but maybe it is possible to set property from recovery update script?
Such script, downloaded onto phone and accessible from recovery would be better, than PC with USB drivers and a cable

piskor said:
Very good idea. Thanks
I am not sure, but maybe it is possible to set property from recovery update script?
Such script, downloaded onto phone and accessible from recovery would be better, than PC with USB drivers and a cable
Click to expand...
Click to collapse
Thank you for the idea, implemented it now and added to the OP.

dextrey said:
Thank you for the idea, implemented it now and added to the OP.
Click to expand...
Click to collapse
Excellent, thanks

Updated to mount the /data filesystem directly using the fstab entry. Also changed the recovery-flashable .ZIP to use a temporary BusyBox for all commands, because I'm not completely sure about the filesystem differences between different ROMs and recoveries (the locations of binaries such as mount and umount)

Thanks!!!
Very useful!!

Thanks, this worked. I was on CM11 nightlies and read an article about ART and switched it from Dalvik, phone app crashed and wouldnt let me boot in. Although I'm using HTC One, this method worked for me.
For TWRP users, boot into recovery and go into Advanced, and then use terminal to command the type the main line to switch to Dalvik, no need to adb shell and mount data.

Fixed my HTC ONE m7 that got brinked when selecting ART.
dextrey said:
Today I tried to enable ART on my S3 Mini running Maclaw's CM11. After the phone was shut down, the CM loading circle stayed there forever and the phone didn't boot.
To fix this you can boot the phone into recovery (I'm using CWM) and use ADB to revert the runtime back to Dalvik.
There are 3 ways to do this:
Use the following manual instructions
Download the second attachment and run the batch file, while the phone is connected using a USB cable and in recovery mode. For this you need USB drivers installed.
Download the first attachment and flash it in recovery
Manual instructions
Boot to recovery
Open the shell
Code:
adb shell
Now, while in the shell, the data filesystem must be mounted.
Code:
mount /data
Still staying in the shell, use the following command to set Dalvik as the runtime of choice.
Code:
setprop persist.sys.dalvik.vm.lib libdvm.so
Now the /data-filesystem can be unmounted using
Code:
umount /data
Type exit in the shell to exit ADB shell.
Reboot the phone and it should get past the loading circle again
If anything goes wrong, I'm not responsible
Click to expand...
Click to collapse
Thank you, thank you, I'm in great debt for this.
Can recommend the method if you are running viperOne 6** on a HTC one m7 (bulletproof kernel).
NB:
My ADB was totally broken, but I wrote all commands in the TWRP terminal window, and it reverted my phone back to dalvic from ART!