Related
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
I've read up on the Q&A and development op. After following the instructions here is my current situation. I have the multisystem installed on a stock rooted rom(NCE w/OA1 bl). My ext sd is partitioned in two primary sections. One Fat32 and the other ext4. 50gb and 20(ish)gb. The app opens fine. I clicked install and received a toast notification on the bottom. Then I tried to flash the multisystem zip in safestrap. Flashing in multisystem was not possible for me. When I selected the zip from the multisystem "select file" option nothing appeared in the space under the option. When flash was pressed nothing happened. Anyways, I ended up flashing in safestrap. It appeared the the script was ran and my phone rebooted. The op said to wait for the green led light and set selinux to permissive. Never got that screen. I've tried it a few times now with same results. After I flashed the multisystem zip in safestrap and not getting the green led and multisystem screen on boot I tried flashing the zip in multisystem. Same result, I am unable to flash from the app. It lets me select the file. But after that it doesnt appear in the items to be flashed and pressing the flash button is met with a toast but nothing happens. I'm stuck any help is appreciated. Thanks.
stupid question. Do you have to be rooted for this to work?? Tried on locked lollipop bootlader from att and it force closes.
ecera said:
I've read up on the Q&A and development op. After following the instructions here is my current situation. I have the multisystem installed on a stock rooted rom(NCE w/OA1 bl). My ext sd is partitioned in two primary sections. One Fat32 and the other ext4. 50gb and 20(ish)gb. The app opens fine. I clicked install and received a toast notification on the bottom. Then I tried to flash the multisystem zip in safestrap. Flashing in multisystem was not possible for me. When I selected the zip from the multisystem "select file" option nothing appeared in the space under the option. When flash was pressed nothing happened. Anyways, I ended up flashing in safestrap. It appeared the the script was ran and my phone rebooted. The op said to wait for the green led light and set selinux to permissive. Never got that screen. I've tried it a few times now with same results. After I flashed the multisystem zip in safestrap and not getting the green led and multisystem screen on boot I tried flashing the zip in multisystem. Same result, I am unable to flash from the app. It lets me select the file. But after that it doesnt appear in the items to be flashed and pressing the flash button is met with a toast but nothing happens. I'm stuck any help is appreciated. Thanks.
Click to expand...
Click to collapse
You can't use the flash function until you correctly install MultiSystem. Follow OP instructions & install MultiSystem from within app; then, flash the ZIP file via FlashFire. If this doesn't work for you, send me the log file (if created at all) & /system/bin/e2fsck.
Also, you may get assistance from VZW N3 users here: http://forum.xda-developers.com/verizon-galaxy-note-3/help/qa-multisystem-android-t3089530
Billy06010 said:
stupid question. Do you have to be rooted for this to work?? Tried on locked lollipop bootlader from att and it force closes.
Click to expand...
Click to collapse
Root access is required.
Here are the two files. I odined to NCE w/OA1 bootloader because I ended up soft bricking after a failed flash attempt of the Multisystem.zip in flashfire.(no idea why that happened, I probably goofed up somewhere). Followed muniz's upgrade method for lollipop to keep root OC4 w/OA1 bootloader. Followed the steps as you said to properly install Multisystem. Same result. When I'm on lollipop when I click to add a file in the Multisystem apk it doesn't even open up the files. As it did when I was on 4.4.2 NCE. That's one difference I noticed. The reason I updated after I Odined to NCE stock was that the phone was really laggy. Overall it was the same result for me trying to install Multisystem. Again, I appreciate your help. Thank you.
I got this installed and everything looks correct, i dont see any green led on boot though. Do you need to have a second rom installed for mulisystem to show up?
Sent from my twi5ted SM-G900A using Tapatalk
ecera said:
Here are the two files. I odined to NCE w/OA1 bootloader because I ended up soft bricking after a failed flash attempt of the Multisystem.zip in flashfire.(no idea why that happened, I probably goofed up somewhere). Followed muniz's upgrade method for lollipop to keep root OC4 w/OA1 bootloader. Followed the steps as you said to properly install Multisystem. Same result. When I'm on lollipop when I click to add a file in the Multisystem apk it doesn't even open up the files. As it did when I was on 4.4.2 NCE. That's one difference I noticed. The reason I updated after I Odined to NCE stock was that the phone was really laggy. Overall it was the same result for me trying to install Multisystem. Again, I appreciate your help. Thank you.
Click to expand...
Click to collapse
It seems that you're missing some steps here. Could you please follow or this post or this one, but with skipping any device-specific steps? Just read that post to understand/find the step(s) you've missed. Also, before doing anything, you can check MultiSystem installation: http://forum.xda-developers.com/showpost.php?p=60554742&postcount=6
Rakuu said:
I got this installed and everything looks correct, i dont see any green led on boot though. Do you need to have a second rom installed for mulisystem to show up?
Click to expand...
Click to collapse
Which version have you installed? The latest version fixes LED indicator for S5 & S4.
hsbadr said:
It seems that you're missing some steps here. Could you please follow or this post or this one, but with skipping any device-specific steps? Just read that post to understand/find the step(s) you've missed. Also, before doing anything, you can check MultiSystem installation: http://forum.xda-developers.com/showpost.php?p=60554742&postcount=6
Click to expand...
Click to collapse
I followed the steps as explained in the two posts you quoted. Same result, no green LED after flashing the zip. I went to terminal emulator after flashing the zip and performed the command "mount | grep /MultiSystem" and nothing happens. I just get a new line for a different command. I went into /MultiSystem in root browser. Folder is empty. Not sure if that's normal. On a side note, Is there anyone on ATT S5 running rooted Lollipop that has successfully installed MultiSystem that can chime in?
ecera said:
I followed the steps as explained in the two posts you quoted. Same result, no green LED after flashing the zip. I went to terminal emulator after flashing the zip and performed the command "mount | grep /MultiSystem" and nothing happens. I just get a new line for a different command. On a side note, Is there anyone on ATT S5 running rooted Lollipop that has successfully installed MultiSystem that can chime in?
Click to expand...
Click to collapse
Ok, MultiSystem v1.3 will get released today.
hsbadr said:
Ok, MultiSystem v1.3 will get released today.
Click to expand...
Click to collapse
You are awesome and thanks again for helping me out.
hsbadr said:
Ok, MultiSystem v1.3 will get released today.
Click to expand...
Click to collapse
I have the latest one, my /Multisystem has some folders in it, mount | grep /Multisystem comes upbwoth proper output and running Multisysyem does give an output. Should i turn on runnkng at boot in the settings? Or is something broke that you're going to fix in 1.3?
Sent from my twi5ted SM-G900A using Tapatalk
Rakuu said:
I have the latest one, my /Multisystem has some folders in it, mount | grep /Multisystem comes upbwoth proper output and running Multisysyem does give an output. Should i turn on runnkng at boot in the settings? Or is something broke that you're going to fix in 1.3?
Click to expand...
Click to collapse
No, the on-boot commands is device-spcific kernel tweaks that are currently disabled. Check changelog in the main development thread. Mainly, it now has an option automatically mount the stock or secondary virtual IMG on boot. This has some flashing-releated considerations that I'll explain ASAP.
ecera said:
You are awesome and thanks again for helping me out.
Click to expand...
Click to collapse
You can consult @Rakuu on his successful installation of 1.3.
hsbadr said:
You can consult @Rakuu on his successful installation of 1.3.
Click to expand...
Click to collapse
I just want to double check, i'm not supposed to get any screen right? Just the green led which im supposed to press a key after seeing?
Sent from my twi5ted SM-G900A using Tapatalk
Since the first Nougat dev build, I've been running stock unlocked Android. However, I haven't been able to keep my recovery installed, and I've had to reflash it via my computer every time I wanted to be able to flash things via TWRP. In addition, nothing I flash (except when I root the device, for some reason) survives the reboot into system, even if it was a successful flash. Any help is appreciated.
Nexus 6
Stock Android 7.0 Nougat
Unlocked, but not rooted
Sent from my Nexus 6 using Tapatalk
The system will rewrite the recovery partition every time you boot it up. You need to make an edit to system partition to prevent that from happening. Specifically, the script at /system/bin/install-recovery.sh.
Now of course you are *also* having problems getting changes to the system partition to stick. This is due to dm-verity running on that partition. In order to cancel that, you need to modify the initrd image (part of the boot image). Specifically, remove the verity parameter from the fstab for system partition.
doitright said:
Specifically, the script at /system/bin/install-recovery.sh.
Specifically, remove the verity parameter from the fstab for system partition.
Click to expand...
Click to collapse
I've never made an edit to the recovery.sh file but I've always ran a noforce nonverify boot img and TWRP always stuck for me. I read that when you allow TWRP to modify system that it automatically edits this file which I do. Is this way it's sticking? I never had any problems and it seems a lot of "TWRP not sticking" threads are popping up.
Sent from my Nexus 6 using XDA-Developers mobile app
doitright said:
The system will rewrite the recovery partition every time you boot it up. You need to make an edit to system partition to prevent that from happening. Specifically, the script at /system/bin/install-recovery.sh.
Now of course you are *also* having problems getting changes to the system partition to stick. This is due to dm-verity running on that partition. In order to cancel that, you need to modify the initrd image (part of the boot image). Specifically, remove the verity parameter from the fstab for system partition.
Click to expand...
Click to collapse
Could you explain how to do all of that? I have no idea what to edit or where those things are.
Sent from my Nexus 6 using Tapatalk
What exactly does this option do when booting into TWRP for the first time?
And as a follow up question, if I don't do it how does it limit me in the future with regards to flashing ROMs?
Anyone?
Official statement:
System read only option: Devices that ship with 5.0 and higher as their initial OS are using block level OTA updates. With this style of OTA update, the update script checks to see if the system partition has ever been mounted read/write. Further, the script also usually runs an SHA sum of the entire system partition to detect if any changes have been made. If any changes have been made, the OTA update will refuse to install. Since not all OEMs and devices have factory images available, we have created a new feature in TWRP that detects if the system partition has ever been mounted read/write. If not, you will be prompted asking if you want TWRP to mount system as read/write. If you choose not to allow TWRP to mount as read/write, TWRP won’t prompt to install SuperSU and TWRP won’t try to patch the stock ROM to prevent TWRP from being replaced by stock recovery. The goal of this option is to hopefully allow the user to make a raw system image backup that they can use to get back to a state where they can take OTA updates again.
Click to expand...
Click to collapse
I don't care about OTA so I always allow modifications.
Have a look at the TWRP thread for OP3/3T: https://forum.xda-developers.com/oneplus-3/development/recovery-official-twrp-oneplus-3-3t-t3543391
Primokorn said:
Official statement:
I don't care about OTA so I always allow modifications.
Have a look at the TWRP thread for OP3/3T: https://forum.xda-developers.com/oneplus-3/development/recovery-official-twrp-oneplus-3-3t-t3543391
Click to expand...
Click to collapse
Thanks, I've simply turned off system updates with TitaniumBackup after root, i guess allowing modifications is a cleaner way of dealing with it.
Cheers!
My phone (3T) has an unlocked bootloader, is encrypted, not rooted, and running stock OOS 5.0.
I flashed TWRP and discovered that stock OOS restores the stock recovery in boot.
I saw the Oreo dm-verity thread by xenet, had a look at the zip file, noticed that it just modified fstab to prevent force encrypt, so I flashed it to see what happens.
And nothing happens. After the system had booted, fstab is unchanged from the original stock copy.
So I'm wondering whether this file is also restored when booting up on stock.
I get aggressive and go back to TWRP and delete /system/etc and /system/bin and modify build.prop.
Surely now the phone won't boot!
Wrong! It boots up and everything is back to normal in /system.
I go back to TWRP and have a look at /system and it shows me one without the etc and bin folders and has the modified build.prop.
What's going on? How can I see one version of /system in TWRP but a different version (ie, stock) when the phone has booted?
By the way I've been an Android user for many years and have rooted and flashed custom ROMs on a variety of phones and I've never seen anything like what's happening on my 3T. I'm sure that dm-verity is somehow involved in this.
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
nicknacknuke said:
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
Click to expand...
Click to collapse
Thanks.
I should have mentioned that I'm also not rooted. So stock OOS 5.0.
Sent from my OnePlus 3T using XDA Labs
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Sent from my OnePlus 3T using XDA Labs
BillGoss said:
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Click to expand...
Click to collapse
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Click to expand...
Click to collapse
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Click to expand...
Click to collapse
Thanks, you are correct. I'd forgotten that that TWRP remembers. Deleting .twrps does bring up the RO prompt after decrypting storage.
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
I had allowed changes to the system otherwise I couldn't have made changes to it, which includes the ability to restore the system partition.
But I'm still unclear why if I make changes to the system partition and boot with the stock kernel, then after the boot none of the changes are present in the system partition, but if I boot back into TWRP then the changes are all there.
I recall someone in another OOS 5 thread saying that the stock kernal replaces TWRP with stock recovery if you don't flash root (magisk/superSU). Is it possible that the kernel re-flashes system on boot? Another possibility is that TWRP thinks it's making changes to system but it's not actually? Not quite sure, I've never heard of anything like this before either, just throwing other ideas out there.
I've never read anything about the OP3T or any oneplus phones for that matter having A/B system partitions like the pixels. *shrug*
@nhshah7, something's like what you suggest must be going on to account for what I'm seeing. I'm hoping that someone can confirm my observations and provide a definite answer.
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Xennet said:
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Click to expand...
Click to collapse
Actually it doesn't explain how TWRP can make changes to system yet the phone boots up on an unmodified system if using the stock kernel. And then, when you boot back into TWRP and look at system, the changes are still there.
Where does the unmodified system come from?
Where does the modified system live?
Why doesn't modifying system result in a failed boot due to dm-verity, while restoring a backup of system does result in a failed boot?
So many questions with no answers.
BillGoss said:
....So many questions with no answers.
Click to expand...
Click to collapse
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
rk2612 said:
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
Click to expand...
Click to collapse
I'll come back to 1.
2. That makes sense and accounts for why a restore of the system partition with the stock boot image causes me to get dumped back in fastboot mode. If I flash the stock system zip file then the system boots properly.
3. I've not had any issues with strange boot behaviour. I'm always starting with stock or flashing kernels that modify the stock boot image, like Blu Spark.
4. I gathered this from my reading of various threads. If I want to make changes to the system partition and get them to stick and not fail dm-verity then I have to flash a custom kernel. I've proven this in my testing. (A rooting solution would also work, but I've not done this).
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
BillGoss said:
....
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
Click to expand...
Click to collapse
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
rk2612 said:
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
Click to expand...
Click to collapse
Good questions. They got me thinking more about how this could possibly work.
I had a look at the cache and there's definitely no copy of the system hiding there.
I also unpacked the ramdisk in the boot image and it had nothing in system. Furthermore, the boot position is only 64 MB, no where near enough to hold the system.
Then I installed Magisk so that I could browse around the phone's partitions and take copies.
I learnt two things from this:
1. If there's a second copy of the system there are only three partitions large enough to hold it (/proc/partitions shows the sizes in 1 kB blocks). The system is about 1 GB. There is space in the system partition (sde20) for 3 GB. There's also space in the data partition (sca15). And there's space in the major partition holding the modems (sdf).
I could eliminate the data partition by formatting it but restoring the internal storage (sdcard) is such a a pain.
So I'll just accept that there is space for a copy, but I'm unlikely to find out exactly where.
2. When I had Magisk installed installed and the system boot, I added a folder and file to /system/priv-app using a file manager (so not using TWRP). I then booted into recovery, flashed the stock boot image, and rebooted. I was expecting it to fail dm-verity (modified system) but it didn't. After booting up there's no evidence of the folder I added to priv-app.
And if I restore the Magisk boot image then the additions show up again.
I'm actually very impressed with how the stock system (kernel, recovery, system) protects itself from modification. Very cool!
Did anybody had a luck of getting RW on C25s ? If so, what was the procedure? Of course, I'm aware of shared_blocks feature, which I removed for all system partitions already.
It's funny, but even if flag rw is set as a mounting option in both fstab files - you'll never get RW for any system partitons. You'll never see RW not only for system / vendor / odm but for all my_ partitions - all of them fail to mount in RW.
And no, it's not funny, it's weird.
vp1117 said:
Did anybody had a luck of getting RW on C25s ? If so, what was the procedure? Of course, I'm aware of shared_blocks feature, which I removed for all system partitions already.
It's funny, but even if flag rw is set as a mounting option in both fstab files - you'll never get RW for any system partitons. You'll never see RW not only for system / vendor / odm but for all my_ partitions - all of them fail to mount in RW.
And no, it's not funny, it's weird.
Click to expand...
Click to collapse
all partitions are set to RO because of dynamic partitions
gianonceu said:
all partitions are set to RO because of dynamic partitions
Click to expand...
Click to collapse
This does not answer my question how to get RW on this particular model. Probably, you know that RW can be easily achieved on other realme phones. Actually, on dozens of phones with super partition where we're bound to have dynamic partitions.
Also, when you say "...partitions are set to RO..." what exactly you mean? Set by whom? To repeat: I've manually removed shared_blocks features on all super sub-partitions and then re-created super. When I flash it, I can clearly check in TWRP that tune2fs -l does not show shared_blocks anymore. So, who has set partitions to RO?
If you know what mechanism of android sets RO on super sub-partitions with shared_blocks removed - please share your knowledge.
Well, judging by no responses the question appears to be of almost zero interest for forum members. Is this the case?
I'm glad to confirm that RW on all super partitions can be easily achieved if RMX3195 runs A12.
However, you'll need to convert erofs dynamic partitons of super to ext4 ones. I did it manually in linux. After partitions are converted you also will have to make certain effort to remove bloatware from ext4 partitions. If bloatware isn't removed then total size of ext4 partitions will exceed max size of super and you will not be able to re-construct super.
Funny enough, I failed to get RW on A11.
so i have this problem yet
Congratulations @vp1117 for successfully making your device RW
Did you use the Yuki guide that's basically a copy paste from the thread in my signature (with the addition of a make_ext4fs binary) ? Where did you find those selinux context files for each subpartition of super to plug into the make_ext4fs binary? Without the proper context files the magic is not going to work right?
Thanks!
vp1117 said:
I'm glad to confirm that RW on all super partitions can be easily achieved if RMX3195 runs A12.
However, you'll need to convert erofs dynamic partitons of super to ext4 ones. I did it manually in linux. After partitions are converted you also will have to make certain effort to remove bloatware from ext4 partitions. If bloatware isn't removed then total size of ext4 partitions will exceed max size of super and you will not be able to re-construct super.
Funny enough, I failed to get RW on A11.
Click to expand...
Click to collapse
Can u guide me in same issue I'm also stuck paid no problem
lebigmac said:
Congratulations @vp1117 for successfully making your device RW
Did you use the Yuki guide that's basically a copy paste from the thread in my signature (with the addition of a make_ext4fs binary) ? Where did you find those selinux context files for each subpartition of super to plug into the make_ext4fs binary? Without the proper context files the magic is not going to work right?
Thanks!
Click to expand...
Click to collapse
Hi!
No, I did not use anybody's guide.
I just took a file (product.img, if I recall it correctly) from the old firmware (it was in ext4 format since it was A11 firmware where erofs fs was not implemented yet), mounted it in linux and then just copied into it all files from system_ext.img. Repeated same excersise for my_bigball.img, my_heytap.img, my_preload.img, my_stock.img subpartitions. All contexts were preserved by using proper option of cp command.
And no, I never used make_ext4fs binary.
I made several attempts to re-construct super.img, and I was able to make RW not only for above mentioned 5 subpartitions, but for all 13 subpartitions of super. However, upon some thinking, I decided that I did not need RW for the rest of 8 subpartitions as I did not find much of bloatware in them. So, to make things easier for me I have now RW only for system_ext / my_bigball / my_heytap / my_preload / my_stock. The rest of subpartitions remain in erofs format.
The main riddle for me is that why I failed to achieve RW using same procedure when my RMX3195 ran A11... But I do not plan to return to A11, so this question is already a history for me.
vp1117 said:
Hi!
No, I did not use anybody's guide.
I just took a file (product.img, if I recall it correctly) from the old firmware (it was in ext4 format since it was A11 firmware where erofs fs was not implemented yet), mounted it in linux and then just copied into it all files from system_ext.img. Repeated same excersise for my_bigball.img, my_heytap.img, my_preload.img, my_stock.img subpartitions. All contexts were preserved by using proper option of cp command.
And no, I never used make_ext4fs binary.
I made several attempts to re-construct super.img, and I was able to make RW not only for above mentioned 5 subpartitions, but for all 13 subpartitions of super. However, upon some thinking, I decided that I did not need RW for the rest of 8 subpartitions as I did not find much of bloatware in them. So, to make things easier for me I have now RW only for system_ext / my_bigball / my_heytap / my_preload / my_stock. The rest of subpartitions remain in erofs format.
The main riddle for me is that why I failed to achieve RW using same procedure when my RMX3195 ran A11... But I do not plan to return to A11, so this question is already a history for me.
Click to expand...
Click to collapse
Bro can u try something for me?
In your root dir have folder with name "proc" can u go inside and cut file and move to sdcard or any other modifications to check whether this past also editable or not?