Related
I am not responsible for any damage your nook suffers.
Officially supported by The Nooter Project for Nook Simple Touch
http://code.google.com/p/nooter/
Touch-Formatter
(Tool to return to stock)
Information:
What it does:
Formats: /data, /cache, /system
Installs 1.1 /system.
Regenerates /data automatically.
Bugs:
CWM may not refresh the screen correctly when booted, move the cursor with the right keys so it refreshes the screen.
If CWM hangs while rebooting, dont worry, force shutdown, and start your nook again, nothing bad happens.
Future updates: (In order of priority).
Update to 1.1.2
Be compatible with NSTG (Nook Simple Touch Glowlight)
Differentiate between the NST and NSTG (Nook Simple Touch Glowlight) so to make only one zip.
Backup /factory + Wipe the complete NST + Recreate the whole NST partition table + Restore /factory
User manual:
Things you will need:
CWM
Thread: http://forum.xda-developers.com/showthread.php?t=1360994
Direct download links:
http://forum.xda-developers.com/attachment.php?attachmentid=806435&d=1323121399
http://forum.xda-developers.com/attachment.php?attachmentid=806434&d=1323121315
Download it and burn it to an sd-card, (windows users use this to burn the image https://launchpad.net/win32-image-writer/+download)
You must have an external microSDCard reader to burn CWM, not the NST.
The button layout of CWM:
Both Buttons on the left: BACK
Upper button on the right: UP
Lower button on the right: DOWN
n button: SELECT
Power button: TOGGLE DISPLAY
Zips:
Download http://nooter.googlecode.com/files/Alpha-FormatTouch-2.zip
Old:
Download http://nooter.googlecode.com/files/Alpha-FormatTouch.zip and copy it on the sd card burnt with CWM
Instructions:
Copy the zip onto the root directory of the sdcard you burned the CWM.(Don't extract them)
Insert the sdcard on your nook, and boot it.
On CWM select install zip from sdcard
Then select choose zip from sdcard
Select Alpha-FormatTouch-2.zip, click yes and wait till the process finishes.
Go back, eject the sd card, and click reboot.
On future updates I'll try: automatically make a backup of /factroy, recreate the whole nook partition table so that people that screw hard can breathe new life into their NST easily.
Index
Automatic Methods:
[NST]MinimalTouch 1.1beta5
[NST]Touch-Formatter
Manual Tutos:
Skip registration (OOBE)
Making the manual process LESS PAINFULL
Setting up adb manually on the nook touch
Setting up root access on NST through adb and installing busybox
Improve battery life(testing)
Backup bookmarks and annotations(testing)
Enable non market app installs
Installing XorZone's B&N button modifier
Change the powered off screen image
Blocking OTA updates
Installing new fonts for your nook (testing)
Installing Gapps (+launcher, etc)
Totally uninstall Gapps (my repack), unrooting, erasing and restoring
Interesting or useful specific apps or hacks for Nook Simple Touch
nook 1.1 update
Thanks to:
ros87 for n2T-Recovery (http://forum.xda-developers.com/showthread.php?t=1289233)
mali100 for the correct command for the /data restoration and for CWM (http://forum.xda-developers.com/showthread.php?t=1360994)
bisbal for trying it out and giving ideas.
meghd00t for pointing out factory.zip is common across more than one NST and researching how to Resize Nook STR Partitions (http://forum.xda-developers.com/showthread.php?t=1225196)
dobbing for the copy of the 1.1 update.
Thanks eded333. Seems Nook touch developers are back on track. Glad to see all the busy posts. Cheer up.
eded333 said:
As some people where having trouble returning to stock after rooting, this is a semi automatic method, easy to follow, that will leave your nook stock (if you havent erased the unique data, flashing Noogie into the NST, which isnt recoverable ¬¬).
Click to expand...
Click to collapse
eded333,
Could you tell where unique data kept (what files)?
Hopefully, it’s small enough and easy to backup / zip
If Touch-Formatter can read the file from SD, it can restore unique data easily, right?
ApokrifX said:
eded333,
Could you tell where unique data kept (what files)?
Hopefully, it’s small enough and easy to backup / zip
If Touch-Formatter can read the file from SD, it can restore unique data easily, right?
Click to expand...
Click to collapse
If i'm not wrong /rom and /factory both hold unique info for every nook, as mac, etc.
If you root your device, the only partitions which are touched are /data and /system, so dont worry for that.
Yes, it should be easy to, for example, to create a Backup.zip which did a backup of those files, partitions, or anything you want and then add to this or another zip a way to restore them from the SD.
Anyway there is allready a tuto for something like that, which creates a full backup of your Nook and it should be the first step before playing with it:
http://forum.xda-developers.com/showthread.php?t=1142983
Edit:
The backup done by CWM dosn't backup /rom and /factory.
So do I have to register again after using this? Or does it stay registered? (I haven't had to wipe my Nook in a while. I'm so proud of myself! xD)
Googie2149 said:
So do I have to register again after using this? Or does it stay registered? (I haven't had to wipe my Nook in a while. I'm so proud of myself! xD)
Click to expand...
Click to collapse
This completely erases /data /cache and /system.
So... yes , you will need to register again, after using this.
eded333 said:
If i'm not wrong /rom and /factory both hold unique info for every nook, as mac, etc.
If you root your device, the only partitions which are touched are /data and /system, so dont worry for that.
Yes, it should be easy to, for example, to create a Backup.zip which did a backup of those files, partitions, or anything you want and then add to this or another zip a way to restore them from the SD.
Anyway there is allready a tuto for something like that, which creates a full backup of your Nook and it should be the first step before playing with it:
http://forum.xda-developers.com/showthread.php?t=1142983
Or you can use the latest CWM: http://forum.xda-developers.com/showthread.php?t=1360994
Click to expand...
Click to collapse
That’s exactly what I want to avoid – to create full 1.8GB backup.
Isn’t it nice to have tiny backup, email to self, just in case?
There is /rom folder, but no /factory one.
/rom “zipped” is 32KB only
Searched both threads you mentioned – cannot find anything related to /factory folder.
Does /rom/devconf backup sufficient?
ApokrifX said:
That’s exactly what I want to avoid – to create full 1.8GB backup.
Isn’t it nice to have tiny backup, email to self, just in case?
There is /rom folder, but no /factory one.
/rom “zipped” is 32KB only
Searched both threads you mentioned – cannot find anything related to /factory folder.
Does /rom/devconf backup sufficient?
Click to expand...
Click to collapse
While your idea with just backing up the unique data (which resides in both the rom partition and the factory one) might seem a good one, what happens when you screw up your NST the way that 99% of the users that asks me for help does?
If you delete/corrupt/overwrite boot, rom, factory or data, then your tiny rom backup won't help you much unless you can get a copy of the other partitions from someone else.
And then there's the problem with alignment of the data partition, which is part of an extended partition.. The first thing people usually kills is the partition table , and simply restoring it from another NST will (in 70% of the cases) not bring back the extended partitions
My vote would be a little yes and mostly no
ros87 said:
While your idea with just backing up the unique data (which resides in both the rom partition and the factory one) might seem a good one, what happens when you screw up your NST the way that 99% of the users that asks me for help does?
If you delete/corrupt/overwrite boot, rom, factory or data, then your tiny rom backup won't help you much unless you can get a copy of the other partitions from someone else.
And then there's the problem with alignment of the data partition, which is part of an extended partition.. The first thing people usually kills is the partition table , and simply restoring it from another NST will (in 70% of the cases) not bring back the extended partitions
My vote would be a little yes and mostly no
Click to expand...
Click to collapse
I think a backup of ROM itself should be a yes. Because if you have that and somehow completely absolutely destroy your partition, you will be able to with a little work and kindness from others eventually completely restore your device, in fact you could create a generic copy of the partitions blank or otherwise then use that to restore a device, have a script take the rom insert it write /boot /system etc for you and you're good to go.
However this shouldn't be used in place of a proper backup.
ros87 said:
While your idea with just backing up the unique data (which resides in both the rom partition and the factory one) might seem a good one, what happens when you screw up your NST the way that 99% of the users that asks me for help does?
If you delete/corrupt/overwrite boot, rom, factory or data, then your tiny rom backup won't help you much unless you can get a copy of the other partitions from someone else.
Click to expand...
Click to collapse
That’s where you Touch-Formatter helps me.
It’ll restore generic copy, my tiny backup makes it “personal” than.
That’s how B&N does it on factory, right?
---------- Post added at 03:43 AM ---------- Previous post was at 03:39 AM ----------
BTW: Where is factory partition?
Code:
#df
/dev: 116512K total, 0K used, 116512K available (block size 4096)
/sqlite_stmt_journals: 4096K total, 0K used, 4096K available (block size 4096)
/rom: 16116K total, 217K used, 15899K available (block size 512)
/system: 285583K total, 196911K used, 88672K available (block size 1024)
/data: 808292K total, 313252K used, 495040K available (block size 4096)
/cache: 237987K total, 8344K used, 229643K available (block size 1024)
/sdcard: 7774208K total, 113824K used, 7660384K available (block size 32768)
/media: 241947K total, 759K used, 241187K available (block size 512)
---------- Post added at 03:51 AM ---------- Previous post was at 03:43 AM ----------
GabrialDestruir said:
...in fact you could create a generic copy of the partitions blank or otherwise then use that to restore a device, have a script take the rom insert it write /boot /system etc for you and you're good to go.
Click to expand...
Click to collapse
Gabrial,
Do you think it’ll be possible to connect via adb and push back /rom partition content to restored generic image.
Providing we replaced uRamdisk and can use adb connect via USB.
Would it be sufficient?
ApokrifX said:
That’s where you Touch-Formatter helps me.
It’ll restore generic copy, my tiny backup makes it “personal” than.
That’s how B&N does it on factory, right?
---------- Post added at 03:43 AM ---------- Previous post was at 03:39 AM ----------
BTW: Where is factory partition?
Code:
#df
/dev: 116512K total, 0K used, 116512K available (block size 4096)
/sqlite_stmt_journals: 4096K total, 0K used, 4096K available (block size 4096)
/rom: 16116K total, 217K used, 15899K available (block size 512)
/system: 285583K total, 196911K used, 88672K available (block size 1024)
/data: 808292K total, 313252K used, 495040K available (block size 4096)
/cache: 237987K total, 8344K used, 229643K available (block size 1024)
/sdcard: 7774208K total, 113824K used, 7660384K available (block size 32768)
/media: 241947K total, 759K used, 241187K available (block size 512)
---------- Post added at 03:51 AM ---------- Previous post was at 03:43 AM ----------
Gabrial,
Do you think it’ll be possible to connect via adb and push back /rom partition content to restored generic image.
Providing we replaced uRamdisk and can use adb connect via USB.
Would it be sufficient?
Click to expand...
Click to collapse
It only gets mounted when running restores, not while the system is in use. But yes assuming your generic image had adb access you could push it back to /rom the issue however is that Touch-Formatter while great for returning devices to stock wouldn't fix partition issues, so if you screw up your partitions you'll need more than just this to fix it.
I will work on (when I have some time) making a blank image with just a generic /boot, with all the partitions correctly done of the NST, but empty.
This image, compressed, shouldnt occupy more than a few megabytes, then make a zip which backups the sensitive data, /rom, /factory and create another zip, which should destroy all the data on the NST, burn this empty image, restore /rom and /factory, then trigger automatically reset/restore to end up with a 100% clean nook, even if you screw it hard.
Is this what you were asking for ApokrifX? Or did I get it wrong?
Is there really unique data on /factory ? I thougt there is only some duplicate data from the rom partition.
eded333 said:
Anyway there is allready a tuto for something like that, which creates a full backup of your Nook and it should be the first step before playing with it:
http://forum.xda-developers.com/showthread.php?t=1142983
Or you can use the latest CWM: http://forum.xda-developers.com/showthread.php?t=1360994
Click to expand...
Click to collapse
Making a normal backup with CWM doesn't include the /rom and /factory partition.
mali100 said:
Making a normal backup with CWM doesn't include the /rom and /factory partition.
Click to expand...
Click to collapse
Mmmm, I thought it did a full rom backup, I'll change the advice on the previous post, thanks.
mali100 said:
Is there really unique data on /factory ? I thougt there is only some duplicate data from the rom partition.
Click to expand...
Click to collapse
Yep, factory contains a copy of the rom data which gets extracted to rom when you do a factory restore.
eded333 said:
I will work on (when I have some time) making a blank image with just a generic /boot, with all the partitions correctly done of the NST, but empty.
This image, compressed, shouldnt occupy more than a few megabytes, then make a zip which backups the sensitive data, /rom, /factory and create another zip, which should destroy all the data on the NST, burn this empty image, restore /rom and /factory, then trigger automatically reset/restore to end up with a 100% clean nook, even if you screw it hard.
Is this what you were asking for ApokrifX? Or did I get it wrong?
Click to expand...
Click to collapse
eded333,
That’s exactly what I meant!
---------- Post added at 04:01 AM ---------- Previous post was at 03:01 AM ----------
ros87 said:
Yep, factory contains a copy of the rom data which gets extracted to rom when you do a factory restore.
Click to expand...
Click to collapse
That’s all?
Anyway, where is it (factory partition)?
I.e. what is # in /dev/block/mmcblk0p#
“fdisk -l” shows nothing...
Factory, should be, if i'm not wrong /dev/block/mmcblk0p3
ApokrifX said:
That’s all?
Anyway, where is it (factory partition)?
Click to expand...
Click to collapse
No that's not all
And it's located where eded said it is.
Guys,
Need a little help here:
http://forum.xda-developers.com/showthread.php?p=22214127#post22214127
Basically, how do we change NST MAC?
Sorry, don’t know where else to ask…
WITH THE NEW CM10 PARTITION LAYOUT THIS SET OF SCRIPTS HAS NO USE ANYMORE, USE IT ONLY IF YOU KNOW WHAT YOU ARE DOING AND YOU ARE SURE YOU NEED THIS.
WHY?
Many people have complained that the new Cyanogenmod 10 partition layout reserved too little space for user application and their data. While I don't find this to be a great deal (having 100+ installed apps usually means many of them are not even used) the solution to the problem is pretty simple, so I've created this tool suite.
FAQ
WHAT DOES THOSE SCRIPTS DO?
Automatic Edition
0.4 AppMover Enabler.zip
When you flash this file if necessary your apk files will be moved to system and a new script will be put in addon.d, this will backup and restore automatically your apps every time you update your rom
This require the rom support, you can check it out HERE if your rom support this function.
0.4 AppMover Disabler.zip
This file will revert everything disabling the automatic backup and restore system and moving apps back to /data. If there is not enough space in /data the script will exit with an error without removing anything.
Developer Edition
0.3dDeveloperEdition.zip
This file contains a modified updater-script and a shell script so that when installing a rom patched with them it will move, backup and restore apks files according to necessity: if the apps are already been moved to /system it will backup them, update the rom and restore the apps; if the apps are still in /data it will update the rom and then move the apps to /system/user_app
Compact Edition
AppToggler.zip
This files moves /data/app to /system/user_app or moves them back to /data/app if you already activated this. If there is not enough space to move the files the script just revert back to a safe condition. You can check the results of the operation in /sdcard/AppMover.txt.
Since the apk files are written only during application installation/updates this should have little to none performance impact while freeing about 70% of the space in /data.
You should use this script just once to move your apk files to the bigger, slower /system partition. Use it again if you want to move them back to the faster /data partition
BackupAndRestore.zip
This files create a backup of /system/user_app to /sdcard/AppBackup.tar. If /system/user_app doesn't exists but there is /sdcard/AppBackup.tar the script assumes you have just updated your rom and restores the backup.
You should use this script before and after every rom update since the CM10 update script formats the /system partition wich now contains your apk files
Normal Edition (Discontinued)
AppMover.zip
This script moves /data/app (the folder where downloaded apk are stored) to a new directory in system (/system/user_app) and then create a symlink to that directory.
AppReverter.zip
This script moves back app to /data/app and deletes /system/user_app.
WARNING: Flash this file only if you are sure there is enough space in /data for all the apps! If not you will end with a full /data partition (and relative forcecloses) and you will lose some apps
AppBackup.zip
This script will backup all your app files in an archive in /sdcard
WARNING: Make sure you have enough space in /sdcard for all your apps.
AppRestore.zip
This script will restore the apps from the archive in /sdcard
HOW TO USE:
Automatic Edition
If you want to move your apps to /system just flash AppMover Enabler.zip, this will take care of moving the apk files and preserve them during rom updates
WARNING: During rom updates ensure you have enough space in /emmc and/or /sdcard for the backup of your apk files, if not you will lose all your apps. Ensure your rom is supported (you can check it here). Consider that rom updates will now take longer, even 3 or 4 times what it used to be depending on how many apps you have installed.
If you want to move your apps back to /data flash AppMover Disabler.zip, this will also disable the backup and restore function. If there is not enough space in /data the script will exit with an error before doing anything.
Developer Edition
Replace the rom files with the one in the archive and then flash the rom normally. Make sure you have backupapps.sh in the root of the rom archive and that updater-script is correctly replaced in /META-INF/com/google/android
Compact Edition
To move your apps to /system you have to flash AppToggler.zip. This should be the first and only time you flash this file since now the fix is applied to a directory level. Newer apps will be installed directly to /system/user_app.
BEFORE flashing/updating your rom you will have to run BackupAndRestore.zip and AFTER flashing the rom you will have to run BackupAndRestore.zip again, not doing so will remove all the apps from your phone since at every update /system dir gets formatted.
If you want to move back all your apps to /data you can just flash AppToggler.zip again.
Normal Edition (Discontinued)
To move your apps to /system you have to flash AppMover.zip. This should be the first and only time you flash this file since now the fix is applied to a directory level. Newer apps will be installed directly to /system/user_app.
BEFORE flashing/updating your rom you will have to run AppBackup.zip and AFTER flashing the rom you will have to run AppRestore.zip, not doing so will remove all the apps from your phone since at every update /system dir gets formatted. Note that AppBackup.zip and AppRestore.zip will work both with /system/user_app and with /data/app, so you can use this two file for backup and restore apps (but not their data) in any rom/occasion.
If you want to move back all your apps to /data you can flash AppRevert.zip
If you done everything good and you get a bootloop try to fix permissions in CWR
If the phone works fine but reboots when you try to install new application it is probably because the OS can't write on /system/user_app for some reason.
Try those steps and report if any of those solves the problem:
Open the terminal or use adb shell and type
Code:
su
mount -o rw,remount /system
and/or
Code:
su
chmod 0777 /data/app
chown 1000:1000 /data/app
In alternative you can try this:
feroxxx said:
[...]
i have problem with reboot issue but solved it wipe cache,dalvik,fix permission and remove google play app's update.no reboot now.
[...]
Click to expand...
Click to collapse
Try to keep in mind that this scripts completely moves /data/app to /system partition. This normally is not a problem, however if you flash something in CWR that needs to read/write something in /data/app (like fixing permissions) make sure to mount /system partition manually
This script should have little to no impact on your rom performance but you may notice some performance loss installing/updating apps.
You may use this script in your rom (integrating the backup/restore into the installation script of a rom would make life simpler for everyone) or improve it, I just ask you to give me some credit.
DISCLAIMER:
This script may contain bugs and is far from perfect. Read instruction twice and make a full nandroid backup before flashing anything, since human errors could be pretty devastating. Anyhow in case of problems I will try to help and improve the scripts but I won't be responsible for any damage to your phone or data, including -but not limited- to: bootloops, app or data loss, alien invasion and thermonuclear war.
==================================================
DOWNLOAD LINK
==================================================
CHANGELOG:
23th September 2012
V 0.5 (All versions) - Updated init.d script, renamed again as S99SystemApps to make it work on devil kernel. Now the script renames init.d scripts that doesn't start with S#. Is still possible that some scripts get executed after mine, but should be pretty rare.
V 0.5 Automatic Edition - Modified so that in case of problems the phone will reboot before deleting anything, thanks to Silentbob999 for the idea.
19th September 2012
V 0.4.2 Compact Edition - Fixed a typoes in AppToggler and BackupAndRestore.
V 0.4.2 Automatic Edition - Fixed the error you get if you try to flash the Enabler this just after formatting data (didn't test it, but it should work).
V 0.4.1 Init.d Updater - Published a flashabile file to update the init.d script so that you can use the updated one without having to toggle apps or extract it manually from the archive.
V 0.4.1 Compact Edition - Little update to AppToggler so that even if exits on error it still updates the init.d script
V 0.4.1 (All Versions) - Updated init.d script, added some fixes for problem no norma user should ever experience
17th September 2012
V 0.4 Automatic Edition - Automatic version published
V 0.4 Developer and Compact Edition - Renamed /etc/init.d/S99SystemApps in /etc/init.d/z99SystemApps, this will make less likely that some script gets executed after it and sets back /system to read only
14th September 2012
V 0.3.2 (both) - Hotfix, looks like the hotfix applied to init.d did the trick, same correction applied to remaining scripts
13th September 2012
V 0.3.1 (both) - Hotfix, seems that on some phones /system is mounted as read only. Modified init.d script to remount /system in RW if needed
V 0.3 developer edition - Almost rewritten from scratch, now there should be no problems if flashing from gingerbread and if any problem occurs the script should stop before deleting anything. Completely rewritten log system. Temporary apk backup will now be placed in /data /emmc or /sdcard, according to where there is enough space. Added file in init.d that helps preventing corruptions, hopefully system reboots when new applications are installed are gone.
V 0.3 compact edition - Added a lot of space checks. The backup is now saved on /emmc, if there is not enough space there is saved on /sdcard. If there is not enough space anywhere script will now exit with error. Completely rewritten log system. Added file in init.d that helps preventing corruptions, hopefully system reboots when new applications are installed are gone.
Normal Edition - Dropped unless I get enough requests to work on it, is almost equivalent to the compact version and having to work and test 3 version instead of 2 is just time consuming.
5th September 2012
V 0.2.5 developer edition - New version to replace CM10 stock update script, intended to be used by developers in their rom
30th August 2012
V 0.1c compact edition - Initial compact edition Release
V 0.2.5 - Fixed the error where app folder was restored in /system/user_app for good
25th August 2012
V 0.2 - Fixed an error in AppBackup.zip that could lead to follow recursively the symlink of the app directory (again and again and again..)
22th August 2012
V 0.1 - Initial Release
Sounds good. Thanks.
It would be better if we can choose the apps to be removed. Thus an app is needed, I think.
what's the difference with titanium backup?
dongfangri said:
Sounds good. Thanks.
It would be better if we can choose the apps to be removed. Thus an app is needed, I think.
Click to expand...
Click to collapse
You are right, but yhea... without an app would be pretty hard to setup the script. Maybe I could make so that moving apps with root explorer to another dir will trigger a script in init.d to create the symlink, but I think it doesn't make much sense since the performance loss of apk on /system is near to 0 (CM9 and all the rom before that had apks on the partition we now use for /system)
forziere said:
what's the difference with titanium backup?
Click to expand...
Click to collapse
It's not intended to be a backing up tool (even if at some degree works for app backup/restore) but just to move ALL apks in /system where there is a lot of unused free space. You can do it pretty easily by hand if you know some basic linux commands but is still more complex/time consuming than using an automated script like this
Hey, thanks, it's that I was loonking for, works great on MIUIV4 Jelly Bean by Andy Thomson !
Great idea
If i will flash the cm10, i will use your scripts
It's a great idea, but then the app work very well from system/user_app?
esticbo said:
It's a great idea, but then the app work very well from system/user_app?
Click to expand...
Click to collapse
I've published this set of scripts also to get some feedback. Personally I can't find any problem nor performance differences (except the fact that before I had 40mb free in /data and now there are 300) between having apk in /data or in /system but I guess different people with different phones may have different perceptions and results.
By the way my phone is pretty old and it lagged a lot before Pawitp introduced the new memory layout, so I guess I have the old, slower, memory. Fact is I read somewhere (on the CM10 thread I think) that old memory is slow just in writing operations and apk files are written just during installation/update.
As soon as I get some more feedback, I will update the OP with this informations, but before this I have to know if the script can create problems or slowdowns of any sort.
This sounds like a really good idea. Does this do the equivalent of Wendigogo's script by moving the lib files to the slower partition only? Or does it move more than just the lib files?
Vertron said:
This sounds like a really good idea. Does this do the equivalent of Wendigogo's script by moving the lib files to the slower partition only? Or does it move more than just the lib files?
Click to expand...
Click to collapse
It's /data/app that is moved so it's only apks.
Updated with a bugfix to the AppBackup.zip file, if anyone is using this is way better to update
Vertron said:
This sounds like a really good idea. Does this do the equivalent of Wendigogo's script by moving the lib files to the slower partition only? Or does it move more than just the lib files?
Click to expand...
Click to collapse
It's not like "my" datafix because CM move all /data to the speedy partition (and increase its size to 420Mo).
I've made something equivalent on my phone to move apk (on /data/app) to the /system partition. And I brake my CM when upgrading it cause installation process format /system and I forgot to backup my apks.
The best solution was to create a specific /data partition and use the speedy partition for /datadata (as in CM9/7) but pawitp's don't want to do that cause the partition layout will be SGS specific and CM is NOT an SGS rom...
For now this is the best solution ( do you backup users:groups a specific rights for each app?).
Bad news for those having lots of big apps...
Envoyé depuis mon GT-I9000 avec Tapatalk
Wendigogo said:
It's not like "my" datafix because CM move all /data to the speedy partition (and increase its size to 420Mo).
I've made something equivalent on my phone to move apk (on /data/app) to the /system partition. And I brake my CM when upgrading it cause installation process format /system and I forgot to backup my apks.
The best solution was to create a specific /data partition and use the speedy partition for /datadata (as in CM9/7) but pawitp's don't want to do that cause the partition layout will be SGS specific and CM is NOT an SGS rom...
For now this is the best solution ( do you backup users:groups a specific rights for each app?).
Bad news for those having lots of big apps...
Envoyé depuis mon GT-I9000 avec Tapatalk
Click to expand...
Click to collapse
DerTeufel1980 is using a different partition for his Helly Bean rom that has a /data and /datadata partition, so your datafix script should work for his rom at least.
Hopefully other roms will use DerTeufel1980's layout instead as they don't have the same limitations as CM10.
Happy to report this fix has been working perfectly for me on CM10. Thanks so much!
Kino87 said:
WHY?
Many people have complained that the new Cyanogenmod 10 partition layout reserved too little space for user application and their data. While I don't find this to be a great deal (having 100+ installed apps usually means many of them are not even used) the solution to the problem is pretty simple, so I've created this tool suite.
WHAT DOES THOSE SCRIPTS DO?
AppMover.zip
This script moves /data/app (the folder where downloaded apk are stored) to a new directory in system (/system/user_app) and then create a symlink to that directory.
AppReverter.zip
This script moves back app to /data/app and deletes /system/user_app.
WARNING: Flash this file only if you are sure there is enough space in /data for all the apps! If not you will end with a full /data partition (and relative forcecloses) and you will lose some apps
AppBackup.zip
This script will backup all your app files in an archive in /sdcard
WARNING: Make sure you have enough space in /sdcard for all your apps.
AppRestore.zip
This script will restore the apps from the archive in /sdcard
HOW TO USE:
To move your apps to /system you have to flash AppMover.zip. This should be the first and only time you flash this file since now the fix is applied to a directory level. Newer apps will be installed directly to /system/user_app.
BEFORE flashing/updating your rom you will have to run AppBackup.zip and AFTER flashing the rom you will have to run AppRestore.zip, not doing so will remove all the apps from your phone since at every update /system dir gets formatted. Note that AppBackup.zip and AppRestore.zip will work both with /system/user_app and with /data/app, so you can use this two file for backup and restore apps (but not their data) in any rom/occasion.
If you want to move back all your apps to /data you can flash AppRevert.zip
If you done everything good and you get a bootloop try to fix permissions in CWR
This script should have little to no impact on your rom performance but you may notice some performance loss installing/updating apps.
You may use this script in your rom (integrating the backup/restore into the installation script of a rom would make life simpler for everyone) or improve it, I just ask you to give me some credit.
DISCLAIMER:
This script may contain bugs and is far from perfect. Read instruction twice and make a full nandroid backup before flashing anything, since human errors could be pretty devastating. Anyhow in case of problems I will try to help and improve the scripts but I won't be responsible for any damage to your phone or data, including -but not limited- to: bootloops, app or data loss, alien invasion and thermonuclear war.
==================================================
DOWNLOAD LINK
==================================================
CHANGELOG:
V 0.2 - Fixed an error in AppBackup.zip that could lead to follow recursively the symlink of the app directory (again and again and again..)
V 0.1 - Initial Release
Click to expand...
Click to collapse
Errors found in AppRestore.zip. The script moves the fold /data/app into /system/user_app. It should be all apks in /data/app, isn't it?
zhuzf said:
Errors found in AppRestore.zip. The script moves the fold /data/app into /system/user_app. It should be all apks in /data/app, isn't it?
Click to expand...
Click to collapse
Depends, AppRestore.zip is used to restore the backup created with AppBackup.zip.
AppBackup.zip creates a .tar file that includes the path from the root (so if you have your apps in /data/app you will have those two directorys in the .tar, otherwise you will have /system/user_app). At the restore time the .tar is simply extracted to the root.
Maybe you are confusing AppRestore (used to restore backups) with AppRevert (used to move back apps in /data/app), but still... it does what it should do (I think).
Soon I will release a 0.3 version that aggregate AppMover and AppReverter in a single package that toggles the place where apps are stored and aggregate AppBackup and AppRestore so that if it finds /system/user_app it will create a backup and if it doesn't find it it will restore it (bringing down the number of zips from 4 to 2, but the operations you have to do remains the same). Less chances to human errors and more to script bugs, so if something happens you can blame it on me
Right now I'm thinking to a complete rework with a couple of alternatives since I think this suite is a little bit impractical:
- create something that changes the partition layout splitting /system in a 512mb partition for /system and a 1536mb partition for /data/app... Still I'd prefear to find some alternative since this solution could create pretty big problems if something goes wrong and it won't have native support in the roms/kernels (wich means you would still have to flash a file every time you update the rom to tell it how to manage the partitions and I'm not really shure what would happen when the CM updater script tries to format system and it finds is smaller than intendend, so it may be impossible to do).
- Create an alternative update script that replaces the one in the CM10 zip and does what I wrote above (you would have to modify the CM10 zip every time, but it would be as simple as drag and drop one file in it).
- As alternative to the the repartitioning create an image file of an ext4 partition and mount it runtime (like we did with One Click Lagfix a couple of years ago). It should be easy to customize the zip so that you can chose where to create this file and how big it has be so that you can place it in /system but also in /sdcard or in /emmc. Still... you will have to flash something that teaches how to handle it to the rom every time you update it and if you put in /system you will still have to backup and restore it every damn time (so I guess is pretty useless).
To be honest I don't think that altering the partition layout without official support in the rom is a practical solution since I think negative aspects are way bigger than positive ones but I still think this solution is quite annoying if you update your rom often as I do, so if anyone has suggestions they are welcome.
By the way while I can see the actual rom partitioning has some serius limitations but I understand the reasons behind Pawitp decisions and I hope we won't get different partition layouts on different roms (that will just be a mess e we will end up with different version of kernels ad patches.. We need no more fragmentation than we already have with our device being 2 years old and having roms starting from 2.1 to the actual 4.1.1)
Kino87 said:
- create something that changes the partition layout splitting /system in a 512mb partition for /system and a 1536mb partition for /data/app... Still I'd prefear to find some alternative since this solution could create pretty big problems if something goes wrong and it won't have native support in the roms/kernels (wich means you would still have to flash a file every time you update the rom to tell it how to manage the partitions and I'm not really shure what would happen when the CM updater script tries to format system and it finds is smaller than intendend, so it may be impossible to do).
- Create an alternative update script that replaces the one in the CM10 zip and does what I wrote above (you would have to modify the CM10 zip every time, but it would be as simple as drag and drop one file in it)
Click to expand...
Click to collapse
That looks like the best solution imo. Changing the update script on each rom before you update it. I assume this will work on all roms, not just CM10?
I assume that will make the partition layout similar to DerTeufel1980's new layout?
I thought of a hopefully good idea that would allow you to update nightly roms. If it is possible and someone is willing to develop it.
For this to work you'll have to create an ext4 partition on an external sdcard of about 700mb.
Basically there will be 4 scripts, 1 of them to move /data/app to /system/app with a symlink. One for simply moving it back to /data/app if wanted. Then the other 2 scripts is to move /app to the sdcard partition when you want to update a nightly.
So my idea is; you install the rom for the first time, then run the 1st script to move /data/app to /system/app.
If you want to update the rom. Run a second script which moves /system/app to the external sdcard partition. Then flash the nightly rom as normal. Then install a 3rd script which moves /app from the external sdcard partition back to system/app.
The 4th script is to simply move everything back to /data/app if wanted.
The only downside to this is losing some space from your external sdcard. But it's worth it imo for having alot more storage space and having the ability to update nightly roms.
Do you think this is a feasible idea, or will updating the rom break the symlink?
Vertron said:
I thought of a hopefully good idea that would allow you to update nightly roms. If it is possible and someone is willing to develop it.
For this to work you'll have to create an ext4 partition on an external sdcard of about 700mb.
Basically there will be 4 scripts, 1 of them to move /data/app to /system/app with a symlink. One for simply moving it back to /data/app if wanted. Then the other 2 scripts is to move /app to the sdcard partition when you want to update a nightly.
So my idea is; you install the rom for the first time, then run the 1st script to move /data/app to /system/app.
If you want to update the rom. Run a second script which moves /system/app to the external sdcard partition. Then flash the nightly rom as normal. Then install a 3rd script which moves /app from the external sdcard partition back to system/app.
The 4th script is to simply move everything back to /data/app if wanted.
The only downside to this is losing some space from your external sdcard. But it's worth it imo for having alot more storage space and having the ability to update nightly roms.
Do you think this is a feasible idea, or will updating the rom break the symlink?
Click to expand...
Click to collapse
This is how it works already.. well.. almost.
The Backup and Restore scripts do exactly what you want to do on an external partition (the only difference is that they don't copy the apk on an ext4 partition but they store them in a tar archive on /sdcard that preserve users and permissions regardless of the filesystem in use).
Would make a little more sense to use directly an ext4 partition on the sdcard or external sdcard since it would avoid you the trouble to backup your apps every time you update the rom (but then you will still have to flash a file at every update that tells to mount this external partition) but even then... I'm not fond of altering the partition layout at all even if doing it on /sdcard or /emmc would make it pretty easy to restore in case of problems.
By the way: I've finished the compact version of the suite (0.1c) and fixed a couple of bugs in the old version. Is actually online BUT IS NOT TESTED IN ANY WAY. Don't use it until I update the OP and even then do a nandroid backup before using it, it may be pretty buggy.
Hopefully if there are no bugs in a couple of hours of test I will report back
If your apps are backed up by using AppBackup.zip and you flash a updated rom, do you have to flash AppRestore.zip before the device boots with the new rom or can you let it boot then turn it off and run the script in recovery after?
Hi
Let's say we have tablet with allwinner a20 but there are two versions of MB(let's call it first MB and second MB). They use different firmware, when you flash wrong one device is booting but lcd is black(only backlight). I have access to stock firmware but only for first version of MB. So I tried to pull firmware from working device. What I did(in short):
1. Factory data reset.
2. Dump bootloader, boot, env, system, recovery partitions using dd if=nandX of=nanaX.img
3. Unpack stock firmware with imgRePacker.
4. Replace bootloader.fex, boot.fex, env.fex, system.fex, recovery.fex with files from step 2.
5. Mount bootloader partition and make copy of script.bin.
6. Update boot1 and boot2 files using update_boot0 and update_boot1 from SDK.
7. Second MB have one extra partition (called private) so I edited sys_partition.fex and generated sunxi_mbr.fex & dlinfo.fex files with update_mbr.
8. Pack modified firmware to img file.
Device booted successfully after flashing my firmware with phoenixsuit, everything worked, but when i restarted, tablet was stuck in bootloop. I tried to look at logcat output, it looks like it cannot create dalvik-cache directory on /data partition. Strange thing, because all required folders are created on /data partition at first boot, including dalvik-cache, they just dissappear after reboot. Wipe data from recovery doesn't help, I need to do reflash using phoenixsuit, but again, first boot OK and then device is bootlooping.
I also tried flashing my firmware on another tablet but I clicked No in "Does mandatory format?" window, tablet was stuck in bootloop with same errors about dalvik-cache directory.
When I try to make dalvik-cache directory manually using ADB it gives me some I/O error, but I can create folders with different names on /data partition without problems.
I don't have access to device right now, I will post logcat asap.
Another strange thing, on second MB with stock firmware there is 4,07GB of internal sd, but when I flash my firmware it grows to 4,56GB. It's almost 500MB Output of cat /proc/partitions is same(only size of last partition(internal sd) is different).
I will try to dump /data partition and add it to img file but it won't problably work. I'm also looking for a way do dump original MBR and boot0/boot1 from nand, in /dev/block I don't have device that represents full nand, only partitions(nanda, nandb, etc).
I have access to many tablets that I can play with, I bricked 2 so far
I don't know if it's right place to post such problems but I hope someone will be able to help
MultiSystem is a powerful tool for locked- and unlocked-bootloader Android devices with many features that at least includes the following:
Keeps stock system partition safe/rooted
Permenant root survival with proper use
MultiROM support via virtual ROMs
Unlimited number of virtual ROMs
Booting options to choose stock, primary, or secondary virtual ROM
Any of the virtual ROMs can work as a recovery replacement
Flashing multiple ROMs at the same time without a reboot
Ability to create/install ROMs on Linux to microSD card
Great performance & battery life on virtual ROMs
Recovery solution to install ROMs or Mods
Easy upgrade to newer versions of Android
Ability to safely apply OTA updates to virtual system
Permissive SELinux and other kernel tweaks
Safe flashing that doesn't trip KNOX flag on Samsung devices
Wrapper script runs via ADB or a Terminal Emulator on device
APK to manage all MultiSystem functions with a nice UI and extra options
Management for the best performance & user experience
Support for all Android devices with microSD card
Portability to almost all devices
Compatibility with all Android versions
Click to expand...
Click to collapse
Q&A
What is the concept behind MultiSystem?
It runs virtual Android ROMs on microSD, like booting multiple systems on a PC from different partitions/disks. So, your stock system partition is kept safe/rooted. It won't affect performance or anything (might even be better on the virtual system if you've high quality microSD & the device supports its speed). Also, you can freely modify any of the virtual systems & in the worst case, reboot the safe stock system or another working virtual system to recover. So, no root loss or potential damage to the original device partitions.
Click to expand...
Click to collapse
Is it a recovery or an APK tool?
It's a shell script that hijacks system at early boot & force Android to boot from the stock system partition or a virtual system IMG & an APK that manages all booting options, virtual ROMs, and works as a recovery replacement + extra features...
Click to expand...
Click to collapse
Does it work as a recovery replacement?
It IS a POWERFUL recovery replacement. You can do whatever you do in recovery with the APK. HOW? recovery does its magic b/c it doesn't depend on the system & has its own kernel/ramdisk. In MultiSystem, you can boot a virtual ROM from extSD that sure doesn't depend on stock system partition or any of the other virtual ROMs (it does depend on the kernel, which you can't flash on locked devcies anyway). Hence, install, backup, restore, ... & all recovery functions are all possible +++ more features since you're running a full ROM not just a recovery ramdisk like Safestrap.
Bottom Line: I think it's the best & most convenient recovery replacement ever for locked devices & it can also attract unlocked devices for the powerful features, MultiROM, and recovery from within ROM.
Click to expand...
Click to collapse
Can I use FlashFire along with MultiSystem?
Yes. MultiSystem is compatible with FlashFire & fully supports it on stock & virtual ROMs. So, you can use both/any of them for flashing to either a stock or virtual ROM. However, it's recommended to use MultiSystem when flashing to the stock system partition (shouldn't be needed anyway since you can always be safe & flash to your old/new virtual ROMs).
Click to expand...
Click to collapse
Does MultiSystem require FlashFire?
No, MultiSystem doesn't require FlashFire. They're fully combatible though.
Click to expand...
Click to collapse
Would the virtual ROM we install be exactly the one in the stock slot?
In MultiSystem APK, you can create a virtual ROM from stock system, a copy from other virtual ROM, a new IMG, a dev-provided ROM, a flashable .ZIP, ... etc. Literally, your virtual ROMs can be any stock or custom ROM that's compatible with your firmware/kernel.
Click to expand...
Click to collapse
How can it run virtual ROMs from external microSD card?
External MicroSD will be formated into 2 partitions:
exFAT or FAT32 for the 1st partition (your new external storage)
EXT4 for the 2nd partition (your MultiSystem partition)
It'll hijack the system & boot a virtual system from the 2nd partition. The 1st partition will be automatically detected as your extSD.
Click to expand...
Click to collapse
Can I run unrooted virtual ROM for work apps or any other reason?
Yes. You can add unrooted virtual ROM & reboot to it via MultiSystem APK.
Click to expand...
Click to collapse
How do you boot back into a different ROM?
MultiSystem APK manages all functions including ROM activation & reboot to current system, another stock/virtual system, download mode, recovery, ... etc.
Click to expand...
Click to collapse
Will it be OK to still store media like movies/photos/music to extSD?
100% OK; That's my setup a few months ago. 2 virtual ROMs in the SECOND extSD partition in EXT4 format while all personal data are stored on the FIRST extSD partition in exFAT or FAT32 format... TWO COMPLETELY DIFFERET PARTITIONS.
Click to expand...
Click to collapse
How much space are we going to have for virtual ROMs?
The size of the 2nd partition is optional (> 4GB) for your ROMs, but here is an estimated sizes:
1 Virtual ROM Uncompressed = ~2.7 GB ---> ready for running
1 Virtual ROM Compressed = ~1.5 GB ---> for full ROM backups
I'd say better allocate 4 GB for each ROM you plan to run. If you just need one virtual ROM to keep stock system safe, 4 GB 2nd extSD partition is enough; The remaining space is allocated for the 1st extSD partition as your external storage.
For me, I run Linux too from extSD via MultiSystem. So, I've 64 GB extSD card with two partitions 32 GB each.
Click to expand...
Click to collapse
Can I clear up space on an existing SD card and partition it while full or will the entire card need to be wiped and partitioned from scratch?
You need to backup all your files; it'll be wiped & repartitioned.
Click to expand...
Click to collapse
How can I swap microSD cards & be able to run virtual ROMs?
You can swap microSD cards as you wish provided that the device is powered off; don't remove the microSD card when running a virtual ROM. If the new microSD card doesn't include a 2nd parition of available virtual ROMs, the device will boot directly to the stock system.
Click to expand...
Click to collapse
Is there a specific sd card you recommended for this?
I personally have two microSD cards:
SanDisk Extreme Plus 64GB (Up to 80MB/s read speed)
Samsung 64GB PRO (Up to 90MB/s read speed)
You don't have to change your microSD card for MultiSystem; any card you use on your device should work just fine. The need for more speed is relevant when the device supports that speed & if you're going to buy a new card anyway that you may use with a newer device later.
Click to expand...
Click to collapse
Can I copy virtual ROMs to a new microSD card?
Yes. I'll add a feature for swapping microSD cards so that you can backup/restore virtual ROMs from/to the current extSD to/from internal storage as follows:
power off device
use MultiSystem APK to backup your virtual ROMs
insert the new properly formatted microSD,
power on device (it'll boot to stock system)
use MultiSystem APK to restore your virtual ROMs
use MultiSystem APK to activate one of your virtual ROMs
use MultiSystem APK to reboot to any of your ROMs
Click to expand...
Click to collapse
What about other data/cache partitions and internal storage?
Only system img's are in the extSD. All ROMs share all other partitions. This substantially improves the performance & you won't notice any difference between your stock & virtual ROMs. The reason for performance improvement is that EXT4 loop devices are very fast in reading but not in writing. Your system partition is read-only while data (for example) is read write & cache IMGs cause problems like Safestrap issues on ROM slots. Also, you don't have to worry about switching data/settings between ROMs (they're shared), but you just need to regularly backup your important data (which is healthy anyway).
Click to expand...
Click to collapse
Can your elaborate where data is stored?
The userdata partition is also shared; so, you'll have access to all your FULL storage partitions & all apps/data similarly on either stock or virtual ROMs. This also solves the Safestrap issue of having less storage on ROM slots...
Click to expand...
Click to collapse
Will mSDcard incur a significant performance penalty on some devices?
there's no diffrerence between virtual & stock ROMs in terms of performance & battery life. The reason is simple: loop devices associated with the READ-ONLY system IMG mounted from EXT4 partition using a high-quality microSD card IS very fast more than enough.
The read speed is faster than the device can operate anyway + the exact same device should perform on the lowest speed when reading/writing from/to the FAT/FAT32/ExFAT extSD card (where you store your files or even move apps!!!) anyway, which is much slower than the read speed of a loop device mounted from EXT4 partition.
That's why data partition is shared for many reasons, including the poor READ/WRITE performance.
Click to expand...
Click to collapse
If virtual systems are read only, how do we modify them? Do we have to boot to another multisystem rom to modify a virtual rom?
The stock system partition is mounted by default read only & so are the virtual systems. To modify a stock/virtual system, the MultiSystem APK remounts them read/write. You can modify the currently running virtual system, copy it & modify the copy, modify another stock/virtual system.
Click to expand...
Click to collapse
How is a corrupted virtual rom handled? Does it see it's bad and default to stock system?
At early boot, MultiSystem checks for the microSD & active virtual ROM to boot it. There's a boot menu that gives you options to select a stock/virtual system, but it crashes on LP. I'm debugging it, but all functions won't be affected if I removed it. To fail safe, you can remove the microSD card to boot to stock system & restore/repair your virtual ROMs.
UPDATE1: MultiSystem v1.0.1 now allows you to also switch to stock system on boot to repair corrupted virtual IMGs or any other reasons. More options will be added during boot to ultimately select another virtual system if the active IMG is not booting normally (e.g., bootloop after applying a mod or flashing a bad .ZIP).
UPDATE2: Now, on boot, you can choose from two primary/secondary virtual ROM or stock ROM. Flashing multiple ROMs at the same time without a reboot is now possible.
Click to expand...
Click to collapse
How to check if an IMG is corrupted using MultiSystem status?
Code:
Current System IMG: Test_Rom.img
Current System DEV: [B][COLOR="Red"]/dev/block/mmcblk0p23[/COLOR][/B]
When you see "/dev/block/mmcblk0p23"; it's the original system partition; so MultiSystem failed to boot Test_Rom.img, but it should be your current system.
So, the check is simple based on "Current System Device":
/dev/block/mmcblk0p23 = Stock System Partition
/dev/block/loop0 = Virtual System IMG
Note: The block device number (mmcblk0p23) may vary per device & per variant !
Click to expand...
Click to collapse
Does android do any maintenance whatsoever on stored data within /data or external sd? So if I have an app installed on 1 system and not on another system will android see it and clear the data?
No, all storage partitions are shared between ROMs. If you installed an app, it'll be availabe for all of them. Since on locked devcies we're limited to stock manufacturer-based ROMs, this makes the switch between ROMs very convinient (you don't have to worry about your changes/data/setup & storage space on the another ROM; all ROMs share everything except system). However, you should make regular backups in case a virtual ROM (probably with unsafe mods) results in bootloop due to your user data. In this case, it's safe to wipe data & selectively restore apps/data from backup(s). Another advantage of sharing all storage partitions is that your messages/emails/etc received on a virtual ROM are immediated synced (actually shared) to the other ROMs.
Click to expand...
Click to collapse
Will anything like Xposed modify the virtual ROM system IMG as opposed to the stock system IMG?
When you run a Virtual System, everything incldung kernel & apps are hijacked to speak to it as the original system.
Click to expand...
Click to collapse
Can we install AOSP ROMs on locked devices?
You can only install stock/manufacturer-based ROMs on locked devices while unlocked devices can use kexec or flash the required kernel to boot any AOSP/Stock ROMs. I've got a Note 4 Developer Edition & a lot of development is planned to go there (thanks to the unlocked bootloader!) More devices will get supported including unlocked TMO & international variants after adding more features untilizing the unlocked bootloader with kexec'd kernels.
Click to expand...
Click to collapse
Are there limitations to the combinations of ROMs that can be loaded on the "stock" and "virtual" slots? Can you mix KK and LP?
Yes, if they can run on the same kernel. LP won't run on KK kernels & so, you'd have to upgrade the firmware anyway. As for running mixed compatible Android versions, this is possible but your'd have to backup your data before switching ROMs; if it cause no issues, enjoy smooth switch & if it doesn't, do factory reset in recovery & restore your data backup. Backups via MultiSystem are painless.
Click to expand...
Click to collapse
Are applications installed once for each ROM slot that has that applicaiton installed, or can I share a game across ROMs (for instance?)
Everything is shared between ROMs, which is very good for storage & for easy switching. Just make regular backups of your sensitive data.
Click to expand...
Click to collapse
How there are no performance hits while internal storage memory was much faster than any microSD technology?
Read speeds from microSD is very fast compared to write speeds & since virtual ROMs are actually a virtual read-only systems (hence, MultiSystem), they provide a high performance. Moreover, again, read speeds from EXT4 loop devices are higher compared to physical partitions. They're very bad in writing, which we don't need for the read-only "system".
Click to expand...
Click to collapse
Is there a preferred "daily driver" ROM that should be installed in the stock slot?
Uses a stock ODEXED ROM on stock slot for better stability!
Click to expand...
Click to collapse
Is it based off of Safestrap?
Short answer NO. I've been working on MultiSystem & Safestrap for ~7 months. Earlier versions of MultiSystem (called, JasmineREC) was based on Safestrap, but it failed to support newer versions of Android mainly due to TWRP changes in the graphics/UI libraries that cause segmentation fault & the stock kernel framebuffer issues. Then, I decided to find another solution. However, the basic idea of system hijack is powered by Safestrap (or 2nd-init recoveries in general) & all the work done by @Hashcode is GREATLY appreciated.
Click to expand...
Click to collapse
How can it overwrite system files while running?
MultiSystem allows you to install safe mod's or a ROM in full or OTA-like update. It's strongly recommended to install .ZIP files NOT to the current system, b/c some files can not be overwritten while running. So, you can use backup function to copy the current system & install to the new img or any of your other virtual systems. You'll have several options to activate a virtual img & reboot directly to stock system, any virtual img you've activated, quick reboot, Download/bootloader, recovery,... etc.
Click to expand...
Click to collapse
How would I benefit from it if I'm only running Stock ROM or would there be no point for me to install it?
If you run a ROM on stock system, you're vulnerable to root loss unless/untill a new rooting method for LP comes out. MultiSystem gives you the option to run safe-to-mod virtual ROMs + recovery replacement + extra features.
Click to expand...
Click to collapse
Is there a way to convert a normal ROM .ZIP into MultiSystem .IMG?
Create or copy any of your IMGs, activate it & reboot to the active IMG! Then, use FlashFire to flash the ZIP file. However, the updater-script should be safe/compatible. Some devs mount the phyical partition, which will redirect everything to it!!
For example:
Code:
mount(“ext4″, “EMMC”, “/dev/block/mmcblk0p23″, “/system”);
will mount the original system partition; while
Code:
run_program("/sbin/mount", "-t", "auto", "/system");
will mount the current system (stock or virtual). This is recommended/safe.
Click to expand...
Click to collapse
Would a KitKat ROM work with multisystem even though my stock is Lollipop?
Any ROM requires a compatible kernel & modem. So, running KK ROMs requires flashing KK firmware (namely, kernel & modem). This may work with MultiSystem on other devices, especially if the bootlpoader is unlocked. For example, I plan to add features for Note 4 DevED to allow different Android versions (including AOSP, manufacturer-based, & probably Linux systems) by utilizing kernel swapping or execution.
Click to expand...
Click to collapse
When MultiSystem comes out will it be open sourced?
Most probably, haven't decided yet!
Anyway, here's the repository on GitHub: https://github.com/hsbadr/MultiSystem
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Video Tutorials
A quick preview of MultiSystem v1.0 tested on Lollipop for VZW Note 3. The video has been captured on a stable virtual ROM of JasmineROM v5.0.1. It's FULLY compatible with FlashFire on virtual/stock systems. More devices will get supported as well, after required testing.
Facebook: https://www.facebook.com/hsbadr/videos/vb.331488823689599/428178174020663
How to check if you are running a Stock/Virtual System?
There're many ways to check whether you're running a Stock or Virtual system. MultiSystem app should include this simple check at some point. That's important to avoint ruining the Stock system & keep it safe. To make it clear to NOOBZ & anyone who's requesting "another" proof even though I owe hime nothing. Very weird!
Anyway, BusyBox mountpoint applet can print the current block/device mounted to /system mountpoint by running the following command:
Code:
busybox mountpoint -n /system
The stock system is mounts the original system partition:
Code:
[B][COLOR="Red"]/dev/block/mmcblk0p23[/COLOR][/B]
while the virtual system mounts a loop device associated with a system IMG:
Code:
[B][COLOR="Blue"]/dev/block/loop0[/COLOR][/B]
Here're two videos for both stock & virtual systems...
UPDATE:
Now, you could run the following command to print the current system (stock or virtual) and the system device (physical partition or loop device):
Code:
MultiSystem status
Note: The block device number (mmcblk0p23) may vary per device & per variant !
How to repartition microSD card for MultiSystem?
You can use any tool/program for partitioning on Android, Linux, Mac, or Windows. For example, MiniTool Partition Wizard is a good partitioning tool for Windows. So, let's use it for this task. Simply, you need to follow this PDF tutorial (thanks to @carl1961). In sum:
Step 1: delete old partitions on SD card
Step 2: create FAT32 PRIMARY partition
Step 3: create EXT4 PRIMARY partition
Then, apply changes (note that the program UI may get changed in newer versions).
Notes:
This partitioning tutorial doesn't create PRIMARY partitions (it creates logical partitions). So, you need to change "Create As" from "Logical" to "Primary" when creatig a partition.
The sizes of the two partitions are arbitrary depending on number of ROMs you plan to install on the 2nd EXT4 partition.
The 1st partition (check size) is automatically detected as your external storage
In Terminal Emulator or ADB shell, check the existence of the two partitions by running the following command (in red):
Code:
[email protected]:/ # [COLOR="Red"]ls -l /dev/block/platform/msm_sdcc.3/[/COLOR]
drwxr-xr-x root root 2015-05-02 21:08 by-num
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1 -> /dev/block/mmcblk1
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1p1 -> [COLOR="Blue"]/dev/block/mmcblk1p1[/COLOR]
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1p2 -> [COLOR="Blue"]/dev/block/mmcblk1p2[/COLOR]
/dev/block/mmcblk1p1 is mounted by Android as your external storage.
/dev/block/mmcblk1p2 is NOT mounted & will be your MultiSystem partition.
Click to expand...
Click to collapse
How to check microSD card partitions for MultiSystem?
You need to correctly repartition microSD card into two partitions:
exFAT or FAT32 for the 1st partition (your new external storage)
EXT4 for the 2nd partition (your MultiSystem partition)
Use the directions in this post!
You should check your 2nd SD partition in EXT4 format mounted to /MultiSystem:
check that the /MultiSystem directory exists after a reboot
check that the 2nd SD partition (/dev/block/mmcblk1p2) is mounted to /MultiSystem by running the following command in Terminal Emulator or ADB shell:
Code:
mount | grep /MultiSystem
The output should be:
Code:
/dev/block/mmcblk1p2 /MultiSystem ext4 rw,seclabel,relatime,data=ordered 0 0
How to check MultiSystem Installation?
The 1st thing to do after installing MultiSystem is to check the /MultiSystem directory & its contents (it shouldn't be empty!). Then, check usage by running the following commands in Terminal Emulator or ADB shell:
Code:
su
bash
MultiSystem
If it retuns "MultiSystem not found" or permission denied, try to use open MultiSystem app to Update Configurations & try again. If this does't fix it, try the following command:
Code:
/MultiSystem/bin/MultiSystem
This should work if you've MultiSystem binaries installed in (extracted to) /MultiSystem directory. If so, you can create a symlink in /system/xbin as follows:
Code:
mount -o remount,rw /system
ln -sv /MultiSystem/bin/MultiSystem /system/xbin/MultiSystem
Then, test it by running:
Code:
MultiSystem
The last thing before using it is to check the boot options: reboot & monitor the GREEN LED indicator for 3 seconds (change in the app) , which give you the following options:
Volume UP = Primary virtual ROM
Volume DOWN = Secondary virtual ROM
HOME KEY = Stock System
Pressing nothing will boot the active system: stock or primary virtual system. Sure, you should have installed one or more virtual ROMs.
Backup & restore or creating/installing a virtual ROM are easy as copy & paste: all img's will be at
Code:
/MultiSystem/img/system
To backup a virtual/stock system, you have many options:
Use create function to create from stock system
Use copy function to copy the IMG
Copy & paste with a new name
Use FlashFire (fully supported on virtual/stock ROMs)
...
If you've IMG mounting issues, run the following commands:
Code:
mount -o remount,rw /system
busybox ln -sv /proc/self/mounts /system/etc/mtab
If this doesn't help, try mounting from Terminal Emulator or ADB shell after selecting the IMG in MultiSystem app, by running the following command:
Code:
MultiSystem mount virtual
Mind Boggling
hsbadr said:
MultiSystem is a powerful tool for locked- and unlocked-bootloader Android devices with many features that at least includes the following:
Click to expand...
Click to collapse
Had to login just to thank you.
Awesome.
Sent from my SM-N910V DE
Remember: Read twice flash once
I decided to go ahead and try this. Using the latest version it appears to install Multisystem with no problem. Then when I try to flash a rom it says: "file selected: null" when I try to select the rom. So I tried FlashFire and ended up flashing on top of my system instead of the virtual rom partition. How do I tell flashfire where to install to?
MultiSystem Video Tutorial
Thanks To: @Tomsgt , aka RootJunky
Don't forget to subscribe & like the video to show appreciation of his great effort & time spent in making the video :highfive::good:
stueycaster said:
I decided to go ahead and try this. Using the latest version it appears to install Multisystem with no problem. Then when I try to flash a rom it says: "file selected: null" when I try to select the rom. So I tried FlashFire and ended up flashing on top of my system instead of the virtual rom partition. How do I tell flashfire where to install to?
Click to expand...
Click to collapse
Will explain this very soon
hsbadr said:
Will explain this very soon
Click to expand...
Click to collapse
Thanks man. You're awesome as usual. ?
Sent from my SM-N910V using Tapatalk
hsbadr said:
Thanks To: @Tomsgt , aka RootJunky
Don't forget to subscribe & like the video to show appreciation of his great effort & time spent in making the video :highfive::good:
Click to expand...
Click to collapse
I found out I was leaving out the "Create Virtual IMG" step. But even with that it still gives me the "File selected: Null" message.
stueycaster said:
I found out I was leaving out the "Create Virtual IMG" step. But even with that it still gives me the "File selected: Null" message.
Click to expand...
Click to collapse
Update Configurations >>> Activate Virtual System >>> Select Primary IMG
hsbadr said:
Update Configurations >>> Activate Virtual System >>> Select Primary IMG
Click to expand...
Click to collapse
Ok, does this look right? It looks like I have 2 copies of the same rom on the same partition.
Sent from my SM-N910V DE
Remember: Read twice - Flash once
stueycaster said:
Ok, does this look right? It looks like I have 2 copies of the same rom on the same partition.
Click to expand...
Click to collapse
This means that IMG doesn't exist or corupted. You need to create a good IMG & activate it: Create IMG >>> wait for the LED >>> Update Configurations >>> Activate Virtual System >>> Select Primary IMG
hsbadr said:
This means that IMG doesn't exist or corupted. You need to create a good IMG & activate it: Create IMG >>> wait for the LED >>> Update Configurations >>> Activate Virtual System >>> Select Primary IMG
Click to expand...
Click to collapse
I fixed it. The problem was my ext4 partition on the sd wasn't big enough. I tried to set up exactly 4 gb but of course it came out 3.68 gb instead. So I went back and expanded it to 5.4 gb. Now the status is right.
Could I replace this virtual image with the stock rooted LP image with Root Explorer and it would work? This one was done with MoRom. I'd like to have the stock rom too.
Or could I flash the 2 part recovery flashable LP update with either MultiSystem or Flashfire without wiping system or data? If I wipe system I'll lose the MultiSystem directory right?
Update: Or should I wait for Jasmine?
Sent from my SM-N910V using XDA Free mobile app
Any chances this will work for the Note Edge before I go through all the work?
stueycaster said:
I fixed it. The problem was my ext4 partition on the sd wasn't big enough. I tried to set up exactly 4 gb but of course it came out 3.68 gb instead. So I went back and expanded it to 5.4 gb. Now the status is right.
Could I replace this virtual image with the stock rooted LP image with Root Explorer and it would work? This one was done with MoRom. I'd like to have the stock rom too.
Or could I flash the 2 part recovery flashable LP update with either MultiSystem or Flashfire without wiping system or data? If I wipe system I'll lose the MultiSystem directory right?
Update: Or should I wait for Jasmine?
Click to expand...
Click to collapse
Great! Yes, you can add virtual ROMs with any root explorer. I'd suggest to increase the EXT4 partition size & keep it for ROM or even backups (it's faster & more reliable compared to FAT32/exFAT). You can add this rooted ROM, unrooted stock ROM (for enterprise, etc), and/or wait for JasminROM.
rlkirkland said:
Any chances this will work for the Note Edge before I go through all the work?
Click to expand...
Click to collapse
Yes, but not tested yet.
hsbadr said:
Great! Yes, you can add virtual ROMs with any root explorer. I'd suggest to increase the EXT4 partition size & keep it for ROM or even backups (it's faster & more reliable compared to FAT32/exFAT). You can add this rooted ROM, unrooted stock ROM (for enterprise, etc), and/or wait for JasminROM.
Click to expand...
Click to collapse
I'm obviously doing something wrong or I've left a step out. I placed the stock rooted LP .img into the /MultiSystem/img/system file using Root Explorer. I opened MultiSystem, tapped Install MultiSystem, chose the virtual rom that I copied originally as Primary System image, the rooted LP image as secondary System Image, tapped Update Configurations, closed the MS app then rebooted. When the LED lit up I tapped the down volume rocker til the light went out. Then when it finishes booting it says it's the stock system instead of the secondary virtual image.
Update: Even when I try to choose the primary virtual image it boots the stock system.
-By following this you can can increase /system space from default 800MB to 1.2GB/2GB
-You can flash gapps on CM ROMs without insufficient space issue.
-You can flash regular MIUI ROMs too,without any issue.
Statutory warning
*Repartition can kill your phone forever if anything goes wrong,so proceed with caution (and make sure you have at least 30% battery)
*This process would format your internal sdcard,backup its contents
*I'm not responsible If your phone dies during this procedure under any circumstances beyond control
Prerequisites:
1)Redmi 1s partition script_system space 1.2GB.zip/2GB.zip
2)Parted
3)Twrp v3.0.2-1.zip
4)Download and copy all these files to external sdcard
Procedure:
1)Flash Twrp recovery(incase if aren't already using it).
2)Boot in to Twrp--->Advanced--->File manager--->Browse to the location of file "parted"--->Select "parted"--->Copy File--->/sbin.
3)Now using Twrp File manager browse /sbin--->parted--->select parted--->chmod 755.
4)You can also use "aroma file manager" instead of Twrp file manager for copying "parted" to "/sbin" and changing it's permissions to 755.
5)In Twrp flash "Redmi 1s partition script_system space 1.2GB.zip/2GB.zip" and wait for the script to finish execution(recovery will reboot automatically once this process finishes).
6)In Twrp--->Wipe--->Advanced wipe--->Mark in "Dalvik/ART Cache"__"Cache"__"System"__"Data"__"Internal Storage"--->Swipe to wipe.
7)Reboot recovery.
8)Install your ROM(don't flash gapps now).
9)Back again to Twrp start screen select "Wipe"-->Advanced wipe-->select/mark "System"-->press "Repair or change file system(notice that size hasn't increased to 1.2GB/2GB)-->Resize file system.
10)Back(though size of partition appears unchanged, its actually increased to 1.2GB)-->Back>select/mark"System"-->Repair or change file system-->Notice size of partition increased.
10)Back to Twrp start screen and flash gapps,that's it.
Reset to default partition:
1)I am also giving link for flashabe script file "Reset to default partition.zip" for restoring default partition sizes.
2)Boot in to Twrp--->Advanced--->File manager--->Browse to the location of file "parted"--->Select "parted"--->Copy File--->/sbin.
3)Now using Twrp File manager browse /sbin--->parted--->select parted--->chmod 755.
4)You can also use "aroma file manager" instead of Twrp file manage for copying "parted" to "/sbin" and changing it's permissions to 755.
5)In Twrp flash "Reset to default partition.zip" and wait for the script to finish execution(recovery will reboot automatically once this process finishes).
6)In Twrp--->Wipe--->Advanced wipe--->Mark in "Dalvik/ART Cache"__"Cache"__"System"__"Data"__"Internal Storage"--->Swipe to wipe.
7)Reboot recovery.
8)that's it you are back to default partition.
PS:
1.Need for "Resizing System partition"(step 9) comes only with CM14.1(haven't tried other CM versions or other custom roms) no need to do that if you are flasing MIUI ROMs(i,e you can skip step 9 if you are flashing MIUI ROMs)
2.If you still need more System space or want to further modify partition table(only if you know what you are doing),you can edit "update-binary" file inside the zip as per your needs.
Credits:
1)forumber2_ Samsung Galaxy S III.
2)slst_for his valuable input.
3)owaisnaim & fefifofum Twrp for redmi 1s.
Downloads:
1)parted:https://drive.google.com/folderview?id=0B6_hhjS3nx4IU05yLVc2Mk9uOEk
2)Repartition script Redmi 1s_1.2GB system space:https://drive.google.com/folderview?id=0B6_hhjS3nx4IRkJFZzAtMjZEa2s
3)Repartition script Redmi 1s_2GB system space:https://drive.google.com/folderview?id=0B6_hhjS3nx4IRXlDZUU1cEJ3Smc
4)Reset to default partition:https://drive.google.com/folderview?id=0B6_hhjS3nx4IeGtXb0liazdLWVk
5)TWRP 3.0.2-1.zip:https://drive.google.com/folderview?id=0B6_hhjS3nx4IdzFHXzdfNXVCYm8
good work mate
Great tutorial! Have a some questions:
1. After successfully doing this, If I decided to full clean wipe system, data, cache, dalvik cache, internal storage, and format data, the size will be reset? Do I need to do all the steps again?
2. If I decided to go back in default partition size I just flash that to reset all the steps? Or there will be a steps to reset all I've done?
Thank you.
Sent from my HM 1SW using Tapatalk
vhick said:
Great tutorial! Have a some questions:
1. After successfully doing this, If I decided to full clean wipe system, data, cache, dalvik cache, internal storage, and format data, the size will be reset? Do I need to do all the steps again?
2. If I decided to go back in default partition size I just flash that to reset all the steps? Or there will be a steps to reset all I've done?
Thank you.
Sent from my HM 1SW using Tapatalk
Click to expand...
Click to collapse
no you just have to go to
wipe >mark on system>click repartition
go back you can see system size 1.2gb
after doing this can i flash latest twrp ?
vhick said:
Great tutorial! Have a some questions:
1. After successfully doing this, If I decided to full clean wipe system, data, cache, dalvik cache, internal storage, and format data, the size will be reset? Do I need to do all the steps again?
2. If I decided to go back in default partition size I just flash that to reset all the steps? Or there will be a steps to reset all I've done?
Thank you.
Sent from my HM 1SW using Tapatalk
Click to expand...
Click to collapse
1.You can do all the wiping as usual, size of partition wil stay as it is and won't get reset,but if you're flashing current version of cm14.1 again you need to resize "System" partition before flashing gapps.
2.You additionally need to change "System" partition too to F2FS and than to EXT4(like you do with "Data" partition),in case you're going back to default partition.
I forgot to mention point 2 in OP,I will now add this there
vinayak.ghimire said:
after doing this can i flash latest twrp ?
Click to expand...
Click to collapse
Ya you can.
and whats the size of userdata and cache partition ?
vinayak.ghimire said:
and whats the size of userdata and cache partition ?
Click to expand...
Click to collapse
Based upon the scenario, the only concern is the system partition coz newer or update partition is too large. Cache partition is ok because it only use as a temp file partition. The userdata partition is large as internal storage because it shared as the same partition. That is the good thing at xiaomi phones, data partition is large as long as you have space in internal storage.
Sent from my HM 1SW using Tapatalk
vinayak.ghimire said:
and whats the size of userdata and cache partition ?
Click to expand...
Click to collapse
Install diskinfo app and check
Thanks for the script. It will help us a lot in now and in future also.
I know, i am asking too much. I bet we all are from developers but I will be very glad if you can provide me link of flashable file of TWRP and philz recovery 6.55.
Thanks Loads.
Anyone have checked this tutorial working ??
I checked this tutorial working fine. Thanks for this awesome tip. Here the flash able zip of twrp
Here is screenshot
apoorvpandey41 said:
I checked this tutorial working fine. Thanks for this awesome tip. Here the flash able zip of twrp
Click to expand...
Click to collapse
Thanks mate appreciated.
Thanks man works perfectly fine. Awesome tutorial.
Guys please help me:
Today morning I reparationed my Redmi 1s as the Op said. it went successful. after using for 5hours I've found an update from CM. So I updated using CM UPDATER APP. after reboot I've lost my Google play store and Google app (after updating to todays CM update using CM UPDATER APP). When I went to see the system partition size, it's size went back to the default 782mb (around 782mb, I don't remember exact size).
I checked whether it is disabled or what in apps. But I can't find there also. I tried Show system apps and reset app preferences, but nothing showed them.
I tried to get them back (play store and Google app) by resizing the partition to 1.2 gb (wipe>advanced wipe> Mark system>change or resize partition>back> checked system partition size whether 1.2gb or not>wipe cache and dalvik cache> reboot to system). But nothing worked.
So please help me in getting them back. Please exclude solution such as factory reset or flash gaggs again.
Is anybody else also facing the same issue or it's just me?:crying::crying::crying:
freeshared said:
1.You can do all the wiping as usual, size of partition wil stay as it is and won't get reset,but if you're flashing current version of cm14.1 again you need to resize "System" partition before flashing gapps.
2.You additionally need to change "System" partition too to F2FS and than to EXT4(like you do with "Data" partition),in case you're going back to default partition.
I forgot to mention point 2 in OP,I will now add this there
Click to expand...
Click to collapse
please give detailed instructions to get back to default partition as i am not anymore able to flash any rom on my device. Sometimes it strucks at patching system image unconditionally and sometimes shows error 7 in twrp. And not even being able flash using adb sideload. Please give detailed instructions to revert back to default partition
sharathe100111 said:
please give detailed instructions to get back to default partition as i am not anymore able to flash any rom on my device. Sometimes it strucks at patching system image unconditionally and sometimes shows error 7 in twrp. And not even being able flash using adb sideload. Please give detailed instructions to revert back to default partition
Click to expand...
Click to collapse
1)Detailed instructions for returning back to default partitions are given in op under the sub header "PPS", nothing more to add to it,just follow as it is.
2)I myself havent faced any issues till now iam currently on cm14.1 6-12-2016 version
3)Saw your posts on cm41.1 thread too,so you're on latest twrp
but still facing error 7,If possible post a screenshot of error 7(coz it never happed for me)
4)coming to the issue at hand,could you able to mount cache,system and data partitions.In twrp go to wipe>>advanced wipe>>select "cache">>Repair/change filesystem and see if everything(regarding partition size)is ok there.
Then do same for system and data too and check how are those partitions,if possible post screenshots.
Post your relpy as soon as possible.
freeshared said:
1)Detailed instructions for returning back to default partitions are given in op under the sub header "PPS", nothing more to add to it,just follow as it is.
2)I myself havent faced any issues till now iam currently on cm14.1 6-12-2016 version
3)Saw your posts on cm41.1 thread too,so you're on latest twrp
but still facing error 7,If possible post a screenshot of error 7(coz it never happed for me)
4)coming to the issue at hand,could you able to mount cache,system and data partitions.In twrp go to wipe>>advanced wipe>>select "cache">>Repair/change filesystem and see if everything(regarding partition size)is ok there.
Then do same for system and data too and check how are those partitions,if possible post screenshots.
Post your relpy as soon as possible.
Click to expand...
Click to collapse
Thank you brother for your reply. Now i am on miui as i am not being able to go to CM14 anymore. But i can flash CM11. (it seems i can use only kitkat).
Here are the screenshots: for MOUNT, ADVANCED WIPE, CACHE, SYSTEM, DATA. And problem struck on patching system image unconditionally