[HOW-TO] Info and Tips for Mitigating Risks in Rooting and Flashing Custom-ROM - Barnes & Noble Nook Tablet

[Caveat emptor: adopt/follow this guide at your own risk].
Rooting and especially running a custom firmware (commonly referred to as “ROM”) on an NT unlock the NT’s full potential as a Android tablet. However these undertakings entail a significant risk: accidents or errors in the Rooting or Custom ROM Flashing process can render the NT unusable (aka “bricked”), potentially permanently. This risk can be mitigated by:
developing a basic understanding of the essence of the Rooting and ROM Flashing processes – in particular which parts of the NT storage/content get modified or replaced, and which parts do not
choosing an effective yet low risk rooting/flashing process, and most importantly,
making preparation in advance for a recovery process in the event something goes wrong: by far the most common cause of permanent bricking is not the initial bad rooting/flashing process but rather the subsequent use of unsuitable recovery (“unbrick”) procedures/tools.
NT Internal Storage (EMMC) Partitions and Associated Content (approximated partition sizes on a 16GB NT w/ 8GB allocated for user media)
/xloader (128KB, /dev/block/mmcblk0p1): first stage bootloader (MLO)
/bootloader (256KB, /dev/block/mmcblk0p2): second stage bootloader (u-boot.bin)
/recovery (15.3MB, /dev/block/mmcblk0p3): recovery process (recovery.img)
/boot (16.3MB, /dev/block/mmcblk0p4): boot process (boot.img)
/rom (49.1MB, /dev/block/mmcblk0p5): a set of 15 files containing factory installed device info (ProductID, manufactured data, etc.) and individual device data (serial no., MAC address, security encryption keys, etc.)
/bootdata (49.1MB, /dev/block/mmcblk0p6): boot control and status data (BCB, BootCnt, max17042.bin)
/factory (378.8MB, /dev/block/mmcblk0p7): backup copy of stock ROM as well as backup copy of device data in /rom partition (romdata.zip)
/system (628.6MB, /dev/block/mmcblk0p8): running copy of ROM (system and base apps)
/cache (436.2MB, /dev/block/mmcblk0p9): storage area for temporary data by system/user apps
/media (7.8GB, /dev/block/mmcblk0p10): user media content
/userdata (often referred to as /data, 5.8GB, /dev/block/mmcblk0p11): user-installed apps
For information on the roles of some of these partitions in the NT boot process: see http://omappedia.org/wiki/Bootloader_Project and http://forum.xda-developers.com/showthread.php?t=1444630.
Rooting
Rooting essentially adds a number of system files and apps to the stock ROM on the /system and /data partitions. The simplest routing method which uses CWM recovery running on bootable SDcard and which contains relatively the most current rooting content package can be found at http://forum.xda-developers.com/showpost.php?p=31271965&postcount=240. To get a sense of what get installed into /system and other changes to the stock ROM file-system, take a peek at the two folders “data” and “system” and the "updater-script" file in the folder "META-INF\com\google\android" inside the rooting content package "update.zip" referenced in that post.
Custom-ROM Flashing
Flashing custom ROM replaces the boot.img in /boot with a copy of boot.img from custom ROM zip file and the stock ROM in /system with the custom ROM and Gapps from the custom ROM and Gapps zip files, and wipes out /data (where user-downloaded apps from Google Play store will be installed) as well as /cache. Some custom ROM builds, such as Succulent’s CM10.x or 11.x builds (which are posted on his Blog http://iamafanof.wordpress.com/) also include copy of CWM or TWRP recovery.img which replaces the stock recovery.img in the /recovery partition. To get a sense of what get installed onto the NT and where, take a peek at the folders (except for "META-INF") and the "updater-script" file in the folder "META-INF\com\google\android" inside the ROM and Gapps zip files.
A method for flashing CyanogenMod (CM) ROM using CWM or TWRP recovery running on bootable SDcard is outlined at http://forum.xda-developers.com/showpost.php?p=51377882&postcount=163 (CM10.x ROM) and http://forum.xda-developers.com/showthread.php?t=2692403 (CM11 ROM).
An alternative to installing CyanogenMod (CM) ROM intenally on emmc is to install and run it off an SDcard, leaving the NT entirely unmodified. See http://forum.xda-developers.com/showthread.php?t=2098419 for info on how to create CM10.x SDcard images using Succulent's CM10.x builds.
Recovery from a Bad Rooting and ROM Flashing
It should be clear from the above discussion that the Rooting and custom ROM Flashing processes only involve /system, /data, (and in the case of ROM Flashing) /boot and /recovery. Thus, a logical approach for recovery is to make a backup copy of these affected partitions prior to Rooting and ROM Flashing. This approach makes even more sense since the very same CWM or TWRP recovery tool used to install the content of the Rooting/ROM/Gapps zip packages can also be used to make a backup copy of the affected partitions’ content and subsequently restoring these partitions using the content backup copy if needed. For this reason, while there are various approaches to Rooting and ROM Flashing, the most pragmatic and prudent one is to use CWM or TWRP Recovery tool running off a bootable SDcard, as this enables using the SDcard for content backup and, more importantly, using the SDcard to boot the NT and restore the backup content even when the NT becomes un-bootable on its own.
The remaining partitions of the NT – namely: /xloader, /bootloader, /rom, /factory, and /media – are not involved and should not be affected at all by Rooting and ROM Flashing. Hence there is absolutely no reason to use any “unbrick” process/tool that would flash/reformat/repartition/wipe/zero-out any one of these partitions – unless it has been determined with certainty that these partitions have been irreversibly corrupted. In particular the two partitions /rom and /factory which contain factory-installed individual device data must never be reformatted/wiped/zeroed-out without first backing up their content in a restorable form -- therefore refrain from using any “unbrick” tool that reformat/overwrite/wipe these two partitions without first backing up and subsequently restoring their content.
Making a Bootable Recovery SDcard
There are two approaches to making a bootable SDcard with Recovery tool for Rooting and ROM Flashing: using a pre-made SDcard image (download, unzip and write the image to the SDcard using a disk-image writer program), and creating the SDcard from scratch. The first approach is convenient, while the second although a bit more time-consuming (and potentially frustrating) provides the flexibility in customizing the card: e.g., selecting particular version of Recovery tool (i.e., for its features, or its compatibility with the particular ROM release), sizing the SDcard boot partition to provide adequate space for backing up current ROM).
The TI OMAP processor used by the NT is very fussy about the cylinder/head/sector geometry of its “boot disk” (i.e., the SDcard in this case) – see http://processors.wiki.ti.com/index.php/SD/MMC_format_for_OMAP3_boot for more info). Fortunately its requirements can be met using many disk-partition management tools such as MiniToolPartition or EASEUS Partition Master simply by selecting the approriate menu options in creating the boot partition: cylinder aligned, primary/FAT32 with partition ID type 0x0C and with LBA and Active flags set.
Next the boot partition needs to contain a specific set of boot files: MLO, u-boot.bin and boot.img and/or flashing_boot.img (aka Cyanoboot); these can be found in SD_boot.zip compiled by Succulent and posted at http://iamafanof.wordpress.com/2012/11/11/how-to-guide-bootable-cm7cm9cm10-sdcard-for-nook-tablet/). I have also found that it helps to first copy MLO (to the freshly made boot partition) before copying the other files, since it appears that the NT OMAP processor only scans the first couple of entries in the partition looking for this file (see http://www2.sakoman.com/OMAP/preparing-a-bootable-sd-card.html and http://permalink.gmane.org/gmane.comp.embedded.openbricks.scm/515).
In my experience, the two most common symptoms of failed SD boot and their likely causes are:
The NT boots straight to stock -- most likely the boot partition's type and/or flags are not correctly set, or the NT cannot find the MLO in the boot partition (see comment re: the ordering in file copying above).
The NT screen stays dark for several minutes then eventually boots to stock -- most likely the MLO or u-boot.bin are corrupted. Check the exact size of these two files in bytes, they should be respectively 38,356 and 179,812.
Also, it should be noted that many NTs will boot off a SD card only from the power-off state and upon insertion of a powered USB cable.
To complete the making of the Recovery SDcard, download a recovery program .img file for sdcard (such as cwm_6012_sd.img or twrp_2220_sd.img from http://forum.xda-developers.com/showthread.php?t=1640958), rename it to recovery.img, and copy it to the SDcard boot partition.
Info/Tools for Restoring to Stock
For situations with absence of a working DYI backup copy, attempts can still be made to restore the NT to stock.
Restore to Stock ROM from Rooted Stock ROM (NT with intact stock Recovery and /factory partition): consider using the “8 failed boots” method documented at http://nookdevs.com/NookColor/RestoreToStock (it was written for the Nook Color but should be applicable to the Nook Tablet as well).
Restore to Stock ROM from Custom ROM:
A good source for resource/tool for restoring to stock is Succulent's repository at https://github.com/succulent/acclaim_recovery_sdcard; see its README file for an annotated index/description of the resource/tools and usage instructions. Another potential recovery tool is the repart.img described at http://raywaldo.com/2012/06/how-to-un-brick-a-nook-tablet-8gb-or-16gb/.
HOW-TO Guides for Installing CyanogenMod on Nook Tablet
Installing CM11 Internally on Nook Tablet
Installing CM10.x Internally on Nook Tablet
Updating NT Internal Emmc to CM11 from CM10.x
Building a CM10.1 (JB 4.2.x) SD card for Nook Tablet

Related

[HOW-TO] Installing CM11 (or CM12) Internally on Nook Tablet

[Caveat emptor: adopt/follow this guide at your own risk].
[Important Note: this process is applicable for CM11 builds that still maintains two separate partitions for /data and /media – as the case with CM10.x and stock ROMs (see http://forum.xda-developers.com/showthread.php?p=48612997#post48612997 for more info). If/when these two partitions get merged in some future CM11 builds (as being contemplated by our NT CM developers – see http://forum.xda-developers.com/showthread.php?t=2560827&page=28) this installation process will not be valid for those future builds with merged /data+media partition].
The following is the process using SD-based recovery to install CM11 internally (i.e., on emmc) on a Nook Tablet running stock ROM. [If your NT is already running CM10.x, see http://forum.xda-developers.com/showthread.php?t=2670589 for a simpler process to update from CM10 to CM11]. This same process can also be used to install CM12.x -- see http://forum.xda-developers.com/showpost.php?p=64624390&postcount=21 for needed corresponding versions of CM12 ROM, Android 6.0 GApps, and EMMC-based CWM recovery.
Using a disk partition tool (such as MiniTool Partition Wizard Home Edition) create on SD card a Primary FAT32 partition, and set the partition ID type for the partition to 0x0C FAT32 LBA and set its Active flag. Once this is done, the partition should appear as a (read/write accessible) drive under Windows
Obtain and copy to the SD card the following files:
first MLO, then next u-boot.bin and flashing_boot.img in succulent_boot.zip obtained from https://www.mediafire.com/folder/xjwc1a482a6ll/Nook_Tablet
TWRP (TeamWin Recovery Project) version 2.6.3.0 or later, e.g., openrecovery-twrp-2.6.3.1-acclaim-sdcard.img from http://techerrata.com/browse/twrp2/acclaim, rename it to recovery.img before copying to SD card.
the flashable_CWM_6.0.4.5_chrmhoffmann.zip zip file from https://www.mediafire.com/folder/xjwc1a482a6ll/Nook_Tablet which contains the CWM recovery v0.2 provided by Chris Hoffmann (in the first post of the XDA Official CM11 thread http://forum.xda-developers.com/showthread.php?t=2560827).
the zip file of CM11 ROM build of your choice from http://download.cyanogenmod.org/?device=acclaim (see http://www.cyanogenmod.org/blog/cm-11-m4-post-release-items for considerations in choosing nightlies vs. snapshot/stable builds).
the zip file of the Gapps package corresponding to CM11 – e.g., from http://wiki.cyanogenmod.org/w/Google_Apps
Put the SD card into the NT, and boot from its power off by inserting a powered USB cable. Press and hold the N button as soon as CyanoBoot comes up to get the boot menu to display.
Select SDC Recovery.
[Optional step but highly recommended] Select Backup to backup your NT current ROM config (/boot, /recovery, /system, and /data).
Select Wipe data & factory reset.
Select install zip from SD card and install flashable CWM recovery zip file.
Select install zip from SD card and install CM11 zip file.
Select install zip from SD card and install Gapps zip file.
Remove SD card and select reboot.
Once the NT boots up, set up the wifi connectivity and your google account info. If you had previously used Google backup service on your NT your apps will be auto-downloaded (but their settings will not be auto-restored).
Notes
If the Nook fails to boot off SD -- the two most common symptoms of failed SD boot and their likely causes are:
The NT boots straight to stock -- most likely the boot partition's type and/or flag are not correctly set, or the NT cannot find the MLO in the boot partition (make sure that MLO is the very first file to be copied to the freshly made /boot partition).
The NT screen stays dark for seemingly a long time then eventually boots to stock -- most likely the MLO or u-boot.bin are corrupted. When in doubt, compare the size of the two copies of the files in bytes.
Installing CM11 ROM and Gapps will override your NT's current boot, recovery, ROM, and Apps, so make sure that you backup all this stuff using recovery backup function, for easy in reverting to previous ROM if desired. See my post at http://forum.xda-developers.com/showthread.php?p=48612997#post48612997 for more "Info and Tips for Mitigating Risks in Rooting and Flashing Custom-ROM".
Also, I would advise against using any other functions of the recovery without first carefully researching to understand what they really do.
My thanks to all the developers who collective work created the wonderful CM11 ROM for the NT as well as the tools and info I made use of to install it.
bad boot image
I have followed your instructions carefully. But got an error message after selecting SDC recovery option from the boot menu..
booti: bad boot image magic (in memory).
I have tried to seat the card several times, no difference. This is a SanDisk 16GB class 10 card. I have installed CM11 on it, and worked. So the card can work. Now I want to install CM11 internally.
Don't know what else to try at this point. Please help. Thanks!
---------- Post added at 10:55 PM ---------- Previous post was at 10:28 PM ----------
gammaworks said:
I have followed your instructions carefully. But got an error message after selecting SDC recovery option from the boot menu..
booti: bad boot image magic (in memory).
Click to expand...
Click to collapse
Never mind, I have picked the wrong recovery.img. Ooops.
did not work for me
Installing it internally for the first time. Did not work...
set_metadata_recursive: some changes failed
E:Error executing updater binary in zip '/sdcard/cm-11-... SNAPSHOT-M4-acclaim.zip'
Error flashing zip '/sdcard/cm-11...SNAPSHOT-m4-acclaim.zip'
It appears I have bricked my nook tablet.
gammaworks said:
Installing it internally for the first time. Did not work...
set_metadata_recursive: some changes failed
E:Error executing updater binary in zip '/sdcard/cm-11-... SNAPSHOT-M4-acclaim.zip'
Error flashing zip '/sdcard/cm-11...SNAPSHOT-m4-acclaim.zip'
...
Click to expand...
Click to collapse
Which version of SD based recovery did you use?
Also, you might want to consider to first flash CM10.x (see http://forum.xda-developers.com/showpost.php?p=51377882&postcount=163) then later update to CM11.
come back from the dead
digixmax said:
Which version of SD based recovery did you use?
Also, you might want to consider to first flash CM10.x (see http://forum.xda-developers.com/showpost.php?p=51377882&postcount=163) then later update to CM11.
Click to expand...
Click to collapse
Thanks. An youtube video helped me out in the end: watch?v=3YYXtGAt6GY
What did I do differently this time? After installed openrecovery-twrp-2.7.0.0-acclaim-sdcard.img onto emmc, I rebooted NT without a SD card. The TWRP boot menu came up. I put the SD card back in. The SD card has CM11 and Gapps zip files. I then selected internal EMMC recovery (that is the key I think):
factory reset
install cm-11-20140405-SNAPSHOT-M5-acclaim.zip
install pa_gapps-modular-mini-4.4.2-20140321a-signed.zip
Now I have Android 4.4.2 running on my NT.
gammaworks said:
...
What did I do differently this time? After installed openrecovery-twrp-2.7.0.0-acclaim-sdcard.img onto emmc
...
Click to expand...
Click to collapse
The TWRP openrecovery-twrp-2.7.0.0-acclaim-sdcard.img is for SD card, the corresponding version for emmc openrecovery-twrp-2.7.0.0-acclaim.img.
gammaworks said:
Thanks. An youtube video helped me out in the end: watch?v=3YYXtGAt6GY
What did I do differently this time? After installed openrecovery-twrp-2.7.0.0-acclaim-sdcard.img onto emmc, I rebooted NT without a SD card. The TWRP boot menu came up. I put the SD card back in. The SD card has CM11 and Gapps zip files. I then selected internal EMMC recovery (that is the key I think):
factory reset
install cm-11-20140405-SNAPSHOT-M5-acclaim.zip
install pa_gapps-modular-mini-4.4.2-20140321a-signed.zip
Now I have Android 4.4.2 running on my NT.
Click to expand...
Click to collapse
I did the same as you and get stuck at the CM boot screen. Tried 2x reflashing and keep getting stuck at the CM boot screen with the spinning arrow.
nm, 3rd time was the charm for some reason . Going through setup now, thanks!
bobzdar said:
I did the same as you and get stuck at the CM boot screen. Tried 2x reflashing and keep getting stuck at the CM boot screen with the spinning arrow.
nm, 3rd time was the charm for some reason . Going through setup now, thanks!
Click to expand...
Click to collapse
How long did you wait for the first-time boot to complete?
FWIW successful first-time boot typically takes 3 to 4 min.
digixmax said:
How long did you wait for the first-time boot to complete?
FWIW successful first-time boot typically takes 3 to 4 min.
Click to expand...
Click to collapse
I waited around 15 minutes the first two times. I could tell it was doing something different the 3rd time as the swirling arrow would stop briefly as it presumably loaded things while the first two times it just swirled non-stop.
Great procedures
digixmax said:
[Caveat emptor: adopt/follow this guide at your own risk].
[Important Note: this process is applicable for CM11 builds that still maintains two separate partitions for /data and /media – as the case with CM10.x and stock ROMs (see http://forum.xda-developers.com/showthread.php?p=48612997#post48612997 for more info). If/when these two partitions get merged in some future CM11 builds (as being contemplated by our NT CM developers – see http://forum.xda-developers.com/showthread.php?t=2560827&page=28) this installation process will not be valid for those future builds with merged /data+media partition].
The following is the process using SD-based recovery to install CM11 internally (i.e., on emmc) on a Nook Tablet running stock ROM. [If your NT is already running CM10.x, see http://forum.xda-developers.com/showthread.php?t=2670589 for a simpler process to update from CM10 to CM11].
Using a disk partition tool (such as MiniTool Partition Wizard Home Edition) create on SD card a Primary FAT32 partition, and set the partition ID type for the partition to 0x0C FAT32 LBA and set its Active flag. Once this is done, the partition should appear as a (read/write accessible) drive under Windows
Obtain and copy to the SD card the following files:
first MLO, then next u-boot.bin and flashing_boot.img in succulent_boot.zip obtained from https://www.mediafire.com/folder/xjwc1a482a6ll/Nook_Tablet
TWRP (TeamWin Recovery Project) version 2.6.3.0 or later, e.g., openrecovery-twrp-2.6.3.1-acclaim-sdcard.img from http://techerrata.com/browse/twrp2/acclaim, rename it to recovery.img before copying to SD card.
the flashable_CWM_6.0.4.5_chrmhoffmann.zip zip file from https://www.mediafire.com/folder/xjwc1a482a6ll/Nook_Tablet which contains the CWM recovery v0.2 provided by Chris Hoffmann (in the first post of the XDA Official CM11 thread http://forum.xda-developers.com/showthread.php?t=2560827).
the zip file of CM11 ROM build of your choice from http://download.cyanogenmod.org/?device=acclaim (see http://www.cyanogenmod.org/blog/cm-11-m4-post-release-items for considerations in choosing nightlies vs. snapshot/stable builds).
the zip file of the Gapps package corresponding to CM11 – e.g., from http://wiki.cyanogenmod.org/w/Google_Apps
Put the SD card into the NT, and boot from its power off by inserting a powered USB cable. Press and hold the N button as soon as CyanoBoot comes up to get the boot menu to display.
Select SDC Recovery.
[Optional step but highly recommended] Select Backup to backup your NT current ROM config (/boot, /recovery, /system, and /data).
Select Wipe data & factory reset.
Select install zip from SD card and install flashable CWM recovery zip file.
Select install zip from SD card and install CM11 zip file.
Select install zip from SD card and install Gapps zip file.
Remove SD card and select reboot.
Once the NT boots up, set up the wifi connectivity and your google account info. If you had previously used Google backup service on your NT your apps will be auto-downloaded (but their settings will not be auto-restored).
Notes
If the Nook fails to boot off SD -- the two most common symptoms of failed SD boot and their likely causes are:
The NT boots straight to stock -- most likely the boot partition's type and/or flag are not correctly set, or the NT cannot find the MLO in the boot partition (make sure that MLO is the very first file to be copied to the freshly made /boot partition).
The NT screen stays dark for seemingly a long time then eventually boots to stock -- most likely the MLO or u-boot.bin are corrupted. When in doubt, compare the size of the two copies of the files in bytes.
Installing CM11 ROM and Gapps will override your NT's current boot, recovery, ROM, and Apps, so make sure that you backup all this stuff using recovery backup function, for easy in reverting to previous ROM if desired. See my post at http://forum.xda-developers.com/showthread.php?p=48612997#post48612997 for more "Info and Tips for Mitigating Risks in Rooting and Flashing Custom-ROM".
Also, I would advise against using any other functions of the recovery without first carefully researching to understand what they really do.
My thanks to all the developers who collective work created the wonderful CM11 ROM for the NT as well as the tools and info I made use of to install it.
Click to expand...
Click to collapse
Your procedures worked out great. I've managed to take a stock Nook Table and have it running KitKat 4.4.4 in 3 day. The 1st 2 days I had only managed to root it and play around a bit. Thanks to every ones great work I'm up and running. 1st boot was a bit interesting as I renamed openrecovery-twrp-2.6.3.1-acclaim-sdcard.img to recovery.img.img but after review the SD Card / rebuilding there were no more issues. it it booted and worked great. Thanks again ===
I ran into a problem and am hoping for a hand. My NT boots perfectly form the SD card and loads up the recovery screen while following the instructions, I made a backup, but when I go to do the data wipe and factory reset or start to install the CWM file I get an error of "E: Unable to mount '/BootData' ".
I have tried starting over by resetting up the Nook and registering it again, but same thing. If I pull out the SD card it boots right up into use as a standard NT ready to register and go.
I am going to try again starting over and with a different version of TWRP just in case that is the issue.
Thanks for the help!
Allkair said:
I ran into a problem and am hoping for a hand. My NT boots perfectly form the SD card and loads up the recovery screen while following the instructions, I made a backup, but when I go to do the data wipe and factory reset or start to install the CWM file I get an error of "E: Unable to mount '/BootData' ".
I have tried starting over by resetting up the Nook and registering it again, but same thing. If I pull out the SD card it boots right up into use as a standard NT ready to register and go.
I am going to try again starting over and with a different version of TWRP just in case that is the issue.
...
Click to expand...
Click to collapse
Did you try TWRP v2.6.3.0 (openrecovery-twrp-2.6.3.0-acclaim-sdcard.img at http://techerrata.com/browse/twrp2/acclaim)?
Working
Thanks for the help. Along the way I did get it working on the night of 11/10, I just forgot to post that . 9th try is the charm I guess? In any case I tried first with TWRP 2.8.1.0 and then went back to 2.6.3.1 and then on my last attempt tried again with 2.8.1.0 and it worked so I have a NT running the last monthly of 11 and so far no issues. The sad news is that I have no idea what I did different to make it work the final time vs the first couple of try's.
YES YES YES!! It works! I've been struggling for more weeks than I care to admit to install CM 12. I've followed nearly every tutorial I can find and pursued WAY too many paths (bootable SD, fastboot, root) and couldn't get anything to work. Probably my very minimal knowledge of this subject is the culprit, but I've done a ton of research. Finally I decided to give CM 11 a shot and found this post. What a life saver!! Thank you everyone for your contributions to make this possible even for laymen like me!
FWIW, I couldn't get it to work with the "flashable_TWRP_2.6.3.1.zip" included in the mediafire folder provided by digixmax. I deleted that from the SD, downloaded 2.6.3.1 from the TWRP website (note: SD version) and it worked! I also tried the non-SD version of TWRP 2.6.3.1 and it didn't work...required the SD version to work. You guys rock!
coloradonate said:
...
FWIW, I couldn't get it to work with the "flashable_TWRP_2.6.3.1.zip" included in the mediafire folder provided by digixmax. I deleted that from the SD, downloaded 2.6.3.1 from the TWRP website (note: SD version) and it worked! I also tried the non-SD version of TWRP 2.6.3.1 and it didn't work...required the SD version to work. You guys rock!
Click to expand...
Click to collapse
You need to use the SD version of CWM or TWRP to flash CM from SD.
flashable_TWRP_2.6.3.1.zip is a flashable zip to flash and install TWRP itself into EMMC.
So if I download the most recent TWRP and CM 12.1 zip, could I simply replace the 2 older TWRP and CM 11 files on my SD? Would that actually work to get 12.1? It seems like the other files are only related to the bootloader and should be universal to work with any recovery and CM zip. Somehow I doubt it's that easy..
coloradonate said:
So if I download the most recent TWRP and CM 12.1 zip, could I simply replace the 2 older TWRP and CM 11 files on my SD? Would that actually work to get 12.1? It seems like the other files are only related to the bootloader and should be universal to work with any recovery and CM zip. Somehow I doubt it's that easy..
Click to expand...
Click to collapse
The function of the 2 files MLO and u-boot.bin is to boot the NT and load CyanoBoot (the 3rd file flashing_boot.img) which in turns would enable you to select and load the recovery.img file on the SD card; hence they should be invariant of the CM version you want to flash.
All you need is a copy of SD-based (TWRP) recovery.img version that is compatible with CM12.x and the GApps package.
Wow, it worked with 12.1! I have stumbled upon THE thread that finally helped me get this to work. Countless dead ends and I finally found it.
I took the plunge and tried installing cm12.1. Per post #1 in this thread, I used the same flashing_boot.img, MLO, and u-boot.bin that's in digixmax's mediafire folder. Also used the same flashable_CWM_6.0.4.8_chrmhoffmann.zip per post #1.
The files that are different from post #1 in this thread are: the most recent CM12.1 release (as of tonight: cm-12.1-20151117-SNAPSHOT-YOG7DAO1K6-acclaim.zip), the most recent TWRP for SD (as of tonight: twrp-2.8.6.0-acclaim-sdcard.img; renamed to recovery.img before copying to SD as suggested) and a compatible gapps version. A little google searching led me to the pico gapps from TKruzze that I got from post #1 of this link (http://forum.xda-developers.com/android/software/tk-gapps-t3116347). I downloaded this from the BasketBuild link under "Proper DPI Play Services" of the Pico Modular Package in post #1 of that link I just mentioned. I followed the same directions that were in post #1 of this thread that originally gave me success with CM11, and sure enough it all worked great with CM12.1. I'm now running CM12.1 and couldn't be happier.
A HUGE THANK YOU to digixmax and everyone else who contributed to the creation of these seemingly universal files (e.g., flashing_boot.img, MLO, u-boot.bin, etc.) to enable this to work. And of course a THANK YOU to the CWM, TWRP and CM developers. Seriously, you guys rock.
can someone check if my files are correct? especially the first 3 since I cant boot from SD no matter how many time I reformat, redownload, recopy....
ddvche said:
can someone check if my files are correct? especially the first 3 since I cant boot from SD no matter how many time I reformat, redownload, recopy....
Click to expand...
Click to collapse
Did you boot from power-off by inserting a powered USB cable?
Also, make sure that MLO is the very first file you copy to the freshly reformatted, empty SD card.

Solved -- Running safestrap on sdcard -- looking for input

So I got tired of my weird configuration of running the apps in a mounts2sd with a second ext4 partition on my sdcard and technically nothing should prevent us from running safestrap on the sdcard. So I looked around and it took me a while but I found Hashcode's source code and spent some time studying all the voodoo he does, and most of it is fairly straight forward. Small breakdown:
* Extend TWRP with ifdef statement to add new buttons
* sh scripts get called to perform the functionality for those button
* Swap out some links in /dev/block when you switch between slots and stock
* The entire boot partition including scripts, TWRP, etc are stored in boot image
* The boot image is stored in the stock system under /etc/safestrap
Like I said before, most of the functionality is done in borne shell scripts, but there is some hardcoding in TWRP like creating the .img file to /ss. I really don't want to try to recompile TWRP at this time. As such, I want to limit my changes to the borne shell and configuration INI files only. The simplest answer is to remap /ss from internal storage to the sdcard storage. Another option is to have "system" and "cache" in the internal storage and moving "data" to the sdcard. The difficulty here is since TWRP is hardcoded to create the .img file under /ss, I need to move it during the format stage which happens in the script. The danger with the first option I don't know if the phone will boot if the sdcard is removed. safestrap looks for that directory to figure out the mappings in /dev/block. I think if the directory is missing then it will attempt to create it. After that, things might go bad.
Anyway, what are your thoughts?
i wish and hope your still working on this..my phone is so low in internal storage..i cant even use a rom slot other than stock,,ive been useing stock slot ,flashing custom rom in stock slot....anyways hope you continue to figure this out..i know lots of people would appreciate it..thanks
So I've tried multiple ways and have had to step away, think about it some more, and come back to it. Essentially I was not able to get system to boot off of the sdcard. However, the good news is today I was able to have system and cache on internal storage and data on sdcard. So here are the keys to the kingdom that I have found....
The CM11 (and I assume other) ROMs there is a /system/etc/kexec/ramdisk.img file. This file is extracted (gunzip < ramdisk.img | cpio -iu) into the root directory "/" (rootfs). There is a shell script "/sbin/fixboot.sh" that gets executed by /init at the start of the android (on fs). That script essentially mounts /ss to /emstorage and does all the loop storage links to the system.img, cache.img, and data.img files. I was able to mount another /ss2 to my sdcard and point the userdata to /ss2/safestrap/rom-slot?/userdata.img. The limitation is that vfat limits all files to 4 GB max, so the userdata.img cannot be more than 4 GB of storage.
So an option is I can create an updated ramdisk.img file. You would just drop this into your /system/etc/kexec directory on the slot-rom you want to use it. The only file changed in ramdisk.img is /sbin/fixboot.sh. ramdisk.img is part of the CM11 distribution so you would need to replace it each time you perform an update on that rom slot. Other than that, safestrap would by default create userdata.img to be in internal storage.
The next part I'm going to look at is to create a f2fs partition on my sdcard and have my userdata use that f2fs partition. I figure I should good considerable more I/O as f2fs is suppose to be a good amount faster than ext3/4 and we wouldn't be going through a loop device from ext3 to vfat for all I/O. In addition, my data partition would no longer be limited to 4GB due to the file limitation size of vfat.
Thoughts...
So Spyder doesn't have f2fs on it so I've been running ext4. The kernel would need to be setup to be compiled with it. I have a second 6Gb partition formatted with ext 4 with writeback journaling but per my timing tests I don't think it has made a difference. Now I have more than enough space left in both the data and internal partitions. I don't know if it is just a placebo effect but my apps do seem to start slightly faster.
There doesn't seem much interest in this but it was a fun exercise for me. This will be good enough for me as I'll probably upgrade my phone sometime in the future.
Sent from my XT912 using XDA Free mobile app

[Q&A] MultiSystem for Android

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
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
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:
No AOSP roms, what's the point?
Don't mean to be a Negative Nancy here but what is the point if locked bootloaders cannot run AOSP roms on this. My locked bootloader S4 has always been able to run stock roms and those with unlocker bootloaders have always been able to enjoy the freedoms Multisystem can provide for them anyway. This doesn't seem to change the game at all.
Once again those with locked bootloaders are left out in the cold.

[Q&A] MultiSystem for Android

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
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
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:
I remember we had this kind of thing working on Galaxy Y, it was working just excellent (tho SD card is slower than int.flash)
multisystem is very much like SAFESTRAP , google it

How to access boot partition of sdcard to alter file

This may be simpler than I think or impossible, but I don't know enough to decide either way.
I am trying to salvage an abandoned sdcard-based CM 11 ROM for the B&N Nook Simple Touch e-reader. Mostly, I've been able to work around issues but I would like to enable some kind of boot option so the user could reboot into the CM 11 ROM from the stock OS and vice/versa. I have tested the idea in principle and know that if u-boot.bin in the boot partition of the sdcard is renamed to u-boot.bin.bak or similar, the device will not boot from the sdcard but instead from the internal OS.
If I expand the sdcard boot partition (FAT32) to fill up the vacant space on the sdcard, the internal OS sees this as a valid sdcard and will use it for user files, etc. And, indeed, I can still see the boot files using a file manager so un-renaming u-boot.bin in preparation for booting into the CM 11 system is easy. I can write a little app that will handle both restoring the file name to u-boot.bin and triggering a reboot.
It's the other direction that has me stumped. When the CM 11 ROM boots up from the sdcard, the boot partition becomes invisible as far as I can tell. How can I see the files there and (hopefully) rename u-boot.bin to disable it if the user wants to reboot back into the stock OS? If this can be done via shell commands, that would be ideal.
Any help?

Categories

Resources