Database Users

[GUIDE]Moving Dalvik-Cache to /Cache -Viewpad 7 Tested

Moving Dalvik-Cache to /cache
Notes:
If you want to move the Dalvik-Cache to /cache you will needed to the following:
1. A Viewpad7 or another branded device (such as: Cherry Mobile Superion, Commtiva Linx N700, Olivepad VT-100, Spice MI700, and Camangi FM600..........)
2. Already got the root permission (For running a set of command)
3. ADB or Terminal Emulator (For running the command)
4. Root Explorer(Optional - if you have a lot of patience for typing)
Steps
1. Build a file call "install-recovery.sh" into the /etc (Path: /etc/install-recovery.sh) With 711 Permission. (Or you can build it in your computer and put it in the sdcard then copy it using Root Explorer.
Code:
#!/system/bin/sh
chmod 771 /cache
2. Move your dalvik-cache and Create Symbolic Link
(You may experience some program FC (Force Close), but never mind)
Code:
mv /data/dalvik-cache /cache/dalvik-cache
ln -s /cache/dalvik-cache /data/dalvik-cache
You've done the action!
If you got a LOT of FC after move the dalvik-cache.
Please go to /(Root) to check the permission of the /cache it may be become 770.
Remarks:
I think it is able to do the same things to a SD Partition or A2SD.
However I have try it. (Because I still haven't install the Custom Recovery.)
If you have any problems. Please leave a message here.
If you want to forward this message. Please provide the source URL in your message.
DISCLAIMER: I cannot be held liable for anything you do to your Viewpad 7 (or equivalent device).
[DISCLAIMER Copy from lakehousetech thanks for your DISCLAIMER.]

Will this still works, after reboot ?

Yes It will be. The install-recovery.sh scripts will be automatically run everytime you boot up the viewpad 7

i found a more efficient method, moving dalvik chache to sd card partitions... using rom manager and link2sd..

wazzzuuuup2 said:
i found a more efficient method, moving dalvik chache to sd card partitions... using rom manager and link2sd..
Click to expand...
Click to collapse
Hah same here And it works great

Could either of you guys who are using ROM Manager/Link2SD provide instructions for how you set that up? Thanks!
Edit, a few days later. Disregard, figured it out on my own. For anyone else interested...
If you're one a Windows based machine, download this, and use it to create an ext2 partition on your SD card. Personally, I copied the contents of the SD over to my computer before I did so, then copied them back after I was done. With link2sd, you can just adjust all the "user" apps to link to the SD, and set it up so it does likewise on install of new apps. Very easy.

[PSA] lollipop sdcard/TWRP directory permissions problem

I upgraded to motorola's 5.02 lollipop last week. Beautiful - no problems worth mentioning.
Then I wanted to try xposed, so I went into TWRP and made a backup. No problems with xposed. It is working fine.
But, I noticed a disk space inconsistency and a problem with the /sdcard/TWRP directory. Here are the symptoms:
Under settings->storage, it did not show my TWRP backups under "misc", but it counted the space as used in the numeric free space.
I tried to look at /sdcard/TWRP/ in es file explorer, but TWRP showed up as a file and not a directory.
At the command line, I got permission denied when I tried to cd into or ls the /sdcard/TWRP directory.
I could not see the /TWRP directory using my PC via USB/MTP while in android.
I could not delete /sdcard/TWRP within es file explorer or at the command line.
The TWRP directory was available and seemed fine at /data/media/0/TWRP.
Within TWRP recovery (v2.8.5.0), I had no problem viewing or deleting the TWRP directory, but when I made a new backup, the problem came back.
I googled and found a number of people with the same problem. (ie http://forum.xda-developers.com/google-nexus-5/general/sdcard-problems-upgrading-android-t2938749)
This fixes half of the problem. After running this, the TWRP ?file? was a directory again and the space was seen in storage under "misc":
Code:
su
restorecon -FR /data/media/0
But, I still did not access to read TWRP as either root in the terminal or from es file explorer. I noticed the owners were not the same as other directories. This fixed that problem:
Code:
su
chown -R media_rw:media_rw /data/media/0/TWRP
Now, I seem to finally have control over the /sdcard/TWRP directory. Whew!
I did not try a restore, and read where others were having trouble restoring lollipop (bootloops or /data missing) with older versions of TWRP. I would be interested to hear if anyone had successfully restored lollipop /data/ using TWRP.
edit: I was forced to restore system and data.. It worked....

Ctrl-Freak said:
I did not try a restore, and read where others were having trouble restoring lollipop (bootloops or /data missing) with older versions of TWRP. I would be interested to hear if anyone had successfully restored lollipop /data/ using TWRP.
Click to expand...
Click to collapse
About 2 weeks ago I had restored the Motorola 5.0.2 backup posted here on XDA [Link Removed by Mods due to Moto Policies]. I had the SELinux storage access problem. Then I restored the CM12 nandroid i had then.
No problem occurred. All of my data in /data is still intact.

Ctrl-Freak said:
I upgraded to motorola's 5.02 lollipop last week. Beautiful - no problems worth mentioning.
Then I wanted to try xposed, so I went into TWRP and made a backup. No problems with xposed. It is working fine.
But, I noticed a disk space inconsistency and a problem with the /sdcard/TWRP directory. Here are the symptoms:
Under settings->storage, it did not show my TWRP backups under "misc", but it counted the space as used in the numeric free space.
I tried to look at /sdcard/TWRP/ in es file explorer, but TWRP showed up as a file and not a directory.
At the command line, I got permission denied when I tried to cd into or ls the /sdcard/TWRP directory.
I could not see the /TWRP directory using my PC via USB/MTP while in android.
I could not delete /sdcard/TWRP within es file explorer or at the command line.
The TWRP directory was available and seemed fine at /data/media/0/TWRP.
Within TWRP recovery (v2.8.5.0), I had no problem viewing or deleting the TWRP directory, but when I made a new backup, the problem came back.
I googled and found a number of people with the same problem. (ie http://forum.xda-developers.com/google-nexus-5/general/sdcard-problems-upgrading-android-t2938749)
This fixes half of the problem. After running this, the TWRP ?file? was a directory again and the space was seen in storage under "misc":
Code:
su
restorecon -FR /data/media/0
But, I still did not access to read TWRP as either root in the terminal or from es file explorer. I noticed the owners were not the same as other directories. This fixed that problem:
Code:
su
chown -R media_rw:media_rw /data/media/0/TWRP
Now, I seem to finally have control over the /sdcard/TWRP directory. Whew!
I did not try a restore, and read where others were having trouble restoring lollipop (bootloops or /data missing) with older versions of TWRP. I would be interested to hear if anyone had successfully restored lollipop /data/ using TWRP.
edit: I was forced to restore system and data.. It worked....
Click to expand...
Click to collapse
hi, im having the same problem as you. I was on cm12, reverted to 4.4.4 and took the OTA, i then flashed TWRP and did a backup of the stock rom, but I cant see the file on ES Explorer and its taking space like you said. The problem is I didnt understand how you fixed it. Could you explain please? Whats the code you mention on the solution? where do you enter it?
Edit: I managed to flash a backup of the rom i was running prior to KitKat via OTG cable. TWRP recognized the backup when i made a couple of folders: TWRP/BACKUPS/TA000021JN and i flashed. As soon as the phone booted up I was able to see the TWRP folder on ES Explorer again so i think it 's probably fixed?

Cristian314 said:
hi, im having the same problem as you. I was on cm12, reverted to 4.4.4 and took the OTA, i then flashed TWRP and did a backup of the stock rom, but I cant see the file on ES Explorer and its taking space like you said. The problem is I didnt understand how you fixed it. Could you explain please? Whats the code you mention on the solution? where do you enter it?
Click to expand...
Click to collapse
Terminal emulator (app), I just tried it, works [emoji2]
Enviado desde mi XT1058 mediante Tapatalk

Soft-Bricked phone (SM-9005, OS: 4.4.2), problem with /system

So Hello everyone, i got interesting problem...
I bricked my phone
Phone: SM-9005
OS: Android 4.4.2
Firmware: N9005XXUGNG1
Recovery: TWRP 3.0 installed.
Root software installed which may be interesting "Xposed Additions, Lucky Patcher, SuperSu, Greenify"
Step by step.
// maybe helpful - cache / dalvik cache wiped and after reboot i started playing stuff
I used Root Browser (com.jrummy.root.browserfree) to copy 2 directories from my /downloads to /system.
There were /lib & /bin which contained unique libs and one executable so this would not affect system if everything went ok, but i didn't
After i started coping, root explorer asked me that "File already exist, overwrite or make a copy"? i pressed overwrite, in same second all apps in android started to generate "unexpected error", i tried to reboot and got boot into recovery
after i watched /system i found that what i tried to copy actually copied not to /system/lib & /system/app but to /system/system/lib & /system/system/app.
So i think there was some folder or file called system in /system directory which was overwritten. Or any kind of problem with dir / file permissions.
Any ideas of how to fix this / what was in /system/system / where to get bootlog to find after what "kernel panic" takes place or any other help?
Thanks.
// maybe somebody with same model version, same os version can upload zip file of own /system folder without /apps, /priv-apps and build.prop so i can compare whats lost compared to my data?

Fixed myself, root browser set wrong permissions to /system while was coping files... set back to 755 and it works

How do I persist changes to the /oem folder?

I have the Moto G7 International variation (INDIA/RETIN, it turns out; I'm in the US and thought I was buying the RETUS version, but I didn't pay enough attention to the store page). I have rooted the device easily, thanks to the assistance of these forums. I have also installed TWRP 3.3.1-2-river for the purpose of backups and restores, though there seems to be problem with it. However TWRP is not the focus of my question right now.
I have become quite annoyed with the boot animation on this phone and would like to change it. Putting new boot animations in the /system/media folder has not been working and it seems to be because this international model has a boot animation override (that trumps all other boot animation locations) in the /oem/retin/media folder. The /oem folder is initially read-only, but can be remounted with read-write without error (using root). Using MiXplorer or the adb shell, I can delete stuff from there without error as well. However, when I reboot, it all comes back. I suspect that the changes I make to the /oem folder are not actually persisted to whereever in the first place. When I look at the mounts on the phone, I see /oem is mounted from /dev/block/dm-1. /dev/block/dm-1 is listed in my partitions list when the phone is booted up normally. From what I can tell though (and I'm not that knowledgable on this topic), that is just a "wrapper" around some data elsewhere. How can I tell where this dm-1 partition's data is really coming from?
As additional information, the block list by-name lists the oem image as belonging to block mmcblk0p58. When I boot into TWRP and mount that block, I do see the usual /oem stuff in there. I deleted the boot animation from there and tested unmounting the block, rebooting into TWRP and remounting the block and can see that the boot animation is still properly deleted from there. However, when I boot the phone back up normally, I see the usual stuff (including the boot animation) in the /oem folder still. That might make some sense, since it is listed as being mounted from /dev/block/dm-1 and not from /dev/block/mmcblk0p58 (though I was hoping dm-1 was a wrapper for mmcblk0p58).
This is the only dm mount on the phone; I don't have the problem with /system being uneditable because it is mounted to dm-0 like I see in many other posts for other phones. In turn, I don't think I have the "base data is encrypted" problem from those cases either (it is "just" an oem setup and not personal data). This still seems somewhat like the dm-verity problem I read about with other phones though (although this one doesn't give the dm-verity warning when I try to remount /oem as read-write). Running the commands:
Code:
adb root
adb disable-verity
just tells me
Code:
disable-verity only works for userdebug builds
verity cannot be disabled/enabled - USER build
I'm not sure how to check if there is dm-verity on in the first place though.
As a more direct question (though I would still like to know how to trace this dm-1 partition backwards), how can I make changes to this /oem folder actually persist between reboots?

@Spaceminer described the exact same problem for the Moto G6 in the Universal DM-Verity remover thread. In the end he said that it wasn't solvable without a system root.
https://forum.xda-developers.com/an...rceencrypt-t3817389/post81974407#post81974407
(I have since returned the phone because of this.)

1equals2 said:
@Spaceminer described the exact same problem for the Moto G6 in the Universal DM-Verity remover thread. In the end he said that it wasn't solvable without a system root.
https://forum.xda-developers.com/an...rceencrypt-t3817389/post81974407#post81974407
(I have since returned the phone because of this.)
Click to expand...
Click to collapse
i was unable to get this to persist either. i ended up using magisk for my work instead.

@1equals2 @HT123 To persist changes to your /oem partition the HAB (high assurance boot) verification must be deactivated. I've already successfully tested it on my device, a Moto G6 plus.
Here are the required steps: (only for Stock ROM!!)
1.) Start TWRP and backup /vendor + /system
2.) Mount /vendor + /system and delete the following
files:
- /vendor/etc/init/hw/init.mmi.hab.rc
- /vendor/bin/init.mmi.hab.sh
- /system/verity_key
3.) Go to /vendor/etc/init/hw and adb pull init.mmi.rc in order to edit the file.
4.) Open it and delete the lines 19+20:
Code:
19 # Moto verified boot extension
20 import /vendor/etc/init/hw/init.mmi.hab.rc
5.) Save the changes, copy it back to its path and set permissions to: -rw-r--r-- root:root
==> After the next reboot /vendor and /oem are mounted as ../vendor_a and ../oem_a (depending on your active slot).
As the last step you have to customize fstab.qcom to be able to access the files within the /oem folder.
Adb pull /vendor/etc/fstab.qcom and open it. The last line defines how /oem is mounted during the init process. You should change it like this:
before:​
Code:
/dev/block [...] /oem ext4 ro,nosuid,nodev,[STRIKE]context=u:object_r:oemfs:s0[/STRIKE] wait,slotselect,[STRIKE]verify[/STRIKE]
after:​
Code:
/dev/block [...] /oem ext4 ro,nosuid,nodev,[COLOR="red"]barrier=1[/COLOR] wait,slotselect
Save it and copy it back. Permissions: -rw-r--r-- root:root
>>> REBOOT AND ENJOY!!

[SOLVED] Restore decrypted nandroid backup of FBE

Tried restoring a nandroid backup of the data partition with twrp.
also copied the /data/media partition back from an external copy.
when booting up the phone immediately reboots back into twrp with an error message:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/vendor'
the vendor partition seems to be intact and i do have a backup of it taken at the same time as the data backup, restoring it doesn't yield results..
i'm wondering if FBE is throwing it off, as the backup was taken when the phone was decrypted (within twrp) however the data on the partitions is referencing some sort of encryption key?

you may also exhibit the following error upon bootup of a restored nandroid backup.
immediately after booting, the phone reboots back into recovery.
viewing the log in twrp will show:
Android Rescue Party...
The reported problem is:
'--reason=set_policy_failed_:/data/bootchart'
1. the solution to this is editing fstab.​​under twrp or other recovery​mount /vendor from the mount icon.​​in twrp: Advanced > File Manager > /vendor/etc/fstab.qcom​select edit file under userdata, find where it says fileencryption=ice​rename fileencryption to encryptable.​​Original​
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,fileencryption=ice,quota,reservedsize=512M
​​Modified​
Code:
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=ice,quota,reservedsize=512M
​save file.​
2. next delete the following directories:​
/data/unencrypted
/data/misc/vold/user_keys
3. Lastly delete any of the existing files from /data/system/ :​
locksettings.db
Gatekeeper.password.key
gatekeeper.pattern.key
locksettings.db-shm
locksettings.db-wal
recoverablekeystore.db
password.key
pattern.key
4. Reboot and re-encrypt​​
At this point rebooting from recovery will result in a running and successfully recovery backup.
one thing to note is the data and data/media partitions are at this point unencrypted
TRYING TO REINCRYPT NOW WILL FAIL to reencrypt got to settings > security > re set your pin or password for the phone
(optional) then select encryption and there will be an orange button to encrypt device.
the encryption process will take quite a while as it will reencrypt your entire phone.
The above doesn't work as it's trying to accomplish FDE, and the fstab line for encryptable=ice, isn't compatible with this.
i could not find an fstab string to follow the same option but for FBE.
​

Thanks for sharing, nice guide to disable forced FBE encryption! I think this applies to Android 12+ in general, not just OnePlus devices.
I ended up with the same problem on my Mi 10 Ultra with MIUI 13 after a /data partition restore and it was a real pain to solve ("set_policy_failed:..." rescue party error for different directories). It's strange though why it fails to set the fscrypt policy for existing directories with no policy, correct permissions and SELinux context...
(Btw: whether a fscrypt policy is applied to a directory ("is this directory encrypted?") can be checked with fscryptpolicyget in terminal.)
Unfortunately, this didn't directly solve my TWRP backup restore problem and I still had to do a manual restore, but now I can at least disable FBE and it's always nice to have actual control over the device you paid money for (you should really have control by default, but oh well...)
(Some of) the troubleshooting I did:
Like I mentioned, I first thought the issue might be with the SE linux context, so I tried running restorecon, but this didn't help - I eventually found that in init.rc, restorecon is usually already automatically run during each boot for directories under /data/... so running it manually makes no difference.
To edit /vendor/etc/fstab.qcom (or /system) on my device, I had to first disable the shared blocks EXT4 optional feature. I followed this nice guide to unpack/repack super.img. But this is missing the step for disabling shared blocks: when I tried to mount any of the unpacked images (e.g. vendor.img) as R/W, it failed with the useless generic error:
wrong fs type, bad option, bad superblock on ...
Click to expand...
Click to collapse
Then dmesg gave me another clue, but at the same time was still cryptic and not immediately helpful:
EXT4-fs (loop*): couldn't mount RDWR because of unsupported optional features (4000)`.
Click to expand...
Click to collapse
So I guess 4000 is the code for shared blocks and you can disable these with e2fsck -E unshare_blocks <your .img file or loop device> (and probably need a filesystem check with e2fsck -yf <file>). Again very annoying that these numerical feature codes are not mentioned anywhere in the e2fsck manual pages for example.
Anyway, I was finally able to either:
1. mount vendor.img on my PC (mount -o loop vendor.img /mnt/vendor) and edit the /mnt/vendor/etc/fstab.qcom right there before repacking the .img and flashing the new edited super.img to my device
or
2. just repacking the vendor.img with shared blocks disabled and size increased (resize2fs vendor.img <new size>) and flashing the new super.img without other modifications - this way /vendor can also be mounted as r/w in Android and changes made later (mount -o remount,rw /vendor).
The worst part is that in the end, even with decryption disabled and the keys deleted, the device still wouldn't boot after a /data restore from TWRP (and after multiple days spent on debugging )... I still had to manually extract the TWRP backup and move directories/files individually - thankfully no issues with app/ or data/ - I think the problem was with some files in either system/ or misc/, but idk for sure. I just manually went through and kept only what seemed important (saved wifi APs, BT devices, SMSs etc, but not saved accounts). And after this it finally booted with all my apps and (most of) my settings!
(Btw2: a TWRP/nandroid backup is apparently just a bunch of separate tar.gz files, not a split archive, so you can just extract them with for file in ../data.f2fs.win*; do echo "extracting $file..."; busybox tar -xzf $file; done)