Question Could not mount system in RW mode. Can you? - Realme C25 / C25s

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?

Related

[Recovery] Customized CWM 3.0.1.3 fake-flash with ext4 support (03/06/2011)

OK, here's the deal. This is my attempt in customizing CWM. It features several changes in comparison to one from CM source...
Changes
removed menu entries for updating via /sdcard/update.zip (useless for fake-flash users)
stripped some "No" line entries from confirmation menus
removed some insane size values from partitioning list
added some sane size values to partitioning list
added option to add 2nd ext partition (for some data2sd variants)
added block alignment to partitioning part
added advanced backup submenu
Plans
add block alignment to partitioning part
add advanced backup submenu
add some additional wipe options
Issues
mounting /sdcard again after unmounting not possible
Installation
Just copy this file to root of your SD card and rename it to update.zip. You can also use previous non-customized version.
Source
Source for this project is available on GitHub.
CAUTION! This is still in test phase. And your phone may explode suddenly if you're not careful enough. But in general it is pretty much safe (if you stand several feet from your phone). If you encounter any problems relevant logs are /tmp/recovery.log and /data/sdparted.log which I will need for debugging.
Hi BlaY0!
does this file works even on s-off legend?
Thx
goose2600 said:
Hi BlaY0!
does this file works even on s-off legend?
Thx
Click to expand...
Click to collapse
Yes. Have fun!
Thanks a lot for this
Sent from my Legend using Tapatalk
goose2600 said:
does this file works even on s-off legend?
Click to expand...
Click to collapse
Yes, but why would you do that???
So you buy a Ferrari and put in the engine of Fiat 600? I don't get it
Thanks man, it's great.
goose2600 said:
Hi BlaY0!
does this file works even on s-off legend?
Thx
Click to expand...
Click to collapse
Well, sort of. If you go to recovery via ROM manager, you will not get CWM 3.0.0.6 and if you go to recovery from HBOOT you will not get CWM 3.0.0.6.
The only way is to go to recovery and then choose "Apply update.zip".
So, yes, it works. But it's a bit tricky.
Thanks a lot!
Really helped me!
Fantastic. Great stuff!
This is Super! Been stuck with a rom with ext4 enabled for quite some time now. And this worked!
Blay0! your the man!
Sent from my Legend using XDA App
thanks!but i don't understand !!!I'm not good at these things
i have update the file by recovery and now?where should I set???
No, you have only to put the update.zip on SD-card and that´s it.
Than you have CWM recovery in version 3.0.0.6...
My ext4 partition still can't mount. Is there any way to collect recovery logs or something?
CfYz said:
My ext4 partition still can't mount. Is there any way to collect recovery logs or something?
Click to expand...
Click to collapse
You can run
Code:
adb shell dmesg
just after trying to mount the sd-ext. Then put it in this thread.
BTW, BlaY0, if i correctly understood, in your B ROM ext4 creates with huge_files option. My ext4 partition was created being under your rom, and all had run smooth except current CWM could not mount partition saying
Code:
<6>[ 37.128723] yaffs: dev is 187695106 name is "mmcblk0p2"
<6>[ 37.128936] yaffs: passed flags ""
<4>[ 37.129150] yaffs: Attempting MTD mount on 179.2, "mmcblk0p2"
<6>[ 37.129791] yaffs: dev is 187695106 name is "mmcblk0p2"
<6>[ 37.130004] yaffs: passed flags ""
<4>[ 37.130371] yaffs: Attempting MTD mount on 179.2, "mmcblk0p2"
<3>[ 37.131561] EXT4-fs: mmcblk0p2: Filesystem with huge files cannot be mounted read-write without CONFIG_LBD.
until i turned this option off. Under working system with your kernel/modules ext4 mounts good even with huge_file option.
saw81 said:
thanks!but i don't understand !!!I'm not good at these things
i have update the file by recovery and now?where should I set???
Click to expand...
Click to collapse
as picz mentioned, you put this file in the root of your sd card.
than you switch off your phone. than on it holding the Vol- and the power button. Than select recovery. ant the red [!] screen. press Vol+ and the power button. wait for a blue menu list at the top of the screen. than select update.zip...
this is Fake Flash....
BlaY0 said:
OK, I made this update to S-ON recovery that adds ext4 support. Flash it just after you enter CWM. Test and report...
PS: This is temporary solution.
Click to expand...
Click to collapse
working perfectly. i've successfully backup and restore a CM7 with TGF's ext4 data2ext mod. everything works normal.
Kot_Ik said:
BTW, BlaY0, if i correctly understood, in your B ROM ext4 creates with huge_files option. My ext4 partition was created being under your rom, and all had run smooth except current CWM could not mount partition saying
Code:
<6>[ 37.128723] yaffs: dev is 187695106 name is "mmcblk0p2"
<6>[ 37.128936] yaffs: passed flags ""
<4>[ 37.129150] yaffs: Attempting MTD mount on 179.2, "mmcblk0p2"
<6>[ 37.129791] yaffs: dev is 187695106 name is "mmcblk0p2"
<6>[ 37.130004] yaffs: passed flags ""
<4>[ 37.130371] yaffs: Attempting MTD mount on 179.2, "mmcblk0p2"
<3>[ 37.131561] EXT4-fs: mmcblk0p2: Filesystem with huge files cannot be mounted read-write without CONFIG_LBD.
until i turned this option off. Under working system with your kernel/modules ext4 mounts good even with huge_file option.
Click to expand...
Click to collapse
Yeah, formatting ext4 partition under B or CM adds "huge_file" to the filesystem features by default. Actually this is default for mke2fs config (will be changed in the next B release). My customized and also CM kernal got this LBD alias LBDAF support built in but stock kernel from recovery doesn't hence the error. Unfortunately LBD support can't be built as a module so there is actually no way to add this support to stock recovery if your Legend is S-ON.
But... since LBD alias LBDAF and consequently "huge_file" support in ext4 is actually support for files bigger than 2TB we kinda don't need it I guess so what we can do is as you suggested remove "huge_file" feature from ext4 filesystem like this:
Code:
tune2fs -O ^huge_file /dev/block/<ext4_partition>
e2fsck -pf /dev/block/<ext4_partition>
...and we do this via recovery or system but ext4 partition shouldn't be mounted at that point! So unmount it first or disable data2ext/a2sd and reboot, do da above job, enable data2ext/a2sd and reboot again. To check if "huge_file" feature is actually enabled in your ext4 filesystem you do:
Code:
tune2fs -l /dev/block/<ext4_partition>
...and check "Filesystem features:" line.
Customized CWM 3.0.0.6 for S-ON Legends (fake-flash)
OK, here's the deal. This is my attempt in customizing CWM.
Check 1st post for update!
hi BlaY0 !
can you release img for S-off users ? (i know we can use this but i like IMG)
New update. Check 1st post.
jinxul said:
hi BlaY0 !
can you release img for S-off users ? (i know we can use this but i like IMG)
Click to expand...
Click to collapse
No, I decided not to. Will stick to fake-flash. But if you want, you can do it yourself and post it here...
EDIT: Rather post img in the other thread.

[HACK] Increase Internal Memory Size to Whatever You Want!

Free Memory to > 1Gb!​
How to Increase your Internal Memory Size with very low effort!
NOTICE: This method works both on Rooted and NOT Rooted Phones!
You simply need to meet three easy requirements:
Stock Firmware installed on the Phone (custom ROMS not supported ...They don't need to!)
A microSD with two primary formatted partitions inside (the former 'to FAT32' and the latter 'to EXT4' filesystems)
Ready to Flash to your Galaxy Next via Odin
NOTICE: The following Black Box Howto is explained deep inside in the next post of this Thread (short explanation) and in This Thread from outside: Internal Memory to +1Gb! and related ones (long explanation / Italian Language)
HOW TO
1) Download Tass.ops file for Odin!
2) Type this number on your phone keyboard:
*#1234#
and keep note of the PDA code of the Firmware installed.
3) Download boot image ready for Odin and suitable for your firmware:
All modded images are inside my Google Drive; actually we find:
Code:
[b][url=https://docs.google.com/folder/d/0B3qe_9NlA1D_QVlKXy01bjZPbVE/edit]Memory Hack Google Drive Archive[/url][/b]
[b][size=3]Galaxy MINI/NEXT/POP[/size][/b]
S5570AIKQ3 S5570BGKS3 S5570BGKT2
S5570BVKQ4 S5570BVKT1 S5570DDKA7
S5570DDKQ7 S5570DXKPD S5570DXKT6
S5570JPKQ8 S5570JPKS1 S5570JPKT2
S5570JVKQ3 S5570JVKT1 S5570MJKS2
S5570XIKQC S5570XWKE3 S5570XWKQG
S5570XWKS2 S5570XWKS7 S5570XWKT7
S5570XWKTH S5570XWKTN S5570XWKTS
S5570XWKTU S5570XXKPF S5570XXKPI
S5570XXKPK S5570XXKS1 S5570XXKS4
S5570ZSKPC
-----------
S5570bVJKPB
-----------
S5570LWMKP9 S5570LWMKPJ S5570LWMKPO
[b][size=3]Galaxy MINI/NEXT/POP[/size][/b]
[b]Froyo[/b]
S5570DXKB1 S5570XIKFI S5570XWKC1
[b][size=3]Galaxy GIO[/size][/b]
S5660AIKT4 S5660DXKT8 S5660JPKT7
S5660XXKPA S5660XXKTF S5660XXKTI
S5660XXKTK S5660XXKTO
-----------
S5660MUGKG3
[b][size=3]Galaxy FIT[/size][/b]
S5670DDKB1 S5670DDKT3 S5670DXKPB
S5670DXKT4 S5670JPKQ7 S5670XWKQA
S5670XWKTI S5670XXKPQ S5670XXKPU
-----------
S5670LUBKP6 S5670LUBKPI
[b][size=3]Galaxy ACE[/size][/b]
S5830BOKS3 S5830DDKQ5 S5830DDKQ8
S5830DXKPB S5830DXKPD S5830DXKT5
S5830XWKPY S5830XWKS2 S5830XWKS9
S5830XWKT7 S5830XWKTM S5830XWKTQ
S5830XXKPH S5830XXKPP
your firmware not listed? ...take a look into Google Drive first, then let me know if you don't find anything!
4) Flash the downloaded archive with Odin
Example image follows:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
5) THAT'S ALL FOLKS!
- - -​
How does it Work:
Scenario 1:
I switch on the Phone, without a MicroSD slotted in or with a microSD with a single FAT32 partition (broken or damaged microSD also suite this scenario...); GingerBread boots as usual!
No Difference!
Scenario 2:
I switch on The Phone with a microSD slotted in (with the second partition formatted as EXT4 filesystem but still EMPTY); Ginger boots acting as if
/data
is completely moved outside to microSD but just WIPED (not true obviously, and the original /data is safe inside the phone), so it resettle it from beginning...
NOTICE:
...If your second partition is 1Gb wide...
...your new Internal Memory will be 1Gb wide...
Scenario 3:
I switch on the Phone with the second partition of the microsd (EXT4) up and running (already resettled up for use and with my userdata on it); Ginger simply boots with
/data
moved outside to microSD with your userdata there and tons of apps just installed from the market...
Example Image of my New Internal Memory Size follows
- - -​
NOTICES & ADVICES:
If I want to remove the microSD from the slot, FIRST I NEED TO SWITCH OFF THE PHONE!
When I install apps from the Market, Ginger Misunderstands the actual new Internal Memory SIZE and puts the apk files to External Storage anyway! I simply need to move them "to the phone" via "Settings menu" immediately after!
When I switch on the Phone without the microSD, I boot using the original /data inside the phone, actually loosing all the apps installed onto the external one untill next boot with SDcard; and, of course, loosing my sms stored there and others personal userdata too.
Unfortunately this boot image heavy conflicts with Link2SD (great app anyway!), so you must choose one: This Boot image or Link2SD... not both... sorry!
Don't You Like the boot image just installed and You want to revert without flashing the full firmware to the Phone?
The original images, ready for Odin, are stored into my Google Drive too, inside BASE subfolders!
- - - - - - - - - - - - - - - - -​
THREAD ADDONS
CHECK FILESYSTEM FOR ERRORS
On post n. 43 you can find an Android Application useful to check the 2nd partition filesystem for errors once a month...
EXT4 Checkup Tool 1.0 RC3
P.S. Only for rooted phones!
Click to expand...
Click to collapse
HOW TO
From post n. 52 I explain exactly What I do deep Inside and Step by Step...
Click to expand...
Click to collapse
ADDED PHONE MODELS
In post n. 56 I added boot images modded for Galaxy FIT (S5670), Galaxy ACE (S5830) and Galaxy GIO (S5660)!
Click to expand...
Click to collapse
ALL IN ONE WONDER AUTOSCRIPT
In post n. 78 I added a Linux Script "All in one" to mod your boot Image on your own simply with a double-click!
Click to expand...
Click to collapse
MEMORY AND OVERCLOCK KERNEL
In post n. 148 you find modded images with OC Kernel inside
P.S. Only for rooted phones with CWM or Custom Recovery!
Click to expand...
Click to collapse
Patched Boot Image "Deep Inside"
As I stated in the previous Post, I skip the Long Explanation of this How to (Italian Threads online anyway) and briefly describe What I did!
1) Split Boot.img
I splitted boot.img into it's two main parts: The Kernel and the Ramdisk.
2) Edit ramdisk
2.1) Strip Samsung Kernel Modules
I figured out that Samsung modules used for rfs filesystem are compiled with all the debug symbols inside, so I stripped them saving more than 3Mb into the ramdisk!
NOTICE: The boot.img must not exceed 8Mb Size or I cannot flash it! BEWARE!
2.2) Add Ext4 kernel Modules
I compiled the jbd2.ko and ext4.ko modules for the attached Kernel and put them into /lib/modules inside the ramdisk:
Code:
gandalf $ ls -l ./ramdisk/lib/modules/
totale 1304
-rw-r--r-- 1 root root 236116 11 dic 08.24 [b]ext4.ko[/b]
-rw-r--r-- 1 root root 363932 11 dic 08.24 fsr.ko
-rw-r--r-- 1 root root 211200 11 dic 08.24 fsr_stl.ko
-rw-r--r-- 1 root root 58176 11 dic 08.24 [b]jbd2.ko[/b]
-rw-r--r-- 1 root root 260568 11 dic 08.24 rfs_fat.ko
-rw-r--r-- 1 root root 90968 11 dic 08.24 rfs_glue.ko
-rw-r--r-- 1 root root 99532 11 dic 08.24 sec_param.ko
gandalf $
2.3) Patch init.rc file
I patched the init.rc file into the ramdisk to load these modules into the kernel immediately after the first boot stage of the firmware:
Code:
# insmod fsr/rfs modules
insmod /lib/modules/fsr.ko
insmod /lib/modules/fsr_stl.ko
insmod /lib/modules/rfs_glue.ko
insmod /lib/modules/rfs_fat.ko
insmod /lib/modules/sec_param.ko
[color=red]insmod /lib/modules/jbd2.ko[/color]
[color=red]insmod /lib/modules/ext4.ko[/color]
2.4) Add busybox
I added a copy of busybox into /sbin.
I'll need it to mount ext4 filesystems on microSD later on.
Code:
gandalf $ ls -l ./ramdisk/sbin/
totale 2088
-rwxr-x--- 1 root root 117948 11 dic 08.18 adbd
-rw[color=red][b]s[/b][/color]r-xr-x 1 root root 2016700 11 dic 08.21 [b]busybox[/b]
lrwxrwxrwx 1 root root 7 11 dic 08.18 ueventd -> ../init
(i686) gandalf ~ (i686) $
2.5) Patch init.rc again
I changed the mount command for /data!
Original code:
Code:
# Mounting of system/userdata is moved to 'on emmc' and 'on nand' sections
# We chown/chmod /data again so because mount is run as root + defaults
[color=red][b]mount rfs /dev/stl13 /data nosuid nodev check=no[/b][/color]
chown system system /data
chmod 0771 /data
Patched code:
Code:
# Mounting of system/userdata is moved to 'on emmc' and 'on nand' sections
# We chown/chmod /data again so because mount is run as root + defaults
[color=red][b]exec /sbin/busybox sh /init.data.sh[/b][/color]
chown system system /data
chmod 0771 /data
2.6) add init.data.sh file
I added an external shell file, used to mount microsd /data avoiding the Android Init Language used by init.rc.
Code:
gandalf $ cat ./ramdisk/init.data.sh
#!/sbin/busybox sh
/sbin/busybox mount -o nosuid,nodev -t ext4 /dev/block/mmcblk0p2 /data || /sbin/busybox mount -o nosuid,nodev -t rfs /dev/stl13 /data
gandalf $
3) Repack ramdisk and kernel into boot.img
I used the AOSP mkbootimg tool to repack alltoghether.
4) Prepare Odin Archive ready for flash
I created a PDA Archive with only boot.img inside.
A command sequence could be, for example:
Code:
tar -H ustar -c boot.img > CODE_S5570XWKS7_boot.tar
md5sum CODE_S5570XWKS7_boot.tar >> CODE_S5570XWKS7_boot.tar
mv CODE_S5570XWKS7_boot.tar CODE_S5570XWKS7_boot.tar.md5
That's All!
Enjoy!
Wonderful
now i am using this: http://forum.xda-developers.com/showthread.php?p=18561098
i have s5570jpks1 in pda
phone:s5570xwks2
csc:s5570ojpks1
it's arabic firmware with 2.3.5
help me please
what pda i should use?
Increase Performance? Oh Yes!
denzel09 said:
...now i am using this: http://forum.xda-developers.com/showthread.php?p=18561098
Click to expand...
Click to collapse
Great Script! Really Interesting!
Good Idea to mix /data outside with some programs still onboard, looking to performance...
At a first glance I like a lot this command:
Code:
busybox mount -t ext4 -o noauto_da_alloc,data=ordered,commit=15,barrier=1,nouser_xattr,errors=continue,noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
I achieve the same safe result while data=ordered and barrier=1 are defaults for ext4 mount command and because I compiled ext4 kernel modules with the extended attributes disabled (nouser_xattr).
I surely agree with noatime and nodiratime due to microsd lifecycle troubleshootings, but never set noauto_da_alloc...
...after some readings I figured out that it should be a MUST Option for SSD...
While working of this bunch of code
Code:
#-- SDCard Speed Fix
if [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/system/xbin/echo "8192" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;
fi;
I surely upgrade AS SOON AS POSSIBLE the attached boot images to gain performance without loosing stability..
Thanks a Lot!
P.S. Great Idea Again; thanks to Amarullz too.
Actually, anyway, I moved the whole GingerBread outside... I have /data, /system and /cache alltoghether into my microSD...
...that is: "free to experiment! No need to halt and reflash on errors"...
midomad said:
i have s5570jpks1 in pda...
Click to expand...
Click to collapse
I'll take a look. Please Hold on...
Doc_cheilvenerdi.org said:
I surely upgrade AS SOON AS POSSIBLE the attached boot images to gain performance without loosing stability..
Click to expand...
Click to collapse
Please do it ASAP, thanks
Doc_cheilvenerdi.org said:
...
I surely agree with noatime and nodiratime due to microsd lifecycle troubleshootings, but never set noauto_da_alloc...
...after some readings I figured out that it should be a MUST Option for SSD...
While working of this bunch of code
Code:
#-- SDCard Speed Fix
if [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/system/xbin/echo "8192" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;
fi;
....
P.S. Great Idea Again; thanks to Amarullz too.
Actually, anyway, I moved the whole GingerBread outside... I have /data, /system and /cache alltoghether into my microSD...
...that is: "free to experiment! No need to halt and reflash on errors"...
Click to expand...
Click to collapse
Wow, 8 MB ? Is that really useful ? I read somewhere that 3 MB is optimum, 4 MB is slightly waste. 8MB ? Then again I might be wrong, never tried 8MB myself.
It's a good thing you come up with this doc. I read at stepph's thread how you MOVED /system to MicroSD but somehow I forgot to ask. Now you mentioned it here. Is it safe ? No i/o bottleneck / noticeable lag ? I know we'll need a really fast and reliable MicroSD card. What's yours doc ?
---------------------------------
Sent from my Samsung Galaxy Mini GT-S5570 via xda-dev app
CyanogenMod 7.2.0-RC4-KANG by squadzone
Doc,
Now this just came across my mind. With /system and /data in MicroSD, does this mean we can MULTIBOOT ?
Let's say I partitioned my sdcard into 5 : 1st one is FAT32 and the other 5 is ext4. I modified boot.img from (let's say) CM7 and stock GB. On CM7's init.rc i put /system and /data into partition 2&3. On stock GB's init.rc i put them into partition 4&5. Partition 6 is used for /cache. I flashed stock with modded boot.img, play around first. Then I flashed CM7 with modded boot.img and played around. Now each time I want to switch ROM, all I have to do is flash the appropriate boot.img using CWM. This boot.img will determine which partition will be used for /system and /data.
Could it work doc ?
---------------------------------
Sent from my Samsung Galaxy Mini GT-S5570 via xda-dev app
CyanogenMod 7.2.0-RC4-KANG by squadzone
Read Ahead...
distan7 said:
Wow, 8 MB ? Is that really useful? I read somewhere that 3 MB is optimum, 4 MB is slightly waste. 8MB? Then again I might be wrong, never tried 8MB myself...
Click to expand...
Click to collapse
Antutu Benchmark Total Result on my Stock ROM with a 4Gb SD Class 4 said about 1650...
After moving (without tuning filesystems...) Antutu Said about 1450...
After Amarullz reading I remounted my filesystem from the shell this way:
Code:
# busybox mount -o remount,nosuid,nodev,noatime,nodiratime,errors=continue,nouser_xattr /cache (ext2 filesystem)
# busybox mount -o remount,ro,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /system (ext4)
# busybox mount -o remount,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /data (ext4)
#
Left commit=15 backwards, but I'll put it in the new init.rc of patched boot images... I also set barrier, data order and extended attributes, even if defaults...
and Antutu said about 1550...
Actually I'm trying on the fly this tweak
Code:
# busybox echo "[b]8192[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
#
While googling for optimum value...
And Antutu said about 1600
Now I'm trying to stress the system with heavy loads from/to SDCard...
...Anyway I cannot say anything yet about Battery charge..
van8x10 said:
Please do it ASAP, thanks
Click to expand...
Click to collapse
...Boot images are ready to be shared with these patches on, but I need to test them one by one... I think to be Ready within tomorrow night...
midomad said:
i have s5570jpks1 in pda...
Click to expand...
Click to collapse
Found and patched 2.3.5 fimware S5570JPKS1 with these tweaks too... scheduled to be tested within tomorrow night too...
distan7 said:
...I read at stepph's thread how you MOVED /system to MicroSD but somehow I forgot to ask. Now you mentioned it here. Is it safe ? No i/o bottleneck / noticeable lag ? I know we'll need a really fast and reliable MicroSD card. What's yours doc?
Click to expand...
Click to collapse
It is safe... Up and running very heavy since last month...
Bottlenecks and lags occurr when I stress /data writing and /system reading while /cache is working... sometimes happens...
As I said somewhere else, if You like to play with your phone dont do it! but...
...if you like (for example) to test firmwares or play around deep inside the system without flashing anything and resuming from errors whenever you want... I call it "a Must Option"
I don't have a fast SD card (now on 4Gb class 4 and very old sailor...) so I cannot compare lags and performance for now with faster memories...
distan7 said:
...With /system and /data in MicroSD, does this mean we can MULTIBOOT ?
Let's say I partitioned my sdcard into 5 : 1st one is FAT32 and the other 5 is ext4. I modified boot.img from (let's say) CM7 and stock GB. On CM7's init.rc i put /system and /data into partition 2&3. On stock GB's init.rc i put them into partition 4&5. Partition 6 is used for /cache. I flashed stock with modded boot.img, play around first. Then I flashed CM7 with modded boot.img and played around. Now each time I want to switch ROM, all I have to do is flash the appropriate boot.img using CWM. This boot.img will determine which partition will be used for /system and /data...
Click to expand...
Click to collapse
I'm working on this in my spare time... Actually - without flashing anything - I cannot change kernel from one boot to another one, but via init.rc I could start following something written somewhere on /cache or /sdcard...I could - for example - shutdown CM7 saying that I want to boot (next time) to Stock GB and viceversa...
I'm not a True Developer (Long time ago I said "Hello World" to somebody but I don't know if I will be able to do it) but I'm trying to start the system asking to th euser what to do during the boot stage...(Hard Task for me, but why not...)
Doc_cheilvenerdi.org said:
Antutu Benchmark Total Result on my Stock ROM with a 4Gb SD Class 4 said about 1650...
After moving (without tuning filesystems...) Antutu Said about 1450...
After Amarullz reading I remounted my filesystem from the shell this way:
Code:
# busybox mount -o remount,nosuid,nodev,noatime,nodiratime,errors=continue,nouser_xattr /cache (ext2 filesystem)
# busybox mount -o remount,ro,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /system (ext4)
# busybox mount -o remount,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /data (ext4)
#
Left commit=15 backwards, but I'll put it in the new init.rc of patched boot images... I also set barrier, data order and extended attributes, even if defaults...
and Antutu said about 1550...
Actually I'm trying on the fly this tweak
Code:
# busybox echo "[b]8192[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
#
While googling for optimum value...
And Antutu said about 1600
Now I'm trying to stress the system with heavy loads from/to SDCard...
...Anyway I cannot say anything yet about Battery charge..
...Boot images are ready to be shared with these patches on, but I need to test them one by one... I think to be Ready within tomorrow night...
Found and patched 2.3.5 fimware S5570JPKS1 with these tweaks too... scheduled to be tested within tomorrow night too...
It is safe... Up and running very heavy since last month...
Bottlenecks and lags occurr when I stress /data writing and /system reading while /cache is working... sometimes happens...
As I said somewhere else, if You like to play with your phone dont do it! but...
...if you like (for example) to test firmwares or play around deep inside the system without flashing anything and resuming from errors whenever you want... I call it "a Must Option"
I don't have a fast SD card (now on 4Gb class 4 and very old sailor...) so I cannot compare lags and performance for now with faster memories...
I'm working on this in my spare time... Actually - without flashing anything - I cannot change kernel from one boot to another one, but via init.rc I could start following something written somewhere on /cache or /sdcard...I could - for example - shutdown CM7 saying that I want to boot (next time) to Stock GB and viceversa...
I'm not a True Developer (Long time ago I said "Hello World" to somebody but I don't know if I will be able to do it) but I'm trying to start the system asking to th euser what to do during the boot stage...(Hard Task for me, but why not...)
Click to expand...
Click to collapse
thanks a lot bro i can't wait for you're boot img
Upgrade Complete!
Upgrade completed and new boot images uploaded.
Also added S5570JPKS1 to the list!
init.data.sh changed to
Code:
#!/sbin/busybox sh
if /sbin/busybox [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/sbin/busybox echo "[b]3072[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
fi;
/sbin/busybox mount -o [b]noauto_da_alloc,data=ordered,commit=15,barrier=1,nouser_xattr,errors=continue,noatime,nodiratime[/b],nosuid,nodev -t ext4 /dev/block/mmcblk0p2 /data || /sbin/busybox mount -o nosuid,nodev -t rfs /dev/stl13 /data
Enjoy again!
P.S. +10% Performance!
Doc_cheilvenerdi.org said:
Upgrade completed and new boot images uploaded.
Also added S5570JPKS1 to the list!
init.data.sh changed to
Code:
#!/sbin/busybox sh
if /sbin/busybox [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/sbin/busybox echo "[b]3072[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
fi;
/sbin/busybox mount -o [b]noauto_da_alloc,data=ordered,commit=15,barrier=1,nouser_xattr,errors=continue,noatime,nodiratime[/b],nosuid,nodev -t ext4 /dev/block/mmcblk0p2 /data || /sbin/busybox mount -o nosuid,nodev -t rfs /dev/stl13 /data
Enjoy again!
P.S. +10% Performance!
Click to expand...
Click to collapse
it's a little slowly but working like a charm
you're a life saver
Some apps run very slowly, especially import contacts from SD (file .vcf)!
(My Rom is the GingerBread Europe 2.3.6 PDA=S5570JVKT1)
Nice. Some interesting stuffs are really coming out from our forum I will give these mount option a shot.
I will try to convert /system and /cache to ext2 and leave /data as ext4 as system is mounted as r/o as default and cache can be formatted anytime.
I recommend you not to flash boot image for the ROM 2.3.6 PDA=S5570JVKT1. I've come back the original boot image!
van8x10 said:
I recommend you not to flash boot image for the ROM 2.3.6 PDA=S5570JVKT1. I've come back the original boot image!
Click to expand...
Click to collapse
Why? You must explain reasons ...
denzel09 said:
Why? You must explain reasons ...
Click to expand...
Click to collapse
Simply for me, some apps run very slowly:
- It took me ~1 hour to import contacts from vcf file on SD card
- When I was testing the Expense Manager App, My Phone Shutdown for unknown reason (not reboot), luckily not yet bricked
- I think It is not safe for me, then wait for a new version from Doc!
hey can u pls tell me how to do it?or can u pls do it for samsung galaxy ace?
Beta Testing...
van8x10 said:
Some apps run very slowly, especially import contacts from SD (file .vcf)!
(My Rom is the GingerBread Europe 2.3.6 PDA=S5570JVKT1)
Click to expand...
Click to collapse
How I Test all the boot images before sharing them
When I power on the phone the hardware bootstrap passing soon after the control to the (using PC terminology) BIOS (Basic Input OutPut System)... a sort of mini system used to poweron all the peripherals inside and related to the phone... (In my Galaxy Next - briefly - I find something similar in the code sequence mibib-qcsbl-oemsbl-amss-arm11boot)...
...Immediately after, the BIOS loads into memory the Kernel in a fixed position and an initial ramdisk (in a fixed position too) and leave control to the kernel...
...the kernel setup the ramdisk and use the second mini system inside to complete the boot stage...
...Finally the kernel - using commands in the ramdisk - give control to the real system - GingerBread.
Actually the Bios releases control to the kernel calling a routine starting always from a fixed point hardcoded in itself and the Kernel launch the system (wherever it is) looking in the init files inside the ramdsik...
While slightly upgrading GingerBread from 2.3.0 to 2.3.* the mid part of the full boot sequence (kernel + ramdisk) need only two things to work properly:
Kernel compiled with the first assembly code starting from the fixed position hardcoded in the Bios
init files in the ramdisk showing where the filesystem and its data are...
Finally: All boot.img of GingerBread flavours meet these prerequisites... so I can easily use anyone of them with my system (or any other minor version of Ginger) while my BIOS call the kernel and it is in the right place and the init files exit to the filesystem where it really is...
I simply flash one of the shared boot images and test it three times:
power on with micorSD outside (system boot as usual)
power on with microSD inside and /data empty (the system fill it with all what is needed)
power on with microSD already full of apps, userdata and cache
I check mount points, SD read ahead, browse something on Internet, Market...
...and Finally I feel comfortable with the image cooked...
...I can share It!
Why didn't I said that you can use any of the shared boot images
If I simply call the boot image (for example)
CODE_S5570DOC01_boot.tar.md5
probably several end users (not heavy skilled with Linux, boot, Android, etc...) could be scared to use it...
... so I decided to provide an image for any of the "most wanted versions" now on the network using the attached kernel (anyway slightly different each other) with the same name of the Stock Version...
How I handle Errors reported from end users
van8x10 said:
Simply for me, some apps run very slowly:
- It took me ~1 hour to import contacts from vcf file on SD card
- When I was testing the Expense Manager App, My Phone Shutdown for unknown reason (not reboot), luckily not yet bricked
- I think It is not safe for me, then wait for a new version from Doc!
Click to expand...
Click to collapse
With my Wind boot.image first, and then with the JVTK1 one, I did what follows:
First Test
I exported my contacts to SD twice (about 2 minutes every time)
I imported it four times from SD without overwriting existing ones (about 1 minute to 2 minute at last) growing it to 400 entries
I exported and Imported them again (2 +2 minutes)
Test made with both the boot images - same result
Second Test
I own Titanium Backup PRO so I performed a backup of 98 apps (about 200Mb mixed from /system and from outside /data) to SD (4-5 minutes)
I repeated 3 times forcing the full operation (always about 5 minutes)
I Verified the backups towards original apps (3-4 minutes) (Found 2 errors related to WiFi in both boot images)
I restored 25 apps (this time only the ones stored on the outside /data - left untouched /system); I needed 10-12 minutes to reinstall them while dr web light antivirus was underneath scanning them. (Market crashed once in JKVT1 boot image)
Third Test
Called friends by Phone,
Sent some SMS to them,
Whatsapped them too,
Browsed xda-developers forum with Opera Mobile and Tapatalk.
Fourth Test
Don't do it!
I started "via emulator terminal" to dump a 100Mb wide file copying from /dev/zero...
while writing to SD I removed it crashing the system...
All fine after reboot... but (I'll soon post about what I'm saying) I suggest to use tools like fsck for errors out of journals...
Last Test
I own a Very old SD (1Gb) at the end of its lifecycle...
Every time I use it, bad blocks appear... timing readouts... freezing PC ports where connected...
...so I consider it a very bad hardware...
...but very useful for extreme tests of hardware/software endurance...
I made this test only with JVKT1 anyway...
I prepared the 2 partitions in it on my Linux PC (system froze twice then I was able to write partion table and format them)...
...Power On the phone with SD inside...
...adb shell and ddms connected to follow the de-wipe operation from PC..
...needed 40 minutes to complete it...
...frustrating...
...the System ended up and running anyway...
Conclusions
I think that the problem noticed should be investigated outside the boot stage of Ginger JVKT1 image...
How I cook the boot images
The images to deal with are growing up (just preparing XXKPI) so I prepared a Batch Farm used to do the dirty job avoiding human errors...
...Obviously I check pre and post by Hand...
...Test on My Next...
...Share...
Once the Script will be STANDALONE FUNCTIONALE I'll share it too!
van8x10 said:
...luckily not yet bricked ...
Click to expand...
Click to collapse
No luck needed here...
Studying Brick deep inside, while the Flash operation doesn't touch the first BIOS code (mibib, ecc...), if I don't make mistakes with Tass.ops or images too big I cannot really Brick while flashing...
...obviously I can always kill definitely my system with a wrong root command...
...All situations that I can resolve at last using Odin again...
parasmi said:
Nice. Some interesting stuffs are really coming out from our forum I will give these mount option a shot.
I will try to convert /system and /cache to ext2 and leave /data as ext4 as system is mounted as r/o as default and cache can be formatted anytime.
Click to expand...
Click to collapse
Good Hint! Why do I need to journal a filesystem read only... I think I can deal with it occasionaly while readwriting something to it anyway!
THANKS!
when i want to use my phone on start up: keep rebooting many times and after that it works
any idea DOC?

Full unroot sufficient for OTA?

Hi. There is a thread here where we are wondering if SuperSu full unroot is enough to allow an OTA to succeed (assuming no other mods were made to the system other than root) (Nexus 6, Lollipop). There is speculation but hard to find a definitive answer on the subject. Anyone here able to shed light on that? Thanks!
It depends.
OTAs can update various parts of the system in various ways.
Previous to Lollipop, updates to the system partition were usually (but not always) done file-based. Which meant that if you removed/renamed all the modified files and put back their originals, the OTA would work. And thus, SuperSU's OTA survival option and/or the unroot option would allow OTAs to complete.
Partition-based OTAs have become standard with Lollipop. Some OEMs have used them before (different implementation), but it was rare. This new style OTA does not patch the differences between files, but on the underlying partition contents. If you make changes to a partition's filesystem and then revert them so that all the files and their contents are original again, this does not actually mean the partition contents are completely the same. In fact, just remounting /system read-write and not making any modification changes the partition contents - that specific change is actually the first thing these OTAs check.
If the OTA is partition based (which by far most OTAs upgrading from 5.0 to something newer will be) the only way to guarantee the correct contents of the system partition so that the patch script will succeed is to reflash the entire partition.
Chainfire said:
Partition-based OTAs have become standard with Lollipop.
Click to expand...
Click to collapse
I wonder if that is because of problems from rooted devices and modified System partitions. They now replace the entire partition to ensure a successful update.
Chainfire said:
In fact, just remounting /system read-write and not making any modification changes the partition contents - that specific change is actually the first thing these OTAs check.
Click to expand...
Click to collapse
Is that because some people leave '/system' read-write or is there some residual change even after the partition is returned to read-only. In other words: if someone remounts '/system' read-write and immediately returns it to read-only without any writes to it, is there some detectable change that remains.
Frank
Frank Westlake said:
I wonder if that is because of problems from rooted devices and modified System partitions. They now replace the entire partition to ensure a successful update.
Click to expand...
Click to collapse
No, it's for dmverity. A kernel-based security system that verifies the system partition contents are as the manufacturer intended. It requires the partition contents to be predictable and verifyable on block level. See https://source.android.com/devices/tech/security/secureboot/index.html for further details.
Frank Westlake said:
Is that because some people leave '/system' read-write or is there some residual change even after the partition is returned to read-only. In other words: if someone remounts '/system' read-write and immediately returns it to read-only without any writes to it, is there some detectable change that remains.
Click to expand...
Click to collapse
Yes, there is.
From what I can see though (in updater-script), in current OTA for past Nexus devices, they are still file-based, even for 5.0>5.0.1(2) upgrade path.
This is not truth for Nexus 6 and 9 OTAs, which are partition-based from day one.

[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
Pressing nothing will boot the active system: stock or primary virtual system. Sure, you should have installed one or more virtual ROMs.
Backup & restore or creating/installing a virtual ROM are easy as copy & paste: all img's will be at
Code:
/MultiSystem/img/system
To backup a virtual/stock system, you have many options:
Use create function to create from stock system
Use copy function to copy the IMG
Copy & paste with a new name
Use FlashFire (fully supported on virtual/stock ROMs)
...
If you've IMG mounting issues, run the following commands:
Code:
mount -o remount,rw /system
busybox ln -sv /proc/self/mounts /system/etc/mtab
If this doesn't help, try mounting from Terminal Emulator or ADB shell after selecting the IMG in MultiSystem app, by running the following command:
Code:
MultiSystem mount virtual
This is the one thing missing from my Note 4. Thank you for the detailed Q&A and i can't wait to try this tool out.
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:
Thank you so much for this! My multbooting-manic* appetive is wet (read: RAVENOUS) :laugh: Thank you also for the extremely comprehensive and clear FAQ, which answered nearly every question that I had, as well as some other very helpful ones that hadn't even occurred to me! I just have a few other questions that arose when planning my own personal setup with the incredible tool (just to be clear, I don't plan on updating to TW LP.... propbably for a while). Also this is what I'm thinking for a 3x boot setup: stock odexed ROM (first question). virtual slot 1: Dynamic Kat 4.2 (KK), v-slot 2: AOSP LP... think I'm leaning towards XenonHD.
Questions:
1. Do you have a recommendation for a custom (Kit Kat) ROM compatible with the N910T? AFAIK JasmineROM isn't compatible, looks nice though. Am I correct in my interpretation that any stock-ish odexed ROM would be a good base for a stable installation? I need to look through the DevDB again, but just wondering if you had a recommendation.
2. I just want to make sure about this, because you asked and answered in the OP Would you consider using the stock kernel with the ROM in stock to be "best practice", or does it matter? I just ask because I've been a longtime supporter of the AEL kernel and would prefer to use that (with both the ROM in stock and v-slot 1). Thoughts?
3. RE: the BusyBox installation in the stock slot, is there a particular version/installer that you recommend? I usually use Sterickson's but have also used BB on Rails. both of which install to system/xbin (and remove any former installation from sbin), so just wondering if it made a difference.
Thank you so much again! BTW, just thought I'd mention that I while writing this, I saw that Amazon had PNY 128GB UHS-1 micro sd's for $75 and ordered one . I currently have 2 of that same card, one in my N4 and one in my Note 10.1 2014 and really think that PNY storage products in general are excellent. Just thought I'd put the word out.... curious why this topic made me think of that...
*multibooting-maniac adj. Descriptor of a person and/or geek who has "Hackintosh"-based triple boot installations on two or more personal conputers and needs the computer that they carrry around in their pocket to catch up with the rest of the gang :laugh:
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
First off, this sounds like a really nifty and useful program/app/modification? Sorry, I don't know what to really call it.
As per the above quoted, I am a little confused. The part about (same kernel)? I may be missing something but in regards to being able to run Lollipop ROM along with KitKat ROM either of which located as primary or virtual (SDcard) , how is this actually possible? As far as I know, while we can use say COD6 - bootloader & modem, I am not aware of an actual "Kernel" that could support both? Hope I am voicing this correctly... :silly:
Other question and I apologize if I missed it as I tried my best to read the well detailed OP's...
- What actual recovery is being used? Can I assume TWRP, and if so, is it a "Special - modified version" OR can we use any of the later TWRPs at our choice?
Thanks! Interested in following this!
jazzmachine said:
Thank you so much for this! My multbooting-manic* appetive is wet (read: RAVENOUS) :laugh: Thank you also for the extremely comprehensive and clear FAQ, which answered nearly every question that I had, as well as some other very helpful ones that hadn't even occurred to me! I just have a few other questions that arose when planning my own personal setup with the incredible tool (just to be clear, I don't plan on updating to TW LP.... propbably for a while). Also this is what I'm thinking for a 3x boot setup: stock odexed ROM (first question). virtual slot 1: Dynamic Kat 4.2 (KK), v-slot 2: AOSP LP... think I'm leaning towards XenonHD.
Questions:
1. Do you have a recommendation for a custom (Kit Kat) ROM compatible with the N910T? AFAIK JasmineROM isn't compatible, looks nice though. Am I correct in my interpretation that any stock-ish odexed ROM would be a good base for a stable installation? I need to look through the DevDB again, but just wondering if you had a recommendation.
2. I just want to make sure about this, because you asked and answered in the OP Would you consider using the stock kernel with the ROM in stock to be "best practice", or does it matter? I just ask because I've been a longtime supporter of the AEL kernel and would prefer to use that (with both the ROM in stock and v-slot 1). Thoughts?
3. RE: the BusyBox installation in the stock slot, is there a particular version/installer that you recommend? I usually use Sterickson's but have also used BB on Rails. both of which install to system/xbin (and remove any former installation from sbin), so just wondering if it made a difference.
Thank you so much again! BTW, just thought I'd mention that I while writing this, I saw that Amazon had PNY 128GB UHS-1 micro sd's for $75 and ordered one . I currently have 2 of that same card, one in my N4 and one in my Note 10.1 2014 and really think that PNY storage products in general are excellent. Just thought I'd put the word out.... curious why this topic made me think of that...
*multibooting-maniac adj. Descriptor of a person and/or geek who has "Hackintosh"-based triple boot installations on two or more personal conputers and needs the computer that they carrry around in their pocket to catch up with the rest of the gang :laugh:
Click to expand...
Click to collapse
@jazzmachine Curious if you ever found out anymore information on this elsewhere that I may be missing. I see it's reference, youtube videos, and whatnot coming up in various threads but little known as far as it's usability on a (910T) Note 4 - mainly what kernel has to be used that supports kexec on STOCK?
lazer9 said:
@jazzmachine Curious if you ever found out anymore information on this elsewhere that I may be missing. I see it's reference, youtube videos, and whatnot coming up in various threads but little known as far as it's usability on a (910T) Note 4 - mainly what kernel has to be used that supports kexec on STOCK?
Click to expand...
Click to collapse
Hey there man, wish I could provide you some useful info wrt this project, but unfortunately I've been unable to find anything directly relevant myself. However, this: http://forum.xda-developers.com/note-4/general/dual-boot-n910f-snap-dragon-variant-t3065211 (shout out and thanks to @aukhan!), which you've likely seen as well, has captured my interest. There are direct references to our device in that thread, but I haven't really been able to make any attempts towards making use of it due to "life stuff" conflicting with my phone tinkering / XDA activity . I haven't been able to follow it as much as I'd like (or hit you up with any actual "useful" info ) but at this point (from what I've read) it seems more... practical wrt our N910Ts.
BTW, I've read and been really appreciative of your contributions to the Emotion kernel thread :good: Definitely keep me posted if you make any progress towards the "multi/dual boot dream"... I'll do the same
jazzmachine said:
Hey there man, wish I could provide you some useful info wrt this project, but unfortunately I've been unable to find anything directly relevant myself. However, this: http://forum.xda-developers.com/note-4/general/dual-boot-n910f-snap-dragon-variant-t3065211 (shout out and thanks to @aukhan!), which you've likely seen as well, has captured my interest. There are direct references to our device in that thread, but I haven't really been able to make any attempts towards making use of it due to "life stuff" conflicting with my phone tinkering / XDA activity . I haven't been able to follow it as much as I'd like (or hit you up with any actual "useful" info ) but at this point (from what I've read) it seems more... practical wrt our N910Ts.
BTW, I've read and been really appreciative of your contributions to the Emotion kernel thread :good: Definitely keep me posted if you make any progress towards the "multi/dual boot dream"... I'll do the same
Click to expand...
Click to collapse
Thanks, I will have a look at the thread you mention. It just seems odd that this post popped up in here some time ago with some questions/replies and went completely abandoned, lol :laugh:
Like one of those teaser posts I guess. I've tried to "Google" around and found some YouTube videos along with active threads on different sections of XDA but anything coming down to usability on our N910Ts and for that matter, other devices, seem to indicated the need for a kexec Kernel in "Stock" Rom. I have yet to find/confirm ANY 910T kernel providing kexec support oddly enough but then again, maybe my google skills are lacking. :cyclops:
Primary system IMG
I can't seem to get MultiSystem to create my primary system IMG. I let it sit while the red LED is on and for quite some time afterwards but it only creates an empty file. Any suggestions would be much appreciated.
Just happened to stumble across this, I used multirom on my older lg optimus g pro.... It worked goud until I had a few custom roms , then it just went all to hell... I think I may give this a try.
No Virtual IMG Mode works...
hsbadr said:
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 !
Click to expand...
Click to collapse
So I've chosen the image and tried booting it by VOL UP and over UI reboot into virtual/ active partition... both failed
/block/loop0 doesn't work, remains mmcblk0p23 though it changed to IMG Stock
Thanks for any help!!!
---------- Post added at 21:53 ---------- Previous post was at 21:48 ----------
fegar said:
I can't seem to get MultiSystem to create my primary system IMG. I let it sit while the red LED is on and for quite some time afterwards but it only creates an empty file. Any suggestions would be much appreciated.
Click to expand...
Click to collapse
How does the log show the empty file? Exit 0 or something like that? Or do you see a 0 MB sized file created?
Have you checked the MultiSystem installation?

System encrypted, /dev/block is read-only

Hi, I have a redmi note 9 that I wanted to mod but I had a lot of problems modding it. I initially installed crDroid 8.7 but the control center animation was lagging and the battery drains fast, so I decided to change the ROM with Project Elixir (Android 12 all ROMs). I saw that crDroid 8.9 came out (September 22, 2022) and there had been some notable changes, as the battery did not run out anymore the animations were fluid, but i was not able to get working google apps.
I tried everything and it wasn't right. (Nik, OpenGapps, MTG nothing) indeed I installed the gapps I had on 8.7 and them didn't work .. So I decided to move to pixel experience android 12 but I had these problems:
On all the roms that I have installed (except I think MIUI) the system is encrypted. I tried flashing a zip, via commands, via recovery but nothing the system is encrypted. I can't access it and in addition I wanted to change the bootanimation but I can't move the zip because it says it's read only and following these commands too I couldn't do it:
adb root
adb disable-verity
adb reboot
adb remount
adb shell
mount -o rw,remount /system
for these commands i also used ADB Sideload (ofc) but also some zips
It says the /dev /<number>/block is read-only and I have not been able to unlock it. (I tried with all these recoveries: TWRP, SHRP (SkyHawk, OrangeFox [UNOFFICIAL but is only for A11]). (If I go from TWRP to sdcard / I have all the files encrypted. I have the phone rooted with magisk.
In addition, I also had problems formatting the phone because the system with both TWRP and SHRP was not deleted or if I restarted the phone after formatting the ROM would open again so to format it I used Pixel Experience which has worked very well so far.
But custom rom already have ability to rw
Anyway you're lucky there thread available google it like
Universal method to get rw
Idk. I have installed Project Elixir, crDroid and this Pixel Experience and are encrypted.
I already googled it....
/dev/* will be always read-only.
And how i can modify the boot animation? Files are encrypted and the zip is in /system/product/media/.zip
/dev/ and /system/ are not same.
Stock MIUI is system read-only.
If you want to mount system as read-write, you need "universal mount system r/w" by @lebigmac
[Closed] Universal SystemRW / SuperRW feat. MakeRW / ro2rw (read-only-2-read/write super partition converter)
Welcome to the one and only, the original, universal, System-RW / Super-RW feat. Make-RW / ro2rw (read-only-2-read/write super partition converter) by lebigmac Also known as: THE-REAL-RW, FULL-RW, EXT4-RW, EROFS-RW, EROFS-2-RW, F2FS-RW...
forum.xda-developers.com
Oh ok, it will work on A12?
I'm not sure.
Ok so tried flashing systemrw_flashable (Universal RW) with sideload bcs i have crypted files.
This is the error that it gave me:
Extracting ...
There was an error extracting the file. Please install unzip and try again.
I tried flashing with SHRP (TWRP based) bcs twrp can't work with adb sideload (for me).
Edit: searched on xda the problem, i installed the BusyBox module in magisk (From Fox Modules Manager) but nothing to do, still same error.
Deltwin said:
Oh ok, it will work on A12?
Click to expand...
Click to collapse
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!
lebigmac said:
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!
Click to expand...
Click to collapse
But how can be you make sure without some beta testers you neef guys like me and this op who have device in hand to test it and give you feedback
lebigmac said:
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!
Click to expand...
Click to collapse
Oh so it cant work in sideload... Good tip if it will work u made a very good script
To be honest I've never used this sideload feature before... What are the advantages of sideloading versus flashing the .zip as usual?
Mr Hassan said:
But how can be you make sure without some beta testers you neef guys like me and this op who have device in hand to test it and give you feedback
Click to expand...
Click to collapse
That's a good idea. I should release an open beta before releasing the final program.
That way we can make sure it works on as many devices as possible
lebigmac said:
To be honest I've never used this sideload feature before... What are the advantages of sideloading versus flashing the .zip as usual?
That's a good idea. I should release an open beta before releasing the final program.
That way we can make sure it works on as many devices as possible
Click to expand...
Click to collapse
Thanks for appreciating the idea
Hope we'll get beta soon but is there any idea date how many days still need to release it
Ok let me show my progress
I make my vendor sys odm to ext4
And ser the logs according to logs
I have rw now
OnePlus8:/ # mount | grep "dm-0"
/dev/block/dm-0 on / type ext4 (rw,seclabel,relatime)
OnePlus8:/ # mount | grep "dm-19"
/dev/block/dm-19 on / type ext4 (rw,seclabel,relatime)
OnePlus8:/ # mount | grep "dm-3"
But the weird thing is still not able to edit
Any file in these parts.
lebigmac said:
it should start up if you comment out the checkSDK() function in the script itself.
Not sure if you can sideload it probably not. Just execute it like any other script (runnable in both Android and recovery) or flash it like any other flashable zip in recovery.
Keep in mind I'm working on a new version that should fix some issues. Just need to make sure it works perfect on multiple devices b4 I release it...
If you can't get my script to work and you're too impatient to wait for the new version to be released then you could try some of the copycat imitations. There's a couple of those floating around here... Good luck!
Click to expand...
Click to collapse
How i can run ur script directly from android?
Like on magisk?
Deltwin said:
How i can run ur script directly from android?
Like on magisk?
Click to expand...
Click to collapse
Hi. Please check the Manual Installation and Examples section of the thread in my signature
And if you're running Android 12+ don't forget to disable the sdkCheck() function in the systemrw.sh script file @ line # 425 like this #sdkCheck
It should work if your only problem is the shared_blocks read-only feature. If your device got the new erofs read-only protection feature then you must wait for next version of my script or try your luck one of the copycat imitations that are floating around.
Good luck!
So after an hard brick at work (so i leaved it for 5 hours with redmi logo on lol) and after many steps i reinstalled MIUI with root... it's running A11 so how i can install it? I need to disable the sdkCheck? I think no if you need it on A12...
Second question i need to flash it before the first boot or i can do it after the first boot?
Deltwin said:
So after an hard brick at work (so i leaved it for 5 hours with redmi logo on lol) and after many steps i reinstalled MIUI with root... it's running A11 so how i can install it? I need to disable the sdkCheck? I think no if you need it on A12...
Second question i need to flash it before the first boot or i can do it after the first boot?
Click to expand...
Click to collapse
I thought hard bricks were unrecoverable?
If your Xiaomi device is running Android 10 or 11 then you don't need to disable the sdkCheck() function in my old script.
Ok here are all the necessary steps in chronological order for you
unlock bootloader
flash stock ROM
install systemrw_1.32
root
debloat
customize
enjoy
No it's possible, i tought not but here i am with my redmi note 9..
jk apart i unbrick with SP Flash tool but i had other problems like NVRAM warning (it fixed automatically with updates idk lol..) and the IMEI was deleted but fortunately i had a flashable backup..
I need to flash the stock rom? I have pixel experience with A12/13
Edit: I tried to flash it (i have the file on the microSD) but it gave me this error:
There was an error extracting the file. Please install unzip and try again.
Well my script was designed for stock A10, A11 ROMs ( or A12 if you're lucky and your device only uses the infamous shared_blocks read-only feature + you must disable sdkCheck() function in script itself ) but I don't see why it shouldn't work on a custom ROM as well
Ok let me try this again but only because it's you
Boot phone into Android OS and make sure it's properly rooted
download the systemrw_1.32_BUNDLE_proper.zip and extract it
extract the systemrw_1.32_flashable.zip
copy the systemrw_1.32 folder into /data/local/tmp/ on your phone
open adb shell or terminal app and type
Bash:
adb shell
su
cd /data/local/tmp/systemrw_1.32
chmod +x ./systemrw.sh
./systemrw.sh in=`realpath /dev/block/by-name/super` size=50
Good luck!

Categories

Resources