Related
Hi
I've done a bit of searching but can't find anything too specific to what I'm trying to do. Basically we have 10 Android tablets, and I want to make them all standardised e.g. have the same Apps on, configured in the same way (e.g. enterprise wireless network added).
Now the thing is if anyone messes around with them I want a really easy way to restore them to the original config which I've done.
One way I thought was to configure one fully, install Titanium Backup on it, do a full backup of apps/system data etc, and put the backup onto an SD card. Then I already have the base ROM on an SD card so if theres any problems, I can just flash the ROM over it again, install TB, and restore all the data. Would this be suitable to do to duplicate the data onto 10 tablets, and also restore the data if required?
The other thing I looked into was customising a ROM myself, don't want to do anything too tricky it'll just be a case of removing all the preinstalled crap I don't want, preloading the Apps we do want, and if possible preloading the wireless key and getting rid of the first boot initial set up wizard.
PS I've looked at installing CWM and doing whole image backups, but supposedly the tablet isnt supported (its an Ainol Novo 7 Elf 2)
Any advice would be great, hopefully theres some fairly straight forward way of managing this
Thanks
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
kuisma said:
One of the reasons I integrated a full blown GNU/Linux on my devices, was the need to run full and automated backups. If you are looking into the possibility making a custom ROM, this might be a solution for you as well. I'm using BackuPC to run backups nightly, backing them up as any other GNU/Linux machine (using tar over ssh).
See the link in my signature for more information about this.
Click to expand...
Click to collapse
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
fro5tie said:
Hi
Thanks for the reply, not too sure this would be the right option for us. I don't really need to take nightly backups, I just need to make a backup of a preconfigured image, and then put that image onto 10 other devices. Then I want to keep the original backup and have an easy way to restore it onto any devices which have been messed up. Sort of like image cloning for PCs, I want to prepare a base image, and then flash it over all the devices.
Click to expand...
Click to collapse
Ok, I see. Compile the image to you likings (boot image and system partition), and then flash it using fastboot onto you devices.
Hi
Does anyone have any more thoughts on this?
I have experimented with Titanium Backup and this seems to work quite well. I have installed a ROM, and customised it e.g. installed the apps I need and configured the apps, wireless settings and home screens etc. Then I do a full apps + system backup in TB to my SD card.
Then the plan is, I can reflash the ROM onto the other device, install TB and then restore this backup. This saves my user state and wireless settings etc.
Only problems is when I flash the ROM, I have to go through all the initial set up again and also remove some preinstalled apps which I dont want. Any ways around this?
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
kuisma said:
There must be something I'm missing. Why don't you install the device, walk through the setup, remove the bloatware you don't want and then dumps the disk partitions into images you flash the other devices with using fastboot? This way you'll get'em cloned, isn't it this you want..?
Of course there's still some tinkering needed once restored/cloned, such as giving them individual Google accounts etc, but you can easily fix this without re-running the setup wizard.
Click to expand...
Click to collapse
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
fro5tie said:
Hi
Yes that's what I want to do! How would I go about dumping the disk into an image and then flashing?
Click to expand...
Click to collapse
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
kuisma said:
There are several methods. Some boot loaders (such as nvflash for tegra based devices) can actually read back the disk partitions to a computer via the USB port. You can also on the tablet read the raw mtd device with busybox/dd. I assume you've unlocked the bootloader and gain root access to the device, since this is a requirement for flashing them as well. A third alternative is using busybox/tar, and then recreate the filesystem image using mkyaffs (or if ext3/ext4 even easier, just loopback mount an image on you linux maching to unpack the tar archive to). Once you got the images (system and userdata partitions), you flash the devices with "fastboot flash system system.img" and "fastboot flash userdata data.img". I don't believe you'll need to tamper with the other partitions.
Click to expand...
Click to collapse
Hi
Thanks for the quick reply, much appreciated.
Unfortunately you've lost me a bit here!
Yes the device is rooted, I dont have a linux machine though.
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
fro5tie said:
Any chance you'd be able to provide some more specific instructions? The device is a chinese tablet from manufacturer Ainol, the model is a Novo 7 Elf 2. Unfortunately there isn't much discussion on these online so specific help is hard to find!
Click to expand...
Click to collapse
I can provide you specific answers to specific questions, but I have no experience of the tablet in question, so you'll have to do some digging yourself first. Make sure it supports fastboot, investigate what the proprietary bootloader is capable of, see how/if you can obtain an original image etc.
One maybe easier solution, especially if you plan to restore the tablets on a regular basis, is to only make a new boot image to reflash the devices with. The only modification done is that you change the /init.rc script to mount /data and /system from the SDcard instead of from the internal nand disk device.
Once this is done, you'll power up and run the installation wizard and everything on your master tablet. Then power it down, and clone the SDcard. This SDcard now contains everything, so you'll simply restore a device by replacing its SDcard with a copy of this master card. I guess it's easier to clone a SDcard than reflashing several internal partitions. Easier to make the master as well - you don't need to dd or tar them, they are already in "image" format. If you can get hold of the original firmware, this should be quite easy without the need to preserving data from the device itself.
fro5tie said:
Any chance you'd be able to provide some more specific instructions?
Click to expand...
Click to collapse
Issue the commands "cat /proc/mtd" and "mount" on your device at command prompt (e.g. via "adb shell" or the "ConnectBot" terminal app). This shows you if the device allows you to copy the boot image from it. Paste in the output into this thread. If you believe the "clone the tablet via the SDcard" is a good solution for you, the process is in short terms something as below;
Copy the boot image to the sdcard:
# dd if=/dev/mtd/mtd2ro of=/mnt/sdcard/boot.img bs=2048 (device dependent of contents of /proc/mtd)
Remove the sdcard, insert into a computer, split the boot image info kernel + initramfs. Read http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images for instructions about how to work with the boot.img file. I really recommend a GNU/Linux environment for this.
Then edit /init.rc replacing the "mount yaffs2 [email protected] /system" with "mount ext3 /dev/block/mmcblk0p2 /system" for system and data (use p3 for data partition, the device name may be different on your tablet, see mount output).
Create an SDcard with three partitions: #1 vfat (standard), #2 and #3 ext3. Insert into you device and boot it up again.
# mount -t ext3 /dev/block/mmcblk0p2 /root
# cd /system
# tar cf - . | (cd /root ; tar xf - )
# umount /root
# mount -t ext3 /dev/block/mmcblk0p3 /root
# cd /data
# tar cf - . | (cd /root ; tar xf - )
# umount /root
This copies your partitions to the SDcard. Shutdown the tablet again.
Make a new boot.img using the instructions in the link above, using the edited init.rc script.
Now you can non-destrutive give this a try.
Place you tablet in fastboot mode (often vol-up (or vol-down) during power on).
$ fastboot devices
This vill verify the tablet is in fastboot mode. It should be listed. Then:
$ fastboot boot boot.img
Note here, only BOOT the tablet, do NOT use the "flash" keyword. This in case of the image isn't working, you'll just have to restart you tablet, and no harm's done.
Look around. Do a "mount" command. Everything works? Mount shows /data and /system from sdcard? Perfect. Now you can reflash it. Shutdown and flash:
$ fastboot flash boot boot.img
Now the device will use /data and /system from the SDcard every time. Customize your device, and then clone your SDcard and try it in tablet #2 you'll booting with your new boot.img and the cloned SDcard. Verify that #tablet #2 is a perfect clone of tablet #1. It is? Now you can flash the boot,img into all your tablets.
--------------------
But don't forget, there may be other solutions as well, maybe more suitable. This you'll have to investigate yourself.
And the usual disclaimer - you can probably not follow above by the letter. There sure is some obstacle you'll have to overcome, something non-standard, etc.
Also keep the original boot.img file for safekeeping in the case you want to restore the device's boot image some day.
Wow! Thanks for the info! This is really helpful, I need to set aside a bit of time to work through this and have a look. Thanks again its really appreciated, I'll be back with info once I've had chance to give it a go!
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
tweeny80 said:
I certainly can't offer more detailed info than the fellow from Sweden who seems to really know his stuff...but what about making a nandroid backup of your fully configured reference tablet (I'm assuming all tablets are rooted). Ensure all your tabs have CWM recovery and copy your nandroid file to each one.
If any of your fleet get 'corrupted' you can simply restore the original, fully configured ROM.
In fact that sounds too obvious..likely I missed something about your scenario which precludes this option from consideration!
Good luck mate.
Click to expand...
Click to collapse
Hi
Yes that was my first thought as well, tablets are rooted yes but there is no CWM for the tablet. Its an obscure Chinese branded tablet.
Unless there is another way to do nandroid backups?
hmm tricky situation. Catch 22 ! From what I know, your best bet is to backup all possible things through Titanium Backup given that you don't have the use of Nandroid backups. You can include wifi settings, messages etc but it's modular & not systemic.
I did a quick google search with no luck - time to upgrade your fleet dude :-0
Best of luck.
F2FS is a brand new file system developed by Samsung. The F2FS acronym stands for Flash Friendly File System. It creates an additional layer that improves the performance and life of the flash memory and the overall performance of any system with flash storage. Almost all the Android phones today still come with the old linux ext4 filesystem. This type of file system is not hardware optimized so it is a baseline for performance. There are plenty of benchmarks and tests throughout the web providing evidence of the overall performance improvement of F2FS over ext4 in Android phones. New flagship devices from Huawei, One Plus and many Motorola phones are now using F2FS as stock filesystem. The flagship Moto Z comes with F2FS, sporting a fabulous 1/10 of lag compared to the Pixel XL. However mind that it is a new technology with barely 3 years of development and you might encounter some issues if you try different configurations. But, we are here testing unofficial things, so risk is a known partner. Just keep a safe backup, that is all you need.
Migrating /system has no sense since it is a read only partition (most of the times) and ext4 is faster for pure readings. On the other hand /cache is formatted to ext4 at boot by the kernel. So patching the kernel is the only way to migrate that partition.
Data partition along with the internal storage can be upgraded to F2FS with visible results. Here I share a method to migrate your system without losing any information. The procedure is reversible, so you can return back to the traditional ext4 in case you are not satisfied with the result. The procedure only requires TWRP recovery 3.0.3 and an external sdcard with enough free space to do at least a backup of the data partition. Since we are not modifying boot or system, this procedure is compatible with unrooted systems with locked bootloaders. It is compatible with all the AXON 7 ROMs.
INSTALLATION
1. Reboot to TWRP and perform a backup of your data partition to your external sd (you can't use internal storage since it will be wiped during the process along with the data partition).
2. Backing up your Internal SD card requires a different way. Here I propose 2 options:
2a. If you have an External SD card with enough free space (check that first), you can use it to temporary store the content of the internal sdcard. While in TWRP root menu, go to Advanced / File Manager and browse into the sdcard (You will see the contents of your internal storage). Tap on the checked folder icon on lower right corner. Select Copy Folder. Now browse into the external_sd folder (you will see the contents of yout external SD) and tap the checked folder icon again. Upon confirmation, it will create a folder named sdcard into the external sd with all the contents inside.
2b. If you do not have a micro SD card with enough space then you can use your computer as backup location. From your computer type adb pull /sdcard and all the content of the internal sdcard will be transferred into a folder named sdcard under you current directory in your computer.
3. Now we can safely change the format of the data filesystem. Go back to the root menu of TWRP, go to Wipe / Advanced Wipe and select only the Data partition. Go to Repair or Change File System / Change File System / F2FS. Upon confirmation, the Data and internal sdcard will use the improved F2FS filesystem. If you have an AOSP based ROM such as LOS, RR or AEX among others, then you can do the same to format the Cache partition as F2FS. But do not reboot yet!
4. Go back to the root menu of TWRP and go to Settings. Ensure "Use rm -rf instead of formatting" is set. This will avoid future restores to change the type of filesystem.
5. We can't restore the data at this time since the system won't boot properly with all kernels, the Stock kernel is one of them. At this point it is safer to reboot the system and wait until the Android welcome wizard shows up on the screen. This will setup everything internally.
6. Now reboot to TWRP, go to Advanced > Terminal and enter the commands (you can bypass these commands only if you are using TWRP 3.0.4 or above):
Code:
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /data
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /sdcard
and then without leaving TWRP restore the backup you created in step 1. This will restore your data partition but this time applying an optimized F2FS structure. Do not leave TWRP yet, there is one more step left before booting into the system.
7. depending on the option you used in step 2 you have to follow one of the following options to restore your internal sdcard:
7a. If you used your External SD card for the internal sdcard backup then while in TWRP root menu, go to Advanced / File Manager and browse into the external_sd/sdcard folder. Tap on the checked folder icon on lower right corner. Select Copy Folder. Now while the root directory is listed tap the checked folder icon again. Upon confirmation, it will restore all the backup into the external sdcard back into the Axon 7 internal memory.
7b. From your computer type the following commands:
Code:
adb push sdcard /
adb shell chmod -R 777 /sdcard
This will restore all the backup of the internal sdcard back into the Axon 7 internal memory. All but the empty directories.
You are done!!!! just reboot into the system with the new state of the art F2FS filesystem.
Sometimes the lockscreen information gets corrupted after restoring a backup. Since this process relies on restoring a TWRP backup, chances are that you are experiencing this issue too. In such case please follow the guide for clearing the lockscreen security settings in the AXON 7.
UNINSTALL
In case you want to go back to the initial state with ext4 filesystem in the Data and internal storage just follow these steps:
1. Reboot to TWRP and go to Settings. Ensure "Use rm -rf instead of formatting" is NOT set. This will allow to restore the data partition to the original filesystem of the backup.
2. Follow steps 6 and 7 of the installation instructions, exactly the same way, to restore the Data and internal storage to ext4 with the same contents.
I hope you find this interesting since it is a performance improving method that drains less battery, doesn't involve rooting, doesn't overheat the processors and provides noticeable results. Just let me know if this guide has been useful for you.
NOTE: If you delete Dlavik/cache in the process, please note that rebuilding it is quite fast, less than 5 seconds. This is caused by the cache of the F2FS filesystem, but all processing has to be done. The system will boot after a quick apps initialization but you will see the system somehow a little slow. Leave it for some minutes until all the apps had been completely processed. It is done in the background, but al least you have your system up and running quite fast even after deleting dalvik/cache partitions.
UPDATE (2017-01-20)
If you have already switched to F2FS filesystem without the optimization parameters for TWRP (using TWRP 3.0.3-2 or below with the initial version of this guide), then you just have to enter in TWRP and follow all the steps without leaving recovery:
STEP 1: reboot to recovery and go to advanced / terminal. Type the command df. This will give you the current usage of the partitions. Write down the total 1K blocks, used and available statistics for the /dev/block/dm-0, the partition shared by data and sdcard. You will use these statistics to compare before and after.
STEP 2: Backup of your system (Boot, system and Data) to external SD.
STEP 3: Backup your internal storage (either way of those detailed in the guide)
STEP 4: Format Data and internal storage.
STEP 5: If you are using TWRP 3.0.4 or above then you can bypass this step. Otherwise open the terminal under advanced menu and type
Code:
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /data
mount -o remount,discard,nosuid,nodev,noatime,nodiratime,nobarrier,inline_xattr,inline_data /sdcard
STEP 6: Restore your Data partition.
STEP 7: Restore your internal storage.
STEP 8: Go again to the terminal inside TWRP and type df again to see the difference in the data and sdcard shared partition.
Please let us know your statistics before and after.
Soon this guide will include the final F2FS optimization patch to be used within your system, it will require root, but is that a problem? On the other hand @jcadduono is working on a new version of TWRP using the backported f2fs drivers from Android kernel 4.10 (our stock kernels still use Android 3.18) with the correct optimized mount options. It is still under development but as soon as it was finished, I will update this guide on how to use the new features. Stay tuned!
That's all folks!
Switching to most F2FS doesn't make sense for anything other /cache (which is rarely even used, so probably not worth it) and /data (probably very worth it). The benefits that F2FS related to writing to the partition a lot over time.
There is no benefit to using F2FS for /system over ext4, in fact there are probably downsides. You aren't generally writing to /system very often, so no need to worry about write speeds to it. Read speeds are going to be similar anyway. And unless all the more recent F2FS development is backported into the kernel, you'd be running a very old version of F2FS as well.
I got almost 5000 more score in Antutu just by migrating the data partition from ext4 to F2FS. Writes are slower than reads for almost all the storage systems, and a flash memory is not different. An increase in the write performance is more noticeable than the reduction in read performance. That combination provides an overall increase in performance to the system.
I have been using it in my previous phone for more than 1 year without any issue, however having a stable and updated implementation is in the hands of the kernel developers. recently the Moto-Z uses the F2FS in its data partition with a very effective mount options. Probably this mix of mount options are the trick that makes the Moto-Z the fastest phone regarding filesystem.
jcadduono said:
you can enable it by opening the zip file for the kernel installer and editing patch.d/*-f2fs-fstab
all you have to do is remove the # in front of the partitions you want f2fs added for near the bottom, just below the comment telling you what to do
Click to expand...
Click to collapse
I do not find those files inside the patch.d folder inside the zip file (the minimal kernel patch). I will take the file from the full kernel and I will insert into the minimal patch.
I would like to enable F2FS for the cache partition as well as using the mount options: rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,nobarrier,extent_cache,active_logs=6 for the data partition. It should increase the performance over the current options set. System partition has no reason to be migrated.
I will modify fs_data_opts string definition in the 06-f2fs-fstab file as well as trying to configure cache as a F2FS. If Motorola is using F2FS with successful results, then probably it worths it. I am trying to test whether the solution Motorola did with the Moto Z also works in our device. A deep analysis can be found here.
Oki said:
I do not find those files inside the patch.d folder inside the zip file (the minimal kernel patch). I will take the file from the full kernel and I will insert into the minimal patch.
I would like to enable F2FS for the cache partition as well as using the mount options: rw,seclabel,nosuid,nodev,noatime,nodiratime,background_gc=on,discard,user_xattr,inline_xattr,acl,inline_data,nobarrier,extent_cache,active_logs=6 for the data partition. It should increase the performance over the current options set. System partition has no reason to be migrated.
I will modify fs_data_opts string definition in the 06-f2fs-fstab file as well as trying to configure cache as a F2FS. If Motorola is using F2FS with successful results, then probably it worths it.
Click to expand...
Click to collapse
https://raw.githubusercontent.com/o...er/marshmallow/ailsa_ii/patch.d/06-f2fs-fstab
add it to the patch.d folder then. change the data mount flags to whatever you want.
i highly advise against uncommenting system/cache, f2fs is nothing but downsides for them. (incompatibilities for cache, which is unused by OS anyways), system is going to be read only all the time and ext4 has much better inode access/index times than f2fs so clearly better for read only, ex. $PATH reading to find locations of binaries to run, so please don't use f2fs on /system.
rw - lol all filesystems are rw by default
seclabel - this isn't a flag for you to use
nosuid/nodev - somewhat of a safety mechanism, unrelated to performance
noatime - very tiny write performance increase that won't be noticeable
nodiratime - same as noatime, but even less so
discard - i don't believe discard mount option is supported on Axon 7.
acl - acl will reduce performance (that's just extra access control/permission management)
nobarrier - this will increase the performance, yes, and it's probably a good idea because you don't have to worry at all about power outages other than severe kernel panics
extent_cache - this is on by default, so no need to specify it
inline_data - this is also on by default, no need to specify it
inline_xattr - no noticeable changes in performance, but normally specified on android i'd keep it
active_logs=6 - the default is 6, so no need to specify it, and there's no need to change this value (6 is optimal)
background_gc=on - the default is on, so need to specify it....
user_xattr - this isn't actually a valid f2fs flag, it is the default though, and don't specify nouser_xattr on android, it will cause bad things to happen
so....nobarrier is the only flag you should care about adding. no, it won't make a noticeable difference.
read: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
You can Only go in TWRP then format Data to F2FS and then install the Rom .Have No Problem and all works fine.But cache not work.Every time i Boot android he write it back to Ext4.But data work
jcadduono said:
https://raw.githubusercontent.com/o...er/marshmallow/ailsa_ii/patch.d/06-f2fs-fstab
add it to the patch.d folder then. change the data mount flags to whatever you want.
i highly advise against uncommenting system/cache, f2fs is nothing but downsides for them. (incompatibilities for cache, which is unused by OS anyways), system is going to be read only all the time and ext4 has much better inode access/index times than f2fs so clearly better for read only, ex. $PATH reading to find locations of binaries to run, so please don't use f2fs on /system.
rw - lol all filesystems are rw by default
seclabel - this isn't a flag for you to use
nosuid/nodev - somewhat of a safety mechanism, unrelated to performance
noatime - very tiny write performance increase that won't be noticeable
nodiratime - same as noatime, but even less so
discard - i don't believe discard mount option is supported on Axon 7.
acl - acl will reduce performance (that's just extra access control/permission management)
nobarrier - this will increase the performance, yes, and it's probably a good idea because you don't have to worry at all about power outages other than severe kernel panics
extent_cache - this is on by default, so no need to specify it
inline_data - this is also on by default, no need to specify it
inline_xattr - no noticeable changes in performance, but normally specified on android i'd keep it
active_logs=6 - the default is 6, so no need to specify it, and there's no need to change this value (6 is optimal)
background_gc=on - the default is on, so need to specify it....
user_xattr - this isn't actually a valid f2fs flag, it is the default though, and don't specify nouser_xattr on android, it will cause bad things to happen
so....nobarrier is the only flag you should care about adding. no, it won't make a noticeable difference.
read: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
Click to expand...
Click to collapse
BIG FAT thanks for the resource. I have a safe backup of the whole system. and I am willing to play the guinea pig role in testing all these options. I already had moved the 06-f2fs-fstab patch into the patch.d folder. But it was late and got some error while flashing. Today I will try again.
Kevinkuensken said:
You can Only go in TWRP then format Data to F2FS and then install the Rom .Have No Problem and all works fine.But cache not work.Every time i Boot android he write it back to Ext4.But data work
Click to expand...
Click to collapse
I have tried to format F2FS and then restore the data and the system doesn't boot. What ROM are you using? So fat I only have tested stock and Z.A.D. ROMs and both exhibit the same behavior.
Im on ZAD Rom and have no Problem to change data to f2fs in TWRP.And Im on Beast Kernel
@jcadduono, I have been trying to add the patched 06-f2fs-ftab file into patch.d folder of your ailsa_ii_xda_safetynet_kcal-1.0 file. But recovery log always returns an error while flashing:
- Executing: 06-f2fs-fstabpatch.d/06-f2fs-fstab: line 2: : not found
patch.d/06-f2fs-fstab: .: line 3: can't open '/tmp/kernel-flasher/patch.d-env '
- Error: Script failed: 06-f2fs-fstab!- Aborting...
Failed to patch boot image!Updater process ended with ERROR: 1
Any clue on what could the problem be?
BTW, I look forward to see your Nougat Kernel!!!!
Thanks for all your help.
Oki said:
@jcadduono, I have been trying to add the patched 06-f2fs-ftab file into patch.d folder of your ailsa_ii_xda_safetynet_kcal-1.0 file. But recovery log always returns an error while flashing:
- Executing: 06-f2fs-fstabpatch.d/06-f2fs-fstab: line 2: : not found
patch.d/06-f2fs-fstab: .: line 3: can't open '/tmp/kernel-flasher/patch.d-env '
- Error: Script failed: 06-f2fs-fstab!- Aborting...
Failed to patch boot image!Updater process ended with ERROR: 1
Any clue on what could the problem be?
BTW, I look forward to see your Nougat Kernel!!!!
Thanks for all your help.
Click to expand...
Click to collapse
You must have somehow removed patch.d-env from the zip at some point, or added a space inside the quotes of . "$env"? I don't know why that error would happen otherwise.
Also, I told you seclabel and user_xattr are not valid f2fs flags, they are display flags only, you won't be able to boot with them.
jcadduono said:
You must have somehow removed patch.d-env from the zip at some point, or added a space inside the quotes of . "$env"? I don't know why that error would happen otherwise.
Also, I told you seclabel and user_xattr are not valid f2fs flags, they are display flags only, you won't be able to boot with them.
Click to expand...
Click to collapse
Finally I was able to flash it. Notepad++ caused the issue. It changed the line end control character and replaced CF by CR+CF. So I just edited it using Sublime and everything went as expected. It flashed properly and the options are in place after reboot. By the way, I removed also seclabel and user_xattr, they are applied by default. I will start doing tests tomorrow.
Happy new year!!!
Cache partition still boot as ext4 after the patched F2FS patch.
I have run AnTuTu v6.2.7 without any overclock at all after applying the F2FS options of the Moto Z. I used my daily drive data with the stock ROM and the repatched patch of @jcadduono to allow F2FS with the extra options.
The AnTuTu score is 152937 Wich makes it the third Android phone in the top 5 list. Adding this patch to an optimized kernel configuration could be close to the iPhone 7 score.
Wow! This phone is a S7 killer!!!
Oki said:
Cache partition still boot as ext4 after the patched F2FS patch.
I have run AnTuTu v6.2.7 without any overclock at all after applying the F2FS options of the Moto Z. I used my daily drive data with the stock ROM and the repatched patch of @jcadduono to allow F2FS with the extra options.
The AnTuTu score is 152937 Wich makes it the third Android phone in the top 5 list. Adding this patch to an optimized kernel configuration could be close to the iPhone 7 score.
Wow! This phone is a S7 killer!!!
Click to expand...
Click to collapse
Dude, I get 152K with B29 stock OS
XblackdemonX said:
Dude, I get 152K with B29 stock OS
Click to expand...
Click to collapse
Even when using the same device, there will be people with more and less performance with stock OS using ext4. It will depend of the bin of the processor, the temperature (thermal throttling), the set of apps you have installed running in background, etc. The important number is the score difference between ext4 and F2FS, in my case it was 7657 points after the F2FS options patch.
Thanks for sharing this. I was under the impression that the stock kernel didn't support f2fs fully for some reason.
I am trying to optimize the filesystem even more. The next step is to provide specific parameters for the geometry with the fs geometry options in the mkfs.f2fs -s- z: these options control number of segments per section and number of sections per zone. Sizes that match chip parameters may speed up FLASH write operations. I assume this should have been taken care of, but I am just trying to find more optimization opportunities within the options.
Does anyone know these two geometry parameters for our eMMC?
@jcadduono Do you know what is the default geometry for mkfs.f2fs partitions in TWRP?
On the options part, I am also considering inline_data and inline_dentry.
Thanks
@Oki
Have you shared with ZTE for inclusion in future updates?
puremind said:
@Oki
Have you shared with ZTE for inclusion in future updates?
Click to expand...
Click to collapse
Nope, I hanven't. But feel free to share this with them if you wish!!!
Happy new year.
I have updated STEP 6 to optimize the initial F2FS structure when restoring the backup. I have also modified jcadduono kernel patch to inject these options also in the kernel to make them permanent. This results in about 3000 extra score in Antutu.
Not sure my question in subject is clear, so here's the thing...
I have dual-boot tablet with Android 5.0.1 and Windows 10 installed, and the model is Onda V80 Plus (32GB), if that matters at all.
I'm really having hard time rooting this device using standard methods (even with much of background knowledge and experience), so I was about to take a different route.
I installed Paragon ExtFS windows app which gives me read/write access to /system and /data android partitions (which have ext4 filesystem).
I was wondering if anyone knows if it's possible to gain root access in Android just by copying some files and changing some permissions or whatever from within Windows OS?
Basically, for those not familiar with ExtFS app, I can assign a drive letter to /system and /data partitions, and do whatever I want with them just like with any other drive or volume.
I'm aware that modifying ext4 partitions can render my Android OS unbootable, but I have a backup and would like to try it anyway as this is my last option.
When I look into SuperSU.zip file (which I always flashed through CWM/TWRP recovery to gain root access), I see many files which some lengthy script is copying all around, so I stopped after analyzing about hundred lines of code lol.
I really didn't find any method like this on the internet, so I wonder if that's even possible, and if it is, how would I go about it?
Thanks everyone.
Burs said:
Not sure my question in subject is clear, so here's the thing...
I have dual-boot tablet with Android 5.0.1 and Windows 10 installed, and the model is Onda V80 Plus (32GB), if that matters at all.
I'm really having hard time rooting this device using standard methods (even with much of background knowledge and experience), so I was about to take a different route.
I installed Paragon ExtFS windows app which gives me read/write access to /system and /data android partitions (which have ext4 filesystem).
I was wondering if anyone knows if it's possible to gain root access in Android just by copying some files and changing some permissions or whatever from within Windows OS?
Basically, for those not familiar with ExtFS app, I can assign a drive letter to /system and /data partitions, and do whatever I want with them just like with any other drive or volume.
I'm aware that modifying ext4 partitions can render my Android OS unbootable, but I have a backup and would like to try it anyway as this is my last option.
When I look into SuperSU.zip file (which I always flashed through CWM/TWRP recovery to gain root access), I see many files which some lengthy script is copying all around, so I stopped after analyzing about hundred lines of code lol.
I really didn't find any method like this on the internet, so I wonder if that's even possible, and if it is, how would I go about it?
Thanks everyone.
Click to expand...
Click to collapse
Root needs a custom kernel. Not something you are gonna do with a Windows setup the way you have it. Also you will most likely not find anything as that is most likely not an official version of Android as Google doesn't allow dual booting.
Thanks for a reply. But I don't see what does custom kernel have to do with what I try to achieve? If I could, in my Windows environment, replicate the modifications that script inside SuperSU zip does to /system partition, I should gain root access, right? In theory that is, since I'm aware lots of things can go wrong. I was hoping someone could explain a bit what SuperSU script is doing when run inside custom recovery, so I try to do the same thing. Again, if it's possible, and if it's worth the time spent. But I have time, and I'm always willing to learn something new.
Burs said:
Thanks for a reply. But I don't see what does custom kernel have to do with what I try to achieve? If I could, in my Windows environment, replicate the modifications that script inside SuperSU zip does to /system partition, I should gain root access, right? In theory that is, since I'm aware lots of things can go wrong. I was hoping someone could explain a bit what SuperSU script is doing when run inside custom recovery, so I try to do the same thing. Again, if it's possible, and if it's worth the time spent. But I have time, and I'm always willing to learn something new.
Click to expand...
Click to collapse
what su is doing is pulls the kernel and patches it. root access is defined in the kernel. what itnis doing in system is flashimg just the apk
Ok, I see. So if I ask someone who rooted the same model successfully to send me patched kernel, I could easily flash it in fastboot mode (my bootloader is unlocked). So only thing left to do would be to copy apk inside /system/app, and cross my fingers? I'll post my findings if I manage to do something worth writing about. Thanks.
I have same problem with you. I can't root my Onda V80 plus. I unlock bootloader, flash recovery for my device. Then, i put it into recovery mode and install supersu.zip over recovery. When i reboot this onda, it has stopped in onda logo.
bahuy2003 said:
I have same problem with you. I can't root my Onda V80 plus. I unlock bootloader, flash recovery for my device. Then, i put it into recovery mode and install supersu.zip over recovery. When i reboot this onda, it has stopped in onda logo.
Click to expand...
Click to collapse
I managed to root my Onda few days after my last post, but forgot to post my findings, sorry. I didn't used any of my hacker's skills lol, but I researched a bit more and found out what I was missing. The same issue is with you, so you have to disable verity before flashing recovery by typing in these commands:
Code:
adb root
adb remount
adb disable-verity
adb reboot
After rebooting install supersu.zip, and the next boot won't hang on Onda logo anymore. Hope this helps you.
btw, note that not just any adb version has verity command line switch. You have to download newer adb version!
Thank you! I trie a lots times, but i can't make successfully!
Basic root procedure would be: unlock BL -> disable verity -> flash (temp) recovery -> install SuperSU
Here are the links containing all the files neccessary for rooting Onda V80 Plus: Mega | MediaFire
Note the ReadMe.txt inside archive. It contains list of adb/fastboot commands needed to be executed in order to successfully root the device.
Thank you very much! I download your file and root successfully my Onda V80 plus! It works well for me.
Sorry if a similar thread has been made, but I cannot find any guide to rooting this damn thing that doesn't involve sketchy one-click-root apps. Any help would be greatly appreciated.
Follow-up question: I did some more digging around on Google and found this:
www(dot)getdroidpro(dot)com/oppo-a77-mediatek-root-via-magisk/
Is this legit?
Forget all the so-called One-click-Root apps: they are known to be spyware. If used and in fact working then take note they modify Android's /system partition what easily can get detected.
In contrast to that Magisk uses a systemless strategy for rooting, meaning that your device's Android will be rooted without any alterations or changes being made to the /system partition. In fact, /system is not even mounted r/w by Magisk. This is accomplished by Android's boot image patching. The bad thing, IMHO, is that you have to install TWRP, too, in order to install Magisk.
Finally: Magisk is a hacker tool, in Google's point of view it's NOT legit.
jwoegerbauer said:
Forget all the so-called One-click-Root apps: they are known to be spyware. If used and in fact working then take note they modify Android's /system partition what easily can get detected.
In contrast to that Magisk uses a systemless strategy for rooting, meaning that your device's Android will be rooted without any alterations or changes being made to the /system partition. In fact, /system is not even mounted r/w by Magisk. This is accomplished by Android's boot image patching. The bad thing, IMHO, is that you have to install TWRP, too, in order to install Magisk.
Finally: Magisk is a hacker tool, in Google's point of view it's NOT legit.
Click to expand...
Click to collapse
Hey thanks a lot, I'll take this to assume Magisk is a decent way to go about the rooting process.
Ok, I get that boot-debug has been around for years... since android 10 for me, before that, it was variant=user, or variant=eng(ineer).
Strange how after I show boot-debug.img, magisk chooses this very path, but only after. Keeping in mind many people come here asking questions, and all those that know sit back and say nothing. Until they dont like what they see.
If you know better, and cant help, please keep your comments to yourself. This thread is intended to HELP, and is targetted toward those who CHOOSE to HELP because they CAN.
How I got su to work. Is this root? Now this is a good question. I dont want ANY overlaid system in my fone. I want to write to system like many others want to.
Not some google way of forcing us to use their mirrored online version of a locked filesystem already on my f'n.
Priority 1: I want to root my f'n without internet. Period. I do NOT want magisk using my credit. This proves we pay for magisk. I sometimes live so far from the world wide web, that offline is the only way to work. So I need to be able to root without google or THEIR employees offerings.
Priority 2: RW-able system.
So, I discover boot-debug.img for my f'n. Had it for a year, before I discovered it. Yeah, I discovered it after a year here asking, and getting NO replies that worked. Only after I'm vindicated to the naysayers 'thats been around forever...' yeah, try helping instead of useless comments.
In the end, I learned so much in such a short time. Constructive critiscism is NOT insulting. Magisk kills root in MY f'n. PERIOD. Camera does not work, location does not work, and I cant make/receive calls. But hey, it's an overlaid file system, of course it wont ALL work, I mean, I'd expect to lose a lil functionality, but disabling the GSI ability in dev options? I dont think so.. Worse, lack of adb or fastboot is produced in my f'n when using magisk, so tata magisk.
My logs actually explain all, so no more crappy adb logs. Yeah, I like simple adb, it works, or I'll MAKE it work.
Like this:
Attempt every possible method of flashing magisk according to tut's, nada. 3 different paths lead me to...?
1: The note9 recovery I found, that lopstom was kind enough to twrp for me (well appreciated) is the KEY to gaining root on my ulefone armor x5 mt6765. It turns out that the note9 recovery is actually an android 9 os, with a 'super' .img - and being android 9, the bootloader I used is an OLD bootloader, in particular, the variant=eng type. Note this, this is key.
2: With the note9 flashed to recovery I can RW system in android 10 properly, but only in twrp.
3: Discover boot-debug.img - yup, it's not quite a variant=eng build, but it does work for the following:
Flash boot-debug.img. By doing so, you get the adb root command, and the disable-verity options, way better than wiping vbmeta, which contains the 'is it rw, or ro' of every file in every partition to be mounted in their own partitions, but what most dont know, is each file mounted in it's own mountpoint also has the information contained by vbmeta, but for each seperate file. So unless you add the /null (one for system, the other for vendor) after the disable-verity...
Nah, wipe most of your directory structure, then wonder why in a RW-able system, it still dont work. Because each file in it's own mountpoint knows if the system directory SHOULD be ro or rw. That's EACH and EVERY stock file in it's OWN mountpoint, has the RW or RO inf for the system & vendor directory, ie, is system RW?
Example: Camera wont work, get it?
In the end, this is how I went about installing su.
Flashed boot-debug.img did NOT flash recovery. Flashed meefik busybox-arm64 to f'n, but did NOT install it, instead, I opened it to install it, top left, saved the busybox-arm64 and then flashed twrp, and while there, flashed the system_rw, to defeat the system_RW saying not enough space, I chose 1024, did the copy over of super_fixed, then rebooted, enabled system, THEN flashed the busybox-arm64 from twrp, and rebooted.
Results: I copied the busybox-arm64 su, from xbin to system. In order to defeat the system_RW saying not enough space, I chose 1024. Round numbers matter with system_RW, same senario as memory, so use sizes equal to how memory works. ie, 32, 64, 128, and multiples of.
Look at the adb posts in my closed thread.
With Su installed, I have to type exit TWICE to exit. without su in system, exit only needs typed once.
Now here is why I continue. I found root, but dont have the experience, but it's like this:
See all those lovely new file that end in .cel? Mine says platinum. That means I AM ROOT. By swapping out .cel files, I have all the access magisk denies me. .cel files... get on it devs... swap them out, try try try... find what I found.
I dont actually need su, but i need it for some apps. What I have proven, is that SU does NOT kill android 10_Q.
variant=user or variant=eng, is NOW dependant on .cel files, like, say, boot-debug.cel.
Have a nice discovery... I hacked googles latest offering my-cel-f
Edit: Cel files are found in the bootloader, a zero byte file, the file NAME decides what the loader can or cant do, PERIOD.
New root tools only require swapping these out, as well as a few system edits when done.
Ok, slight mistake in spelling so I'll add the following for you to 'see'..
userdebug_plat_sepolicy.cil
So it's not cel as I wrote in the first post, my point being just as valid.
Platinum clearly states there are more who's names I have yet to obtain...
Theoretically in my mind, if I swap the .cil file in the bootloader for say hypothetically:
engdebug_plat_sepolicy.cil... with the few edits seen in the android 10 notes I posted from china, the one where people say 'too much hassle' - I say, for them. Those notes show the rest of the cil files, so yeah, I got root OPTIONS to play with
Stay tuned for more scottish inventor style NOTES.
Edit: for the record: https://source.android.com/compatibility/vts/vts-on-gsi