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,
I am trying to figure out ways to create a new partition additionally to the standard ones, like system, boot or data. As the title indicates, my intention is not to create an ext4 partition inside the sdcard to put apps into it, my end goal is completely different as the first sentence indicates.
Do I need to do it at build time? Or can it be done at boot time (by starting a service that uses fdisk via init.rc)? Any resources that could help me understand what needs to be done?
Thanks!
Hi,
Where can I find an explanation of the Nexus 5X partitions, and which of those are changed during use and are a good idea to back up?
Coming from Nexus 7 3G 2012, I see the 5X has quite a few more partitions. I've searched this site and the wider Internet for their purpose but have come up only with a parted listing without explanation.
E.g. what typically goes into "vendor", why do "system" and "vendor" have "... image" counterparts, and what exactly goes into the crucial "EFS" partition?
Following from that, it seems that an unlocked but otherwise unmodified device can be fully restored from the factory image and a data partition backup (apart from perhaps needing to restore EFS in extreme cases), right?
Or are there other partitions that may get modified during normal use and need to be backed up too?
I've come across one of the answers.
It seems the vendor partition contains the platform-specific drivers/binaries that were previously stored in the /system partition: https://plus.google.com/+JeanBaptisteQueru/posts/akHWypRNEn3.
...and according to this the "... image" selections aren't device partitions, but TWRP options to add fastboot flashable image backups of the corresponding partitions.
fvisagie said:
what exactly goes into the crucial "EFS" partition?
Click to expand...
Click to collapse
Continuing the monologue, although I haven't found a definitive source, most authorative-sounding ones like this one and this one claim it contains device-specific IDs, mostly connectivity, such as IMEI/ESN, Wi-Fi and Bluetooth MAC addresses, network unlock information etc.
fvisagie said:
Following from that, it seems that an unlocked but otherwise unmodified device can be fully restored from the factory image and a data partition backup (apart from perhaps needing to restore EFS in extreme cases), right?
Or are there other partitions that may get modified during normal use and need to be backed up too?
Click to expand...
Click to collapse
I recall from a previous experience that to be completely safe, user data/internal storage (/sdcard) needs to be backed up and restored too. Most Android apps that had been run and had created data on /sdcard before the backup will fail to run if restored without their /sdcard content.
Hi, what are the storage requirements for the /system partition for LOS 15.1?
I tried upgrading LOS 14.1 + opengapps nano to 15.1 + opengapps nano after the updater notified me of availability.
Initial attempt to upgrade the system ended in failure (made apparent with opengapps installer, not LOS) which I tracked down to the LOS installer completely exhausting the free space on /system - the build.prop file was empty and opengapps refused to install, citing incorrect SDK version.
So next I tried wiping the /system partition and then installing both again - LOS installer finished successfully, but this left free space of only ~120 MiB, not enough for opengapps nano. Is it expected that a fresh install of LOS without opengapps takes ~700MiB?
I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.
st3v3ntehl33t said:
I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.
Click to expand...
Click to collapse
Sorry, can't quickly try that - already reverted the device to the backup of 14.1 Do you mean you had to delete stock LOS apps to even install the pico opengapps package?
According to description, the diff between pico and nano is Health services and Google search, neither of which is installable from the play store, AFAICT (and would prefer to leave them in). Is there an option for a proper solution, eg. repartitioning the flash so that the system partition is big enough to hold it all? (How big is the system partition on phones factory-shipped with Android 8.1, anyway?)
Yes, that's correct there's not enough space to install gapps with all the factory apps installed. It was asked how this ROM could even go official with lineage when you have to do this work around to get play store functionality but technically having the play store is not a requirement for lineage os. (There's other options). Afaik it's only an issue because of the size of the actual system allocated area (call it a partition if you want) on the Nexus 4 itself. After you get it installed you can install apps to replace the ones you deleted.
Glad I found this post. Thanks for the details, because I was going around in circles trying to figure out what could be wrong.
While GApps are technically not "required", not allowing space for their install - which is likely very common - seems very short-sighted. Furthermore, the Install page offers the option (instructions) of flashing the GApps zip. If they're not going to leave any room for it, they should either document that, or mention that they didn't leave any room for you to do it. And really, the partition should just be sized big enough to allow for it.
st3v3ntehl33t said:
I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.
Click to expand...
Click to collapse
Thank you, pico actually worked!
To anyone is still not on LOS 15:
Repartitioning is fairly simple (although time-consuming, expect the data transfers to/from PC to take ~90 minutes in total), as the device's storage uses plain GPT as a partitioning scheme. Reposting my answer on stackexchange:
I eventually found this thread, where the author prepared an archive with gdisk and a few other tools.
Requirements:
Computer/VM with adb, fsck.ext4 and resize2fs
This zip file
Overview
The relevant partitions (system and userdata) are 21st and 23rd on the storage. The 22nd partition is just cache, so there's no harm nuking it, and making a new one after data from the other 2 are in place.
The TL;DR version of the procedure is:
boot into recovery, unmount everything
pull the data partition to computer
Code:
[PC] adb pull /dev/block/mmcblk0p23 userdata.img
put gdisk on the phone, and use it to modify the partition table - grow system while retaining its starting sector, shrink userdata by the same amount, and re-create cache between them
Code:
[PC] adb push gdisk /tmp/
[adb-shell] /tmp/gdisk /dev/block/mmcblk0
...
use resize2fs on the phone with the system partition to grow it
use resize2fs on the computer with the userdata partition's image to shrink it to appropriate size
push the modified data image to the phone
Code:
[PC] adb push userdata.img /dev/block/mmcblk0p23
format the cache partition, reboot into system
EDIT: I'm intentionally leaving out the details of what to do with gdisk, as I think using sgdisk's output and a text editor to just change the partition boundaries is the proper way to do this. If you really want and need some hints though:
On the phone, all of the affected partitions started on 8MiB-aligned sectors, and I maintained the alignment after the resize. It also makes specifying the new size to resize2fs straightforward
Partition name in the GPT, and unique GUID should be maintained after resize.
Oh, and regarding LOS-15 installation, the installer will image the system partition with original, 840MiB filesystem, and won't grow it, so subsequent g-apps installation will fail. It's necessary to grow the filesystem manually and then install g-apps.
myxal said:
push the modified data image to the phone
Code:
[PC] adb push userdata.img /dev/block/mmcblk0p23
Click to expand...
Click to collapse
putting aside missing information about how to get and use sgdisk (or gdisk) you're also not saying what modification has to be done to userdata.img and if this modification works with encrypted /data
rotanid said:
putting aside missing information about how to get and use sgdisk (or gdisk) you're also not saying what modification has to be done to userdata.img and if this modification works with encrypted /data
Click to expand...
Click to collapse
The modification referred in point 6 is the shrinking done in point 5. I have no experience with encrypted /data (or knowledge how that is implemented, for that matter), so I don't know what extra steps would be needed in that setup.
myxal said:
The modification referred in point 6 is the shrinking done in point 5. I have no experience with encrypted /data (or knowledge how that is implemented, for that matter), so I don't know what extra steps would be needed in that setup.
Click to expand...
Click to collapse
oh, thanks for the fast reply!
in that case, i think it's not possible to keep the data if it's encrypted, because you can't decrypt it on the PC to be able to shrink it